I'm looking for a low voltage level translator that will fit on the breadboard and will help me use SPI between one chip that requires 3.3V and the Atmega168 MCU, which is 5V. Any recommendations?

Also, more generally, what IC packaging/mounting types fit the breadboard? I found a translator that seemed to have the necessary electrical characteristics, but only came in surface-mount.

The breadboard has 0.1" (2.54 mm) spacing the same as "most" through hole components.

You also could use a 3.3v regulator instead of trying to "translate" your 5 volts, which is what I assume you are trying to translate.

The voltage translation sure seems complicated (to many choices) I'd just go for a regulator unless there is a reason you need to translate.

Ralph

Is the SPI communication intended to be two way , just from the Atmega to the 3.3V chip, or just from the 3.3V to the 5V Atmega? Is the Atmaga set up as the master?

Stepping down the signal voltage could likely be done with voltage dividers made up of a couple of resistors. Stepping up the voltage will take a little more hardware.

If it was me doing this, I would I would likely make use components I have on hand now. Using two regulator for the separate voltages for the chips (as Ralph has suggested). The 2n7000 mosfets that comes with the Nerkit should work to make the data signal connections. Or I might consider using optical isolators since I would have them on hand and there is no chance that I would damage any of the chips by selecting and inappropriate circuit or transistors. keeping the 5V and the 3.3V completely isolated from each other

Thanks, Gents!

The SPI communication is two-way with the Atmega being the master, so I'll need to translate 5V to 3.3V on three lines and vice versa on one line. (The other chip is a Texas Instruments CC300 WiFi chip which can only be slave, requies 3.3V, and sends response data back to the master).

I bought a 3.3V voltage regulator (thanks for the link, Ralph!) to power the second chip.

You're saying if I want to use what I have on hand from the Nerdkit, I can use the four, n-channel MOSFET transistors that came with the Nerdkit to handle those translations.

This would be my first time using a transistor, so please check my thinking here:

For each of the three 5V-to-3.3V translations, I would wire the transistor's gate to the pin on the 5V master, wire the drain to the 3.3V regulator's ground, and the source to the 3.3V regulator's +3.3V output.

Similarly for the 3.3V to 5V translation, I would wire the gate to the slave's SDI pin (3.3), the drain to the 5V regulator's ground, and source to the 5V regulator's +5V output.

Is that correct?

I am hoping that some other members that are far more familiar with this than I give us a hand here and make a post. One more question. Can you deal with a data inversion in the code on the Atmega micro.? That is to say if the hardware connecting the two chips inverts the data, making the high signals low and the low signals high will that be a issue that you cannot simply overcome in the code?

My thoughts about dealing with the two voltages on the data and clk lines.

typically mosfets would be used to increase the output voltage and or current available from a signal that has a limited current capacity or to lower voltage then required for the intended load. The various connections between the chips do not require very much current at all.

All that is required on the CC300 chips input pins is the presents or absence of a 3.3V voltage with very little current supplying capability. Since the Atmega should be supplying 5V as output on the appropriate pins all that is required is to reduce that voltage to 3.3V for the CC300. This should be easily accomplished using voltage dividers made up of a few resistors. The resistors should be large enough to effectively limit the load on the Atmega output pins. The Atmega pins are capable of supplying up to 40 mA each. There is no reason to draw anywhere near that much current here. I don’t know what you have for resistors; basically you will require sets of two resistors to make voltage dividers. I would make voltage divides that draw something less than 10ma /pin ( ie total resistance of the two resistor add up to more then 500 ohms.) Each set should consist of one resistor with a value twice the value of the other. This will produce a 1/3 -2/3 voltage divider required to get 3.3 volts signal from a 5V signal. Connect resistors in series from the output pins on the Atmega to ground. The larger value resistor connected to ground. You should get 3.3V at the connection point between the resistors.

As far as converting the 3.3V single to 5V using a 2N7000 I think we are going to end up inverting the signal. I don’t know if that would be expectable or not.

