On Wed, Sep 20, 2017 at 2:39 PM, Douglas Quagliana <[email protected]> wrote:
> I don't think there's a speed issue. They benchmarked the speed of the > GPIO pins on a Raspberry Pi and they were able to toggle the output pins at > 22 Megahertz using an optimized program written in C. See > > http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ > > The Model T's 8085 CPU is running way slower than 22 Megahertz. I would > think that there's plenty of time to read the GPIO pins, decode the > address, set the data lines and flip the OE pin (or whatever else needs to > be set). No? > > I thought there might be an electrical incompatibility (wrong voltage, > can't source/sink enough current) or something else that prevented a direct > hookup between the GPIO pins and the option ROM pins. > > C'mon... Nobody even tried this yet? > > Douglas > Actually, 22Mhz is not all that far away from 2.4mhz. Factor of 10. "This is basically the “upper limit” for any signalling one can hope to achieve with the GPIO pins – real-life scenarios where processing needs to be done would need to aim for some fraction of these values." And you have more than one line to deal with. And then Linux is not going to make it easy for you to run real-time. If you're user land, you run when the scheduler wants you to run. You would need to look into RT linux or a special kernel driver. If possible, some minimal RT kernel instead of Linux. But then you lose the full networking stack the Pi offers. So, maybe? I guess. And a little more hardware might help so you can leave one set of outputs constant while you prepare for the next cycle. -- John.
