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 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.
