Does the compiler have memory mapped I/O - at least byte wide?
Does the compiler have memory mapped I/O - at least byte wide?
Michael,
I'm familiar with the "embedded" family of STM32 processors. On those, you need to go quite far up the ranks of processors before they start having enough pins that ST decided to implement the external memory bus.
Similarly, MOST application processors have an external memory bus. Simply because integrating 1Gb of memory onto one or two chips is best left to the companies specializing in memory chips. That said... the DRAM bus is special and will you be able to access other stuff? The answer is usually yes. Those external busses often need to interface to NAND flash, SD cards (or EMMC) and stuff like that.
The one exception that I'm aware of is the BCM2835. Because it has the memory bus broken out on the TOP of the chip for the stacked memory arrangement, that's one of the few "application processor" chips that doesn't have an external memory bus.
I'm glad my contribution has spurred you into making your own !
Have you tried your code out to see how fast it can actually toggle a pin, it is common for IO ports to use a slower bus than the processor core.
BTW - the ST ARM Cortex M processors go a quite well - up to 200MHz core clocks (400 if you count the H7 which you can't buy yet) but they also have multi-pin set and clear registers for GPIO as well as read and write. The fastest toggle rate I've achieved (measured) is 42MHz, ie 11.9ns on, 11.9ns off.
The PI core will certainly go much better (than a 200MHz M4), but the IO is more complicated and I don't have your PI expertise to know what effect this may have.
MK
This thread will be hard to follow - my previous comment was responding to your long post re. io control on the PI.
MK
Yes, the IOs could be on a slower bus. External pins are usually limited to about 50Mhz, except for special high-speed special purpose ones. So, if there is a need, you can stuff the bits into the 32-bit word in 10ns, but the pin might take up to 20ns to update.
The 50MHz limitation is not a "we have a register that updates every 20ns". Maybe there is a bus speed limitation, so that consecutive writes to the peripheral are spread out a bit. So on an STM32F405 which runs at 168MHz, I think the IO bus runs at 42MHz max. But on a processor like the one on the pi, I expect that if you want, you can run such an IO bus a bit faster, and the 50MHz is just the IO pin struggling to get the signal from 0V to 3.3V within the 20ns. (or 10ns if you take the 50MHz limit as: Can produce a 50MHz signal which requires a 100MHz edge rate).
Food for thought. Thanks for everyone's input. I personally have not been involved with the Linux software that is running on the Crystalfonz SOM I mentioned previously. I designed the external hardware to connect to the SOM and used the GPIO pins available to create an 8 bit 8080 byte bus, i.e. 8 data bits, 6 address bits, one read bit and one write bit. I designed it for up to 10 Mhz bandwidth. I assumed the software driver would have to bit-bash the read and write control signals but was naive to assume one could read/write the 8 data GPIO pins in one operation. This has not been an issue as yet but I was looking at trying to do it better on any new SOM we try. I have not tried using a Raspbery Pi and do not know much about them from the software development side of things - this is why I asked my original question, albeit the wrong question for what I was looking for. The application(s) I am involved with require low level hardware to access peripherals on an external bus AND high level stuff like 800x480 colour LCD touch screens, Ethernet and USB.
So thanks again. I think I have enough information now to look more closely at any SOM (even the Pi), so I think it would be prudent to close off this discussion at this point.
Kind regards
Michael Vos