A serial USB cable has an FTDI FT232 chip in it. Same difference.
Thanks
pert:
Yes. As long as you're not encountering the error:avrdude: usbdev_open(): did not find any USB device "usb"caused by the Arduino IDE running the second command too soon after the first then there is no difference. Of course running avrdude commands from the command line allows you to easily modify the commands as you like.
Here are tonights findings... BLE will setup properly with the latest Adafruit softdevice/application code only on the 3 current-revision (3) but made earlier last year boards.
All boards will work with the slightly older Adafruit softdevice/application code.
Curiously- and this really confuses me, the high fuse set to not erase the EEPROM chip upon upload via the AVR ISP MkII only works on those middle units.
On the older Rev 2 units- it overwrites, on the latest units it does the same.
On the boards that were made at the end of last year- it works as hoped.
Any ideas?
I must be missing something. At least I have continuity between the oldest and the latest... just need to get the EEPROM issue resolved (again, hah) and figure out why the MDBT40 wont program the later softdevice/app combos.
So tonights adventure included understanding that the 16MHz units work properly when set in the boards.txt as 16MHz, and get firmware set to standard baud rate of 115200.
Not sure how I was overwriting the EEPROM last night but that all seems to be settled now.
Curiously, the 10MHz boards; they only output properly in the serial output when mismatched. Either in the boards.txt at 16MHz and baud at 184320 (115200 * 16 / 10) or the inverse with the boards.txt set to 10MHz and the baud at the standard 115200.
Any idea on why that is?
I've got 3 boards now that have serial numbers programmed- just need to figure out why the BLE module wont take a newer softdevice/firmware combo. I did manage to figure out how to get the BLE module into DFU mode and update the firmware that way but it hangs all the same except on those middle boards which function flawlessly (found out one of them is also a 10MHz!)
So. Close.
bolteon:
Curiously, the 10MHz boards; they only output properly in the serial output when mismatched. Either in the boards.txt at 16MHz and baud at 184320 (115200 * 16 / 10) or the inverse with the boards.txt set to 10MHz and the baud at the standard 115200.
What do you expect to happen when you specify the wrong F_CPU in boards.txt...? F_CPU is used to calculate by how much to divide the system clock by to get the UART baud rate, so specifying the wrong F_CPU will throw off UART baud rates. It will also throw off millis() time keeping. Heck, it could even reduce ADC performance by resulting in the wrong divider for the ADC clock being selected (depending on the two specific speeds in question).