Bitbanging GPIO was actually I think the solution in the RPi code. I didn't look at the methods involved in depth, but that's what it seems was going on. So that was my plan, to use the PRUs to generate the bitstream to the tracks. So here is what I'm thinking: use the PRU to send the bitstream. Have a command buffer that the PRU reads from and that the software copies new packets into. In the event that there are no commands in the buffer, the PRU continues to send out the same packet it has been sending or some default packet that will maintain power to the track at all times. I would guess that the memory transactions between the PRU and the DDR3 onboard memory would be plenty fast to support the timing accuracy I need.
As far as the other hardware, I'm planning to build that circuit as I learn more. I do know the basics of electrical engineering, but in total honesty I am still very much trying to cut my teeth on the more advanced stuff so I am still trying to determine what to do. The idea of using the h-bridge (a TI LMD18200) came from an arduino-based solution, but in truth I hadn't analyzed the circuit to see if it would fit this need. So off to the drawing board there. On Sun, Feb 7, 2016 at 4:31 PM, William Hermans <[email protected]> wrote: > Well, I had assumed you're an EE of some sort, or at least have a decent > electronics background. But from memory, each GPIO pin on the board can > only sink 3-5ma current at most. Depending on which pin it is. So this > means you're going to need an external power source no matter what. Which > means, maybe a buffer, maybe a transistor, plus an external power source > this buffer or transistor "switches". Anyway, I'm no EE, so excuse the > rough explanation here. > > So, PWM I think is out of the question. If I understand what is going on: > Which seems to be signaling over the tracks ? You tell me. But in this > case, there are only really two options. > > The first option, would be to use SPI for the signaling. Typically though, > to use SPI in this manner is usually for "high speed" stuff. Which it does > not seem you really need high speed for this. Also, I've never used SPI in > this manner personally, and thinking of all the different things needing be > done . . . it seems overly complex. But certainly possible. > > > The second option would be to bitbang GPIO. First, in this case I > personally would opt to use one of the PRU's. Second, I would probably at > least initially hack one of the DDR3 to PRU examples to do this. By this, I > mean you write a bit pattern to memory, the PRU grabs it, and "spits" it > out over a GPIO pin. I think here is where it would start to get really > interesting for me - Since there would be a lot to consider, and learn. > Because this value you write to memory could also be a bit field containing > the value, GPIO timing, and a repeat value( as in how many times to repeat > ). > > Whats more in the context of the PRU, reading / writing to DDR3 memory can > be comparatively slow. Since I believe this would be done over the L3 > interconnect. But it very well could e more than enough "speed" for your > application. However, if it is not. Then it *should* be possible to mmap() > the PRU's shared memory. Where I believe the PRU's have single cycle reads > / writes. > > Anyway, thats a really high level way of looking at how to solve the > problem. Also since I have not read about the spec, and have not > experimenting with my idea. There could be more to consider. > > On Sun, Feb 7, 2016 at 1:32 PM, Benjamin Melikant <[email protected]> > wrote: > >> Well I was going to use said conversion technique because each decoder >> soaks ~500mA and needs at minimum 8 volts to work, prefereably somewhere in >> the +-15 to +-18v range. So if I wanted to run 4 -5 locomotives at a time, >> thats 6 amps minimum ability to the track (just to err on the side of >> caution.)There is no way to support this kind of power drain from the board >> itself (neither high enough voltage nor amperage), so either way I will >> have to use a booster of some kind. I chose the method above because there >> are already working solutions that use it. It sounds too like it works >> pretty well, but I really am not too familiar with other techniques for >> doing this kind of thing so I would be very grateful to see an example of a >> different method. I would assume that you would use PWM through an h-bridge >> rather than sending a digital high / low? I look forward to hearing your >> plan. Thank you! >> >> On Sun, Feb 7, 2016 at 3:24 PM, William Hermans <[email protected]> >> wrote: >> >>> Sounds as though the packets are sent electrically through the tracks, >>> which is . . . well pretty ingenius, but not totally unexpected I guess. I >>> had not considered that based on your first post. Because it seemed as >>> though you were implying switching a GPIO on, and off several times, to >>> "send" 15vdc out of a DC/DC converter of some type. Which again, seemed >>> like a really "cheap" way of attempting PWM. >>> >>> Anyway, I have a pretty decent idea of implementing what you're talking >>> about, but am busy at the moment, and the post might be fairly lengthy . . >>> . i'll make a new post once I'm able. >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "BeagleBoard" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/beagleboard/7385vSRF5DY/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/7385vSRF5DY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
