I just bought some Pro Mini 328 5V 16MHz compatible boards off eBay (I hope that's not the problem).
I can't load a sketch on any of them. They all behave the same and I don't think all of them would be bad.
Before connecting them to the FTDI board, I checked the pinout on the Pro Mini board and found that I needed to switch a few wires around. Actually, all of them. Made sure to get TX and RX correct. The green LED pulses like a heartbeat while the board is powered up. I'm just supplying power through the FTDI board. When I try to load something on the Pro Mini, the green light has a few rapid flashes like it's communicating but then goes back to the heartbeat while the Arduino program times out. Normally, when programming, the LED on the FTDI board flashes a pattern, but it doesn't in this case. I have the 'Arduino Pro or Pro Mini (5V, 16MHz) w/ ATmega328' board selected but I've tried almost all the others. The JeeNode works on Uno for some reason.
I came across a thread where some people had success by hitting the reset at a particular point in the programming procedure but this didn't work for me.
I hope someone here can point me in the right direction.
coolpins:
Actually, the power LED is red and it is on steady. If you look at the diagram of a Pro Mini, you'll see the green LED is tied to PB5(SCK)
True, except that you didn't buy a pro-mini. You bought something on eBay which may be based on the pro mini, but no guarantee. So I wouldn't rely on the schematic unless it came from seller (except when buying on eBay).
Usually new Arduino's are loaded with the Blink sketch that flashes the on-board LED on/off once per second. Sounds like your not managing to upload a new sketch. Do you have a schematic of the boards you bought and the pinouts of your FTDI device (BUB?)
Before connecting them to the FTDI board, I checked the pinout on the Pro Mini board and found that I needed to switch a few wires around. Actually, all of them. Made sure to get TX and RX correct.
Looking at the BUB and the Pro Mini pinout on here and if that's what matches your setup then I cannot see why you needed to swap FTDI wires around.
Riva:
Usually new Arduino's are loaded with the Blink sketch that flashes the on-board LED on/off once per second. Sounds like your not managing to upload a new sketch. Do you have a schematic of the boards you bought and the pinouts of your FTDI device (BUB?)
Yes, it looks like it's running the Blink sketch. Not uploading a sketch is what I was trying to describe. I don't have a schematic of the boards but it's easy enough to follow the traces and verify with a continuity test when needed.
Riva:
Before connecting them to the FTDI board, I checked the pinout on the Pro Mini board and found that I needed to switch a few wires around. Actually, all of them. Made sure to get TX and RX correct.
Looking at the BUB and the Pro Mini pinout on here and if that's what matches your setup then I cannot see why you needed to swap FTDI wires around.
They didn't use the same header pinout for some reason. Would have been nice.
Before connecting them to the FTDI board, I checked the pinout on the Pro Mini board and found that I needed to switch a few wires around. Actually, all of them. Made sure to get TX and RX correct.
Not always simple or straight forward. Relying on the names TX and RX as used by the BUB and the Arduino can be problematic as there is not a standard definition of if a signal named RX is an input to a specific board or a output. That may sound strange but it's true. To wire up between an external USB serial converter module or cable you must know which pin is an electrical input and which is an electrical output pin. The arduino uses the convention that the signal name they call RX is an input to the AVR and TX is an output. This of course can be validated by looking at the datasheet of the AVR chip being used and the arduino pin number being used. For a given serial converter one would need to trace the signal they name RX back to the USB chip to see if it's an output or input pin. Usually the document for the USB serial device does not go down that far in detail. So you either guess or use test equipment and see which pin outputs and which inputs. If you didn't measure you may have simply guessed wrong on a 50/50 bet.
Before connecting them to the FTDI board, I checked the pinout on the Pro Mini board and found that I needed to switch a few wires around. Actually, all of them. Made sure to get TX and RX correct.
Not always simple or straight forward. Relying on the names TX and RX as used by the BUB and the Arduino can be problematic as there is not a standard definition of if a signal named RX is an input to a specific board or a output. That may sound strange but it's true. To wire up between an external USB serial converter module or cable you must know which pin is an electrical input and which is an electrical output pin. The arduino uses the convention that the signal name they call RX is an input to the AVR and TX is an output. This of course can be validated by looking at the datasheet of the AVR chip being used and the arduino pin number being used. For a given serial converter one would need to trace the signal they name RX back to the USB chip to see if it's an output or input pin. Usually the document for the USB serial device does not go down that far in detail. So you either guess or use test equipment and see which pin outputs and which inputs. If you didn't measure you may have simply guessed wrong on a 50/50 bet.
Lefty
I agree on the RX/TX labeling issue. Some times it's labeled according to the on-board device and other times labeled for what you need to connect to. I went by what has been working on my other boards and the chip pins that were routed to the RX and TX. I prefer not to guess at things. Comes from wanting to keep magic smoke contained.
Since I get some response from the controller when attempting to program, I think I have it in the right direction.
Before connecting them to the FTDI board, I checked the pinout on the Pro Mini board and found that I needed to switch a few wires around. Actually, all of them. Made sure to get TX and RX correct.
Not always simple or straight forward. Relying on the names TX and RX as used by the BUB and the Arduino can be problematic as there is not a standard definition of if a signal named RX is an input to a specific board or a output. That may sound strange but it's true. To wire up between an external USB serial converter module or cable you must know which pin is an electrical input and which is an electrical output pin. The arduino uses the convention that the signal name they call RX is an input to the AVR and TX is an output. This of course can be validated by looking at the datasheet of the AVR chip being used and the arduino pin number being used. For a given serial converter one would need to trace the signal they name RX back to the USB chip to see if it's an output or input pin. Usually the document for the USB serial device does not go down that far in detail. So you either guess or use test equipment and see which pin outputs and which inputs. If you didn't measure you may have simply guessed wrong on a 50/50 bet.
Lefty
I agree on the RX/TX labeling issue. Some times it's labeled according to the on-board device and other times labeled for what you need to connect to. I went by what has been working on my other boards and the chip pins that were routed to the RX and TX. I prefer not to guess at things. Comes from wanting to keep magic smoke contained.
Since I get some response from the controller when attempting to program, I think I have it in the right direction.
Good that you see/understand that there can be naming convention problems, which may not be the problem in your case. However basing it being right just by that fact that the led blinks after you hit upload may not be deterministic of 100% correct wiring because it's the USB DTR signal changing that resets the avr chip and starts the bootloader code which blinks to show it's active. If the bootloader does not see a valid 'lets get started character' from the USB connection after a given time-out value, it will then go ahead and jump to the prior blink sketch that has be loaded on your boards at some prior time.
To complicate even more the symptom cause could be because the vendor installed a different bootloader then the one 'real' arduino Pro mini uses. When you select the board in the IDE that also defines what baud rate the bootloader code on the attached board is using and expecting. I own a couple of clone Nano boards that I have loaded with the Uno bootloader which means I have to select the Uno type board to upload to them. If I select nano board I will get the type of error you are seeing. Not saying that is what you might be dealing with, just that it's another possibility which can make troubleshooting this symptom more difficult then it might first appear.
I just looked at the datasheets and boards to verify I was correct in which way it needed to be connected.
By God, I was absolutely right.
However, when I verified my work AGAIN, I saw that I got it BASS ACKWARDS.
Thanks for the help guys.
Now to go find my Dunce cap and see what else I can get wrong.
