It usually is, no point using I2C or SPI unless there's some advantage to it - and serial is far easier than either, using hardware or software.I'll need to check the PIC datasheet, but it seems to me that their advanced serial ports have built-in support for I2C and SPI in addition to regular UART/USART. I'd forgotten that I2C needs to send address data. That may add unnecessary overhead, since I only need to communicate with one device. Maybe plain old UART will be best after all.
I disagree with this. SPI send and receive can be bit banged in 10 lines of code and is super simple and isn't timing dependent. For chip to chip communication it would always be my go to if I could spare the extra GPIO lines it needs.It usually is, no point using I2C or SPI unless there's some advantage to it - and serial is far easier than either, using hardware or software.
Assuming you've got devices that already require I2C, then it's a great idea, as it's a great saving on pinsI like I2C because we can use the SAME two pins on the uC chip for several peripherals. That saves pins for other uses.
Hi,After Pommie mentioned ready made converter cables, I did a bit more searching, and found that Staples has several listed—some under $5. So, I took a trip to the local store to see if there were any in stock. Unfortunately not. So, I've placed an order with DigiKey for the FTDI breakout board, because I'll have it overnight. I'm too impatient to get it anywhere else.
This USB to serial interface thing seems like it was invented as a stop gap measure to deal with legacy serial devices when USB first arrived on the scene. That's over 15 years ago though, and it appears that these are still nearly as popular as ever. I'm not surprised, because implementing even the simplest USB protocol, the HID device, is an enormous amount of work. If you don't need anything more than what a serial interface can provide, then why complicate things. However, I'm curious whether anyone here has done any projects with the USB module on a PIC.
I have built a PIC programmer with PIC16F1454. It can program 1233 different PIC devices and works faster than ICD3. The main goal for this project was to provide hardware debugger for the development system I'm working on (not ready yet). It also can work as USB-to-UART translator with up to 2MBaud speed, but since HID interface has speed limit of 64KB/sec, sustainable transfers are only feasible with 500K baud (or 460800). The chip can be installed on a board and work both as a programmer (to replace bootloader) and USB-to-UART converter (to replace FTDI chip or similar). There was enough program memory on this PIC to accomplish all this, even some left. Cannot post the link as I think it is against forum rulesI'm not surprised, because implementing even the simplest USB protocol, the HID device, is an enormous amount of work. If you don't need anything more than what a serial interface can provide, then why complicate things. However, I'm curious whether anyone here has done any projects with the USB module on a PIC.
Considering that Microchip makes a chip similar to the FTDI USB/serial converters (eg., Microchip part # MCP2200), I wonder why they don't integrate this function into some of their PICs.Hi,
Sorry it took me so long to get back here.
I have read that with the PIC 16F1455 chip (which has USB pins +D and -D right on it) requires HALF the program memory to hold the USB code (driver). That's nuts if you ask me. Also, Microchip might be charging for the license for that code depending on how it is to be used (personal/commercial).
The USB code certainly doesn't take anywhere near the half of the memory. Whoever told you that is not good at writing code. When written well, the USB code doesn't take much space, especially if USB class is simple, such as HID or CDC (serial). The hardware USB controller on the PIC does most of the work for you.Maybe they thought the code would be smaller when the designed the 1455 chip. Later they found out i was more complicated than they thought
FTDI chips also require drivers to be installed, but Windows can do it automatically. Microsoft certainly screwed up by not making CDC drivers standard up until Windows 10. If they did better job with CDC drivers, there would be much less HID devices out there, and much more CDC.We dont need to "install' problems along with our solutions.
These are just FTDI clones. There was an interesting story that FTDI altered their drivers so that they would kill Chinese FTDI clones. Turned out that lots of their genuine customers were using these clones thinking they were genuine FTDI chips. FTDI had to roll this back and they no longer kill chips with their drivers.Geeze, even the cheap chinese chips do better than that.