7 ms·
That reminds me of a project to interface with vending machines. (We built a bookshop in a vending machine that would tweet whenever it sold an item, with autom
by genmon 5y ago
That reminds me of a project to interface with vending machines. (We built a bookshop in a vending machine that would tweet whenever it sold an item, with automated stock management.)
Vending machines have an internal protocol a little like I2C. We created a custom peripheral to bridge the machine to the web, based on a Raspberry Pi.
The protocol was defined by Coca Cola Japan in 1975 (in order to have optionality in their supply chain). It's still in use today. But because it was designed in Japan, with a need for wide characters, it assumes 9 bit bytes.
We couldn't find any way to get a Raspberry Pi to speak 9 bit bytes. The eventual solution was a custom shield that would read the bits, and reserialise to 8 bit bytes for the Pi to understand. And vice versa.
9 bit bytes. I grew up knowing that bytes had variable length, bit this was the first time I encountered it in the wild. This was 2015.
- raverbashing 5y agoWell you could bit bang and the 9 bits wouldn't be an issue. (Even if you had a tiny PIC microcontroler just to do that) This is best solvable the closer to the device in question and in the simplest way possible.
- ghoward 5y agoSorry, dumb question: what is bit banging?
- gspr 5y agoThe practice of using software to literally toggle (or read) individual pins with the correct software-controlled timing in order to communicate with some hardware. To transmit a bit pattern 10010010 over a single pin channel, for example, you'd literally set the pin high, sleep for a some predetermined amount of time, set it low, sleep, set it low, sleep, set it high, etc.
- thristian 5y agoIn order to exchange data over a serial connection, the ones and zeroes have to be sent with exact timing, so the receiver can reliably tell where one bit ends and the next begins. Because of this, the hardware that's doing the communication can't do anything else at the same time. And since the actual mechanics of the process are simple and straightforward, most computers with a serial connection have special serial-interface hardware (a Universal Asynchronous Receiver/Transmitter, or UART) to take care of it - the CPU gives the UART some data, then returns to more productive pursuits while the UART works away. But sometimes you can't use a UART: maybe you're working on a tiny embedded computer without one, or maybe you need to speak a weird 9-bit protocol a standard UART doesn't understand. In that case, you can make the CPU pump the serial line directly. It's inefficient (there's probably more interesting work the CPU could be doing) and it can be difficult to make the CPU pause for exactly the right amount of time (CPUs are normally designed to run as fast or as efficiently as possible, nothing in between), but it's possible and sometimes it's all you've got. That's bit-banging.
- londons_explore 5y agoConsider being a teacher. Thats a good explanation.
- stefan_ 5y agoThe irony is that while a tiny PIC can do bit banging easily, the mighty Pi will struggle with it.
- hazeii 5y agoI'm familiar with both, and have Pi's bit-banging at 8MHz. It's not hard-realtime like a PIC though (where I've bitbanged a resistor D2A hung off a dsPIC33 to 17.734475MHz). It's an improvement over the years, but surprisingly little since bit-banging 4MHz Z80's more than 4 decades ago, where resolution was 1 T state (250ns).
- londons_explore 5y agoThe 9 bit serial OP mentioned likely doesn't have a seperate clock line, so it is hard realtime and timing matters a lot, and I doubt the Pi could reliably do anything over 1 kHz baud with bit banging. You could do much better if you didn't run Linux.
- BlueTemplar 5y agoWe really should have moved to 32 bit bytes when moving to 64 bit words. Would have simplified Unicode considerably.
- ChrisSD 5y agoNot really. Unicode is a variable width abstract encoding; a single character can be made up of multiple code points. For Unicode, 32-bit bytes would be an incredibly wasteful in memory encoding.
- BlueTemplar 5y agoOne byte = one "character" makes for much easier programming. Text generally uses a small fraction of memory and storage these days.
- cygx 5y agoNot all user-perceived characters can be represented as a single Unicode codepoint. Hence, Unicode text encodings (almost[1]) always have to be treated as variable length, even UTF-32. [1] at runtime, you could dynamically assign 'virtual' codepoints to grapheme clusters and get a fixed-length encoding for strings that way
- jart 5y agoEven the individual unicode codepoints themselves are variable width if we consider that things like cjk and emoji take up >1 monospace cells.
- lanstin 5y agoEvery time I see one of these threads, my gratitude to only do backend grows. Human behavior is too complex, let the webdevs handle UI, and human languages are too complex, not sure what speciality handles that. Give me out of order packets and parsing code that skips a character if the packet length lines up just so any day. I am thankful that almost all the Unicode text I see is rendered properly now, farewell the little boxes. Good job lots of people.
- AnIdiotOnTheNet 5y agoThis just doesn't seem right. Granted, I don't know much about your use case, but Raspberry Pi's are powerful computing devices and I find it difficult to believe there was no way to handle this without additional hardware.
- DeRock 5y agoI’m not familiar with the “vending machine” protocol he’s talking about, but it’s entirely reasonable that it has certain timing requirements. Usually the way you interface with these is by having a dedicated HW block to talk the protocol, or by bit banging. The former wouldn’t be supported on RPi because it’s obscure, the latter requires tight GPIO timing control that is difficult to guarantee on a non-real-time system like the RPi usually runs.