My project involves several hundred MIC5841 driver chips which I control from a Raspberry Pi. They are organized onto circuit boards with 13 driver chips on each board. There is one input port which brings in the clock and data lines, and there are two output ports to send them to two more boards, daisy-chaining them. I thought it would be a trivial matter to find a transistor that would refresh the signal after it arrives at each new board, but have been stymied by it for months. The signals orignally come from the Raspberry Pi at 3.3 volts, but the resulting signals need to be at 5 volts. Would love any suggestions!
Hi Kelvin,
I would suggest to start with some signal buffers. Here is a link to the ones we have :
Signal Buffers
Hello Kevin,
I’m about to embark on a very similar project, except it is just 6 MIC5841’s all on 1 board. I am planning to buy 4 channel logic level shifters, there are several marketed by the people selling boards for the RPi. SparkFun do the BOB-12009 which DigiKey also sell. The idea is to drive them directly from the Pi but I can’t see any reason why they could not be used between boards as well. They will output a signal level which is set by a reference pin, 5V in our case.
I’m not a very experienced programmer - would you be happy to explain how the code works that drives the GPIO pins for the 4 lines which the 5841 needs?
Thanks,
Thomas.
1 Like
Hi Thomas,
I have a couple of those logic level shifters, and used them for a while. There is a limit to how many times they can refresh a signal, but I didn’t really test with them and don’t remember to many details there. I’ve gone a different route.
The GPIO on the Raspberry Pi is incredibly easy to use. You just have to have the address of the GPIO in a register. I’m still using an older model for my project, so that address is 0x20200000, the model 3 would be 0x3F200000, I believe. Then you just or in the bits for the pins you want, and store the value at 28 (decimal) off that register to turn them on and 40 to turn them off. You should download the manual for the processor and read the section on the GPIO pins.
But having said that, I am a very experienced assembly programmer and while turning the pins on and off is easy, putting together complete messages to control the 5841s is more complex and debugging it can be a challenge. You have to come up with a timing strategy which I have done by decrement and branch loops.
Good luck and I’d be glad to answer any other questions. Maybe those answers weren’t very clear.
Kelvin
1 Like
Hello Kelvin,
It sounds like this is going beyond my level of coding skills, I’m basically a novice and won’t be able to go anywhere near assembly.
Am I right in assuming there is no way this can be done in Python?
Admittedly what has stopped me so far embarking on this is the uncertainty whether there is a relatively well trodden route to do this with fairly basic resources.
Having spoken to a colleague the timing concept is probably the greatest worry i.e. generating a steady clock signal and keeping the data pulses in sync with that.
Perhaps this is best left alone…
Kind regards,
Thomas.
Hi Thomas,
Of course, the clock signal does not have to be steady. The 5841s don’t care about that. One clock signal could be 300 ns long and the next could be 3 seconds. I’ve done this. But the data does have to be in sync.
I think you could do this in C just fine. I’ve never used Python, so I shouldn’t dismiss it as a possibility, but high level languages get out of touch with the hardware, and can get extremely inefficient which could make it difficult to get enough data throughput, depending on what you want. They make the starting easy, but the ending can get very difficult.
If you are short on time or enthusiam, then maybe the project isn’t for you. But otherwise don’t shortchange yourself. There are manuals to read and sample code and people to ask questions to, and you have no idea what you can do until you try. And even if you fail, you would still learn a lot.
Kelvin
Hello Kelvin,
What I’ll probably do is get a spare RPi and have a play, with a scope on the IO pins. That should show relatively quickly if my planned approach is feasible, or what I may have to do to make it work.
Thanks and best regards,
Thomas.