| Electronics > Projects, Designs, and Technical Stuff |
| UART using or not CTS and RST signals |
| (1/1) |
| ricko_uk:
Hi, I have to connect the Raspberry Pi to a micro so the CM can program the micro. I am going to connect it using a UART. Two questions: 1) I am planning to use just the usual RX and TX connections. Any practical reasons or advantage in using CTS and RTS too? 2) regardless of CTS and RTS, can you get away with connecting only the communication signals (RX, TX) or is it better to have another signal to signal perhaps the micro to enter in boot mode? Thank you :) |
| jbb:
Ah, this sounds very familiar. In principle, just Rx and Tx would work. However, that relies on your micro to know what to do with a firmware update. If something goes wrong with the update you might brick it. A common alternative is to also connect a reset and bootloadet entry pin. This way the Pi can reboot the micro into firmware update even if it’s crashed, and the firmware update code can be contained in a small bootloader that doesn’t change often. Many micros (eg STM32) have aerial bootloaders programmed in at the factory. On RTS/CTS: flow control is often not critical these days. If both ends of the serial link can keep up then you don’t really need them. However, they could be useful if you’re going to implement sleep modes; the sleeping chip can clear its RTS line to say “I’m asleep, don’t bother me.” |
| ricko_uk:
Thank you JBB! :) Can you explain more about what you wrote: "A common alternative is to also connect a reset and bootloadet entry pin. This way the Pi can reboot the micro into firmware update even if it’s crashed, and the firmware update code can be contained in a small bootloader that doesn’t change often. Many micros (eg STM32) have aerial bootloaders programmed in at the factory." How does that work? If something doesn't go well during the updating of the firmware how does that pin/signal help exactly? Could you briefly explain the entry code/logic at micro boot-up? If the code messes up the overwriting of that very entry point would it not be irreversibly "locked/stuck"? Also how would the programmer know that the burned code burned correctly into the micro? Would that be a single pin going from the programmer (Pi) to the micro or also the same (or another one) communicating back to the programmer/Pi? Thank you :) |
| jbb:
The bootloader is a small program in a fenced-off bit of Flash memory. It’s small and dumb; generally it will only know how to program Flash memory or do CRC check on application Flash and jump to it. This way, you can reboot the chip and signal the bootloader “I want to load Flash,” and the bootloader does that. If the signal is not present, the bootloader checks the application CRC and jumps to it. This way the bootloader can erase and update the Flash used by the application with little risk; if the power cuts off part way though, the application image is trashed but the bootloader is OK because you didn’t erase it. |
| Navigation |
| Message Index |