You didn't say why you were concerned about the data inversion, but I'm going to take a stab and say it's because raising the gate voltage isn't going to raise the voltage between the drain and source as I suspected, but lower it to near zero, allowing current to flow between them. All those signals, then, would be inverted. I confused voltage with current there - thanks for catching that.

I understand using the resistors for dropping the voltage from master to slave. That should be easy enough.

As far as raising the voltage from slave to master, I wonder if I could still use the 2N7000. I'll bet there's an easy way to invert the signal.

If using one 2N7000 inverts the signal, couldn't I use another one to invert it back? This time, however, I would use 5v on all sides so it would only server as an inverter.

@ jlaskowski -

I had the same situation when trying to communicate with a 3.6v SDHC memory card using SPI. I posted a schematic HERE which uses only the components of the NK (except for 2 diodes). I needed some pullup resistors for the project and had some 51K's lying around, but you can use 10K's or maybe even the 100K's. The 2N7000's work great. I tried using a voltage divider, Zener diodes etc, and while they worked, the circuit drew 5x the amps of the final configuration. Make sure you keep track of the pinouts off the MOSFETS.

It is very simple to invert the incoming bytes of data in the code on the Atmaga . The NOT operation does just that. So to get the inverse of a byte use “~”. The inverse of SPDR is ~(SPDR).

For reasons that are explained on various other posts in this forum the N channel mosfet must be placed on the low (ground side) of the load. So to use it for your purpose you will connect the source to ground. The gate to the output pin on your CC300 SPI The drain to the input pin of the Atmaga SPI. When the gate is low the mosfet does not conduct and the input pin on the Atmega SPI is held high by the internal pull up resistor. When the gate goes high the mosfet conducts and pulls the pin on the drain down to near ground.

I just now reopened the forum and see that pcbolt has posted a solution. I would just follow his lead.

@pcbolt: I've been banging my head on why your solution works, and I think I can finally explain it (let me know if I'm off):

It seems the MCU pin going high at 5V is higher than the 3.6V at the gate and causes the gate to be negative biased. This makes the drain-to-source an open circuit, which causes the voltage at the SD pin to be equal to the 3.6V that's on the other side of the resistor.

If, on the other hand, the MCU pin presents 0 volts at the drain, it makes the gate positive biased and therefore makes the drain to source basically a short-circuit. This drops the voltage at the SD pin to zero.

Do I have it right?

Wasn't there another post around here where someone did exactly this just using some high speed diodes?? I want to say that they did something like this: on the NK to 3.3V device put in one or two diodes to drop the 5V to 3.3V and then let the 3.3V come straight into the NK??

@jlaskowski

I'm no expert on MOSFET's so I'd hate to point you in the wrong direction. I found the circuit HERE and they give a very good explanation. I also built it in Circuit Lab and it worked there too. Nice thing about it is it's bi-directional. One thing to keep in mind is the voltage level the ATmega168 needs to see as "high" (> ~3.4v) might not need a level shift to work.

Why don't you just run the ATmega MCU at 3.3V and let everything work on the same V level?

Now that I look back at the posts, that's probably what Ralph was suggesting. I didn't realize the Atmega could work on less voltage, so I thought he was talking about working a 3.3V regulator into the current mix. Now that I look at the specs for the Atmega, I see it can operate on 3.3V:

Operating voltage for Atmega MCUs: [1.8V - 5.5V for Atmel ATmega48V/88V/168V] [2.7V - 5.5V for Atmel ATmega48/88/168]

Thanks!

Only 2 problems running at 3.3v. First you may have to lower your operating frequency. The 14.7 Mhz oscillator has a minimumum operating voltage level around 3.5 to 3.6v, might be close enough. Second, you'll have to switch power levels when programming through the USB cable, which operates at 5v.

jlaskowski

I also did not realize that the Atmega could work at 3.3V.

It would be relatively straight forward to incorporate a couple of optocouplers to make the communications link to the USB cable. This option would allow you to program the Micro as well as do serial communications between the computer and the micro while the CC300 was operating if that is required. The Atmega and the rest of the circuit could operate at 3.3V with no need to switch power levels.

I don’t have any ideas on how to get around the oscillator minimum voltage issue. useless perhaps, as pcbolt has suggested, you are able to operate at a voltage just high enough for the oscillator and just low enough for your CC300 chip to both work.

Pcbolt, I'm having trouble using the design you pointed me to for level shifting (using MOSFETS). The 5V MCU pin I'm using to drive the value on the other chip is PC3, and it's initially an input pin. That means its value is initially floating before the code I wrote gets a chance to make it an output pin with a 0 value. When the drain on the MOSFET floats, it puts a high value on the other chip. That's a false 1 and it's causing problems, because I can't turn that pin on until other things are accomplished.

Any way I can get the drain to be grounded until the MCU pin has a chance to be set to an output pin with a value of 0?

I'm actually going to repost this as a new question.

@jlaskowski -

If you have another MOSFET, you could wire the drain to 3.3v, the source to the gate of the existing PC3 MOSFET and the gate of the new MOSFET to a voltage divider connected to an unused pin of the MCU.

Another solution is to use a "Diode AND Gate", made up of a resistor and two diodes. There is a Wiki article HERE that describes how to wire your circuit. You just need to control the voltage level of the gate of the existing MOSFET to get it to work.

Here is a little board that will do it for you or take a look at the schematic to see how it works if you want to build your own converter circuit.

https://www.sparkfun.com/products/8745

Thanks for the replies. Before pcbolt's response, I considered an AND gate. I bought an AND gate IC (has four AND gates), but was getting the same problem when one of the inputs was high and the other high-Z (producing an output of 1).

I watched a video on YouTube showing how to make an AND gate with two BJTs and some resistors. I tied one input to high and the other to the MCU's GPIO and it worked nicely. Now the line to the WiFi chip stays low until after the MCU's GPIO is converted from an input to an output and is purposefully set to high.

So, I sure learned a lot doing the voltage level shifting with the N-channel MOSFETs and building AND gates to trick the voltage level shifters into thinking the MCU's GPIOs were low on start-up.

However, with all that, I am unable to get the MCU to talk to the CC3000 WiFi chip. I power it up and the CC3000 lowers it's SPI_IRQ line, indicating it's readiness to receive the first SPI write. The MCU then lowers the CS line and sends several bytes constituting an "init" command; then it raises the CS line to indicate it's done. The CC3000 responds by raising the SPI_IRQ line (previously lowered to indicate readiness to receive after power-up). What's supposed to happen next is that the CC3000 drops the SPI_IRQ line again to indicate it has a response to that command for the MCU to read, but that never happens.

I've been working on this particular problem for over a month, trying to get help from LSR, the manufacturers of the CC3000 chips and evaluation board I bought:

LSR Forum Post

I have a data analyzer and have worked out all that I can figure out to match my trace to the sample trace they pointed me to on that forum thread.

I accidentally fried one of the CC3000 emulator boards about a month ago and bought a new one. It has the same problem, so I doubt it's the CC3000.

The only thing I can think of is that the data analyzer doesn't tell me the voltages of the lines, it just represents highs and lows based on an expected voltage range for each. I'm considering ripping out all the voltage level shifting and trying to operate the MCU at a 3.something voltage as was suggested above. It would remove 4 transistors with resistors that I'm using for the level shifting from high to low. It would also remove one voltage regulator. Anyway, I'm at my wits end and the LSR folks are slow to respond and have been of little help to-date.

My concern is that the max power supply voltage to the CC3000 is 3.8 volts. I'll have to disconnect the chip when I want to program the MCU since the USB needs more. That wouldn't be too hard since it's on a separate breadboard and that board's power is supplied by the MCU board with just two lines. However, if I screw it up once, it's another $60 and 6-7 weeks waiting for a new CC3000 EM board. The following was mentioned above regarding having the board run on 3.3, but the USB on 5V, "It would be relatively straight forward to incorporate a couple of optocouplers to make the communications link to the USB cable." Could anyone supply any details on this?

Simplifying the circuit is definitely a good idea. If you check the voltage on the yellow wire of the nerdkits usb serial line it should be 3.3v or somwhere around there. The green wire is only 5v because it's power is coming from the ATmega. Once you power the ATmega at 3.3 both of your usb lines should be at the 3.3 level and work fine.

However, I think the ATmega max frequency is around 12Mhz with only 3.3v, you'll have to get a different crystal or use the 8Mhz internal clock. Also check the brownout fuses to be sure they are not set over 3.3v. When I run the internal 8Mhz clock I have to drop to 38400 baud too so if you want to keep the higher baud get a 11.0592Mhz crystal. Also you will need to change the baud rate setting in the bootloader. Definately need an ISP programmer if you don't already have one.

Sorry I reposted this in wrong place just now.

Electrically isolated the computer and its peripherals from the Nerdkit circuit board.

Optocouplers will separate the USB cable from the Nerdkit circuit board, in such a way that there is no electrical connection of any kind between them. This circuit should protect the computer and the peripherals from any voltage spikes or unexpected EMF that may occur on the Micro board for any reason.

ICs used DN7414N Hex schitt trigger (inverting) H11L1VM-ND optocoupler Schmitt-trigger The circuit is working well I have tested it with a number of two way serial communications between the PC and the micro.

I would change the values of the resistors on the 3.3V side to maintain approximately the same current levels.

sask55 - why do you want to maintain the ~same current levels on both sides of the optocouplers?

I did not word that comment about the current limiting resistors very well. What I meant is to maintain approximately the same current flow to the LED side of the optocoupler when driving it with the 3.3 volts as was the case when I was using 5.0 volts. NOW that I have took another look at the data sheet, that current value is not likely to be very critical at all. The H11L1VM-ND optocouplers I am using are Schmitt trigger output type, basically the output will be in one of two states, nothing in between. According to the data sheet is little as 1 mA of input current (Pins 1 and 2) should result in the output pin(4) being pull low. If I am reading the sheet correctly the emitter will operate thru a wide range of forward current up to 60 mA continuously. Therefore a resistor should be placed in series with the emitter to limit the current to something between 1 and 60 mA to meet the specifications on the data sheet. I was using a 1.2K resistor with the 5 volt supply that should be about 4.1 mA of current to the emitter. All I can tell you is that level is working very well for me.

I also see that many of the characterises of the optocoupler IC are quoted at 10mA on the data sheet. In order to maintain a emitter current of about 4 or 5 mA I would consider changing the value of the 1.2K resistor on the 3.3 volt side of the optocooupler to something like 500 to 800 ohms . but in fact you should have a very wide range of values that will work just fine.

I hesitate to make any further comments because you are getting ideas from a number of people that are very knowledgeable.

I think there is another approach that would work.

If you had two power supplies a 3.3V for the CC3300 and a 5 Volt for the Atmega. Then you could use a couple of optical couplers to separate the CC300 chip SPI data communications single from the 5Volt MCU SPI data stream.

You may be able to use the USB 5V to power the entire nerd kit board at 5volts. The biggest problem I see with that approach is you would require the USB to be connected at all times to power the MCU. Or just use a couple of voltage regulators. Two optocouplers and possibly an inverting chip to deal with the fact that the optical coupler will invert the data (if you can not deal with that in software) could be used to completely isolate the two levels of voltage while still allowing the data flow to pass between the chips.

It would be the same optical isolator circuit only paced in a different data stream, I don’t see why that would not work. It is working flawlessly for me on a couple of boards between the USB cable and the Micro. It should also work between the two chips regardless of there individual voltage levels.

Hey sask55, you have lots of good ideas, keep'em coming!

I'm sure I will need to convert between 5v and 3.3v one of these days so I tried the voltage divider SparkFun uses in their Logic Level Converter and it works. I don't have your 3.3v device so I used another ATmega at 3.3v as the slave. The master outputs go through a voltage divider to reduce the voltage below 3.3v for the slave. However, the slave output I wired directly to the master since 3.3v is good enough to trigger the master input. I also used a mosfet on the reset pin like SparkFun does in their converter and that works too although if it's in backwards it will put over 4v on the slave pin. Here is the schematic of my test setup and a pic of the breadboard below. If you're wired like this then the spi is probably working.

You mention that you tried the voltage divider SparkFun uses, but your schematic doesn't show the use of the FETs for voltage level shifting that they have in their schematic.

I use the FET configured the same as in the Sparkfun converter to shift the voltage for the slave reset pin. The same circuit will work on the other master output pins just as well, I just chose to drive them through the voltage dividers and use the mosfet for the reset.

Gents, I hope you're still subscribing to the is thread and get this reply. I've taken a lot of time off from this project because I've been busy as heck with my job (shed no tears for me, I get paid by the hour).

The voltage-shifted SPI communication between the ATMega and the Texas Instruments Wifi chip, CC3000 is now responding after receiving the basic initialize command. I removed the transistor+resistor solution that seemed to work for pcbolt and implemented the simple voltage dividing resistors solution first offered by sask55.

Pcbolt, I can't tell you why the solution that worked for you didn't work for me. When I tested it manually, the results were perfect. When I used a Saleae Logic (data analyzer) to look at the SPI signals, they were perfect. The signals weren't even that fast (certainly within the switching speed specs of the transistors).

As far as the 3.3V lines from the CC3000 to the ATMega, I didn't need to shift those voltages at all, since 3.3V is within the voltage range of the ATMega I/O port for a high (1) value.

It seems that the hardware portion of this project is sufficient for now, so I get to move on to the software side (my area of expertise). The first software piece to tackle now that the CC3000 is initialized and responding properly to that initialization, is to get the CC3000 to connect to my wireless network. It has both embedded 802.11 and TCP/IP. So, after the connection to the network, I'll send a TCP/IP message to a listener on my laptop.

j-

Glad to see you got things going. I've learned a few things since I last commented in this thread by needing to hook up a bunch of 3.3v chips to the Atmega. First mistake I made was assuming the USB UART Tx/Rx lines operate at 5 volts. Turns out they are in the 3.3-3.5 volt range on my PC which means there is no problem programming the Atmega when it's powered at 3.3 volts. Also even though the 14.7 Mhz crystal slightly overclocks the Atmega at 3.3 volts, it hasn't been a problem so far. So for most of my projects that interface with a 3.3v chip, I have the Atmega Vcc set to 3.3 volts.

The only real "problem" I've run across is using the LCD. The LCD can understand 3.3 volt signals from the Atmega and since I'm not reading from it, everything is fine. Except one thing, the display itself needs about a 4-4.5 volt drop to get the contrast correct. That meas you need to provide a negative voltage (about -1.1 volt) to one of the LCD pins. I thought of using a diode/capacitor charge pump circuit with a PWM line from the Atmega to do this but I found out I can power the LCD with the normal 5v regulator and use that voltage to power a 3.3 voltage regulator for the rest of the circuit. The only thing you need to be aware of is choosing a 3.3 volt regulator that has "low dropout" meaning the difference between input/output is low (1.7 volts in this case). The LM1117T series regulator works good. If you're not using the LCD, none of this matters.

Were you able to get a breakout board for the CC3000?

Hey guys, just wanted to add if you're interested. I just bought a couple dozen of these for a similar application.

http://www.mouser.com/ProductDetail/Texas-Instruments/CD40109BE/?qs=sGAEpiMZZMsty6Jaj0%252bBBmDx0n9pcbkkTQqRfaDiVa4%3d

In case the link doesn't work, it is part #595-CD40109BE from Mouser.com.

They should easily do the job of voltage level translation--although you'd have to use two chips for one application, one chip for each data direction (up to 4 lines per direction). I'm going to use them to keep my MCU at 5V and communicate with 3.3V NRF24L01+ wireless transceivers.

However, I'm also going to use another MCU and wireless chip to instead change the fuses and operate the MCU at the internal 8MHz clock w/ UART at 19200 baud so I can program the chip using 5V but run it using 3.3V--that way the voltage level translation would no longer be needed.

Hi pcbolt,

Those are some interesting comments. How did you find out that the D+/D- USB lines were 3.3-3.5V? I've wondered that myself, and have read in some places that they are, but I can't find a way to tell for sure since my oscilloscope won't trigger on the non-periodic data stream. Also, before any data transmission occurs, my yellow data wire has 5VDC standing on it, which I'd think would be a problem if that was fed into an MCU running at 3.3V. I suppose I could just sacrifice a chip and try to program one at 3.3V and see if it works. Perhaps I'll do that today.

That's also good to know about the 14.7456MHz crystal working at 3.3V--I was concerned about that and planned to set new fuses, but maybe I won't have to now. Though I suppose it would still be informative to see how well it runs on the internal 8MHz, especially since having one less part could be beneficial for some small project designs.

xodin

xodin -

I was able to put the Rx/Tx USB lines to an O-scope which triggers on falling (or rising) edge, so I was able to get a good picture of the transmission voltages (3.3 to 3.5v). The only trouble with the 8 MHz crystal is the error percentage goes up a little during UART communication. Since you're switching to 19200 baud (38.4k works well too), this error is minimal (0.2%).

I don't think overclocking the MCU is a problem since it is very close to the rated values. I've read about some video projects that run the MCU at as much as 30% over the rated values and have not run into problems.

That's good stuff, thanks. When you connected the lines to the o-scope, did you use D+ and GND, and separately D- and GND, or did you connect the o-scope to D+ and D-?

Actually, I think I only tested the Rx pin (#2) on the MCU with the O-scope ground going to MCU ground while the USB cable was communicating. Not sure if I tested the Tx pin or not. The reason I tested in the first place was an article I read somewhere online that claimed the operating voltage was in the 3.3 to 3.5 volt range. I was sceptical so I had to see for myself. I know I can program the chip with the Vcc set to 3.3 volts and since the way AVRDUDE progams is bi-directional, I'm sure the Tx pin is OK. Just so you know, I was running this on a Windows PC so I can't make any claims for Linux or Mac.

On the nerdkit USB adapter, measure the voltage on the yellow wire with a voltmeter and you will see about 3.5v. The nerdkit usb adapter is a PL2303 and it is one of the 3.3v chips that can tolerate a 5v input signal so no reduction is necessary when running the standard nerdkit. Most other 3.3v serial chips I am familiar with will not tolerate higher voltage and need a voltage divider or something to reduce the signal level from the nerdkit but only the Tx pin. Since the PL2303 isolates the TTL Tx/Rx lines from the actual USB D+/D-, it doesn't really matter what voltage the D+/D- use because the nerdkit never sees it. It's the same on MAC and Linux.

Ok interesting, thanks Noter. I actually got the data lines to trigger on the o-scope this evening and saw they are indeed at 5V, and though I'm using a different USB->Serial adapter than the NerdKit's, it's still based on PL2303 (HX), so I'm wondering if there's something else besides the PL2303 chip that could be causing a voltage difference. I think tomorrow I'm just going to give it a go with one of my spare chips and see if it works. If it does, that will be a huge plus for my project, especially if pcbolt is right about the 14.74MHz crystal working fine at 3.3V.

The datasheet for the PL2303HX says 3.3v output and tolerant to 5v on input. So you will expect to see ~5v coming from the nerdkit but only ~3.3v going to it. Disconnect it from the atmega and check it with a voltmeter. You should measure 3.3v on the PL2303 Tx and 0v on the Rx.

For some reason it's not working that way for me. If I disconnect it from the ATMega I get around 4.6V on both data lines coming from the PL2303HX. Perhaps the manufacturer who made the PCB that the PL2303HX is placed on designed it so that it only works with 5V? I tried it on a 3.3V chip anyway, and ended up frying or corrupting the chip it looks like. When I would 'make' it would go to 100% on the reading and then error out on the "writing flash" segment, staying at 0% and then aborting:

avrdude -c avr109 -p m168 -b 115200 -P /dev/tty.usbserial -U flash:w:accelerometer.hex:a

Connecting to programmer: .
Found programmer: Id = "FDL v02"; type = S
    Software Version = 0.2; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x35

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9406
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "accelerometer.hex"
avrdude: input file accelerometer.hex auto detected as Intel Hex
avrdude: writing flash (9010 bytes):

Writing |                                                    | 0% 0.00s

avrdude: butterfly_recv(): programmer is not responding
make: *** [accelerometer-upload] Error 1

Here is the exact module I'm using:

http://dx.com/p/pl2303hx-usb-to-ttl-converter-module-149859

It works fine for everything at 5V.

Now, as for the Nerdkit cable. I get 0V on both data lines when it's not connected to the MCU. Talk about strange. Both cables work fine for programming at 5V though.

Just to follow up. Turns out the chip is not fried or corrupted. Apparently my testing just "gummed up the works", as my USB->serial device stopped programming good chips @ 5V, and then disappeared from my device list altogether. After a reboot of my computer, everything is back to working. Unfortunately though, I'm still not making any progress with 3.3V programming.

Seems there is a problem with your USB to TTL Converter Module. Probably time to get another and give it a try. I would look for something that uses the FT232R instead of the PL2303 because I think the FT232 is a better chip. Either way, get a couple so you always have a spare. If you do decide to use the internal 8Mhz clock at some point you'll need an ISP programmer to set fuses so might as well get one of those too.

I have my NerdKit cable and 5 of the other PL2303HX devices that I linked. They all work great at 5V, so I don't think they are broken. I'm going to wait until my level translation IC's get here and see if I can get it to work using those, or worst case scenario I'll just unplug the 3.3V device every time I have to reprogram the ATMega at 5V, and then run it at 3.3V with no UART.

Earlier I tried using a voltage divider resistor network on the yellow pin to drop 5V to 3.3V, and used a simple switching transistor with a 10k resistor to step 3.3V back to 5V on the green wire, but that failed to communicate as well. I've checked and double checked both the NerdKit cable and PL2303HX devices and during data transfer all of them are using 5V signals.

I already have an AVRISP mkii programmer, and it works great for fuse/bootloader programming, so I should be ready to go there.

Actually I take part of that back. My NerdKit cable does do 3.5V data, but the others all do 5V, so I'm guessing they are wired for only 5V data. However, even with the NerdKit cable at 3.5V, and the MCU at 3.4V or so, the flash operation times out on "Writing flash":

avrdude -c avr109 -p m168 -b 115200 -P /dev/tty.usbserial -U flash:w:accelerometer.hex:a

Connecting to programmer: .
Found programmer: Id = "FDL v02"; type = S
    Software Version = 0.2; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x35

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9406
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "accelerometer.hex"
avrdude: input file accelerometer.hex auto detected as Intel Hex
avrdude: writing flash (9010 bytes):

Writing |                                                    | 0% 0.00s

avrdude: butterfly_recv(): programmer is not responding
make: *** [accelerometer-upload] Error 1

The PL2303 datasheet says it works with 3.3v but if none of yours do then maybe it is in the design of your converter, wish I had one to experiment with. In the meantime you could go ahead and set one of your chips to use the 8Mhz internal oscillator and see if you can program with 3.3v at a lower clock speed.

That's a good idea. I was wondering if it would work with the NerdKit cable at least using a lower clock speed. I'll try that and let you know how it works.

Woohoo. Great news! After setting the fuses for 8MHz internal operation I was able to program the MCU using both types of usb->serial adapters. I'm still sure that the other PL2303HX chips I have are communicating at close to 5V (looks to be around 4.6-4.8V), but it appears the MCU can take it just fine. Hopefully they won't cause degradation over time due to the high voltage, but if they do I'll be sure to come back and post that here.

Thanks for all of the help, Noter!

For future people who read this thread, it would appear that the conclusion is that, yes, you can use PL2303HX USB->Serial converter modules with ATMega chips at 3.3V, but you have to set the internal oscillator to 8MHz.

The way I loaded the bootloader and set the fuses for 8MHz operation:

The fuses I used for my ATMega 328P are:

lock:w:0x2f:m
efuse:w:0x05:m
hfuse:w:0xd2:m
lfuse:w:0xe2:m

Starting with the 328P Bootloader folder provided by NerdKits...

1. Open config.mk and change F_CPU to 8000000, and AVRDUDE_BANDWIDTH to 19200 (and SERIAL_DEV to your usb->serial device if it's not there already).

2. Open Makefile and set the fuses to the values above. Also ensure you have your programmer type listed in the flags area, e.g. I have an AVR ISP MK ii, so mine is:

AVRDUDEFLAGS=-c avrispmkII -pm328p -P usb

I had to add the "-P usb" for it to work on my Mac, but others may not need that.

1. Remove all .o and .hex files from the folder.

2. Make sure your MCU has the programming mode jumper attached (PIN14->GND).

3. Make sure the MCU is plugged in to your programmer and that your programmer is plugged into the computer and power is on.

4. Run "make -f Makefile.fl" to generate the bootloader (foodloader) hex file.

5. Run "make" to program the fuses and load the bootloader on your MCU.

That's it. Now you can remove your 14.7456MHz crystal, run the MCU at 3.3V or 5V, program the MCU at 3.3V or 5V, and do UART at 3.3V or 5V.

xodin -

If you'd like to experiment even further, there is another possible solution to this problem HERE, which just adds a sleep command between reading and writing cycles. This came up with Macs using the normal setup. Of course you'd have to reset your fuses again and put the crystal back in but you'd get a slightly better clock for doing USART read/writes. Most likely not a big deal.

Thanks pcbolt! That looks like it would have worked using the 14.7456MHz crystal, but you're right that for my purposes 8MHz should be plenty fast enough. It is the same error though, so that's good to know! Never thought it would have been due to my Mac.

Hey Xodin,

I received a PL2303 adaptor like yours today and sure enough it has 5v on the txd pin. After looking over the spec some more I see the the serial interface voltage is controlled by pin 4 on the PL2303 chip which is hardwired to 5v on this particular adaptor. So it is operating at full 5v and can damage your serial ports on a 3.3v atmega. With a minor mod to the adaptor you can change to 3.3v, lift pin 4 and connect it to pin 17 which is the regulated 3.3v output from the PL2303. Then the serial pins run at 3.3v which also work fine for a 5v atmega.

Noter -

I didn't notice your "mod" in the photo until now. Pretty slick.

I never imagined I would be soldering such tiny things but after a fair amount of practice with a big magnifying glass I'm able to do it. Here's one that might catch your interest, add a pin to the HC-06 and tap the blinking led so the mcu can determine connection status. Using a pin change interrupt to reset a timer/counter, whenever the counter indicates greater than 125ms since pin change, you're connected.

Nice!

I haven't tested it, but I think the master module I have has a STATE pin which is connected to the LED so I wouldn't have to re-wire that one. For the slave module I think I'd just have to add an extra header pin. Now that you mention it...I should test it out just to see if my theory is correct.

Well that didn't work. The STATE pin doesn't seem to do anything. Thought maybe it would change state when going from AT mode to connected but No Joy.

Yep, I tried that too and had the same results. I think the HC-05 has a state pin but not the HC-06. It's a bit confusing because the same little adaptor board is used for both devices so the HC-05 labels are there on the HC-06 even though they're not used.

Actually the one thing I noticed is when you pull the STATE pin to ground, it won't pair. So maybe it's just a reset pin.

I'd like to have access to the LED line. I initially was thinking along the lines of a photo transistor. I'd have to sheild it from ambient light changes but that shouldn't be hard. I don't have the soldering confidence you have as yet :-)

Here's the best doc I've found so far on these devices. It outlines both the 05 and 06.

HC Serial Bluetooth Products User Instructional Manual

I think I've downloaded that one before. The trouble is the breakout boards I have are made elsewhere and not documented very well. I've tried to trace the headers back to the main chip but many of them are hidden so I have to make some assumptions about where they lead.

When I started out with these bluetooth modules I was using 5v on rx/tx and eventually damaged the ports on one of my HC-06's so with nothing to loose I removed it from the breakout board and could easily follow the circuit. Then I found the above document which was a lucky break because it is written in English and matches the modules I found on eBay.

The moral of the story is never use 5v on a 3.3v device unless the spec sheet specifically says it is ok. It might work for a while but will eventually fail. Hopefully xodin is still following this thread and can modify his PL2303 adapter before the rx/tx ports on his atmega quit working.