Timeline for Why FTDI and not AVR with built-in USB controller?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 11, 2016 at 8:04 | comment | added | user36129 | @alexgray: Wow, you're really talking in extremes there. I don't think I was trash-talking anything; these are just the typical kinds of objectives people have in product design. I've dealt with projects that optimized around pretty much all combinations of these points. For hobby projects there may be a Trump vs. Sanders approach to resolving 'do I or do I not take an FTDI RS-232 bridge?', but in real engineering you should really just objectively consider all the pros and cons and come to an optimal conclusion. | |
| Mar 8, 2016 at 18:57 | comment | added | alex gray |
Wow, your tl;dr paragraph sure was a surprise ending... You trash-talked firmware-only USB/serial stacks (albeit with extremely valid points), and then BAM... "only an idiot would use FTDI". Hilarious. Loves it!
|
|
| Jan 23, 2016 at 10:20 | vote | accept | MrBit | ||
| Aug 21, 2014 at 18:47 | comment | added | markrages | @ChrisStratton's comment points out another issue: USB devices are an order of magnitude harder to debug than simple UART serial. So it speeds development and removes unknowns to leave the USB end of things to the debugged, working FDTI chip. Obviously the economics changes with quantity, but for small production with time pressure the FDTI solution is usually better. | |
| Aug 21, 2014 at 17:20 | comment | added | Chris Stratton | Even if a project is on a microcontroller which has built in USB interface and the plan is to use that, it's still worth having a header to access the UART pins, as you can trivially get useful debug output from that while trying to get the USB code to work. | |
| Aug 21, 2014 at 17:03 | history | answered | user36129 | CC BY-SA 3.0 |