If you want to re-run his tests on your own I think it would be interesting to either:
Optimize the operating system; shut down all unnecessary processes (notably X), disable networking, etc. and see if you can get more speed.
Run multiple instances of the pin toggling program on seperate pins. One process might be able to toggle a pin at 20MHz, but I'd expect two processes to toggle pins at greater than 10MHz.
If you want to re-run his tests on your own I think it would be interesting to either:
Optimize the operating system; shut down all unnecessary processes (notably X), disable networking, etc. and see if you can get more speed.
Run multiple instances of the pin toggling program on seperate pins. One process might be able to toggle a pin at 20MHz, but I'd expect two processes to toggle pins at greater than 10MHz.
I'm not sure I agree with you a hundred percent on your computer architecture work, there, Chagrin. Operating systems don't just slow down the system a certain percentage all the time, the OS is either being executed or one of the user processes is, at least on a single core system. So a user process runs at 100% until the OS runs at 100%, you will see it run full speed and then not at all when something else is running. There is no way to swap it in and out so fast that you would just get the smooth set of square waves shown in my link. For the same reason, two processes will make no difference at all on a single core system. In fact, I see no way two cores could share the same IO pin anyway, they would step all over each other, you wouldn't get a faster wave, you would get a freaking mess with the pin shorting itself a great deal of the time, not that any architecture would allow for this.
I think that you can get a minimal OS to run its tasks always quicker than a certain length of time and be able to count on your task to run at some frequency. Maybe that can be tuned with a tunable OS?
Also, I've programmed and run a whole lot to run on single-tasking (sometimes with TSR's) DOS and there's a lot to be said about your program having the system to itself. Like being able to run a business on 10 Mz and slower 8080 to 8088 CPU's, or 16 Mz 80286 with terminals... at all.
DOS is an OS.
DOS is a "program loader."
Not that that's a bad thing, nor does it disqualify it from being an "operating system."
If RPi is toggling a pin at 21MHz, that's without the linux operating system being involved.
Talking to IO in fast system is always slower than the internal cycle time. Switching a pin at (relatively) high power at the edge of your circuitry and with a potentially significant load capacitance is "difficult."
(You also don't want to look too closely at how slow that RAM memory access is, on cache misses.)
DOS is a "program loader."
Not that that's a bad thing, nor does it disqualify it from being an "operating system."
If RPi is toggling a pin at 21MHz, that's without the linux operating system being involved.
Talking to IO in fast system is always slower than the internal cycle time. Switching a pin at (relatively) high power at the edge of your circuitry and with a potentially significant load capacitance is "difficult."
(You also don't want to look too closely at how slow that RAM memory access is, on cache misses.)
OK, that is something I suspected and hoped was not true, but thanks for the information. On the Atmel chips you can get a square wave at clock divided by four, 21Mhz on a 700Mhz system is clock divided by thirty three. I was hoping that the Raspberry Pi was a cheap and simple route to working with higher throughput chips, like high-speed ADCs with parallel interfaces (e.g. 8 bit 100Msps), but I can see that was a pipe dream. I'd rather write code than figure out how to get a FPGA to work.
You might be able to connect those via the memory interface, or via some sort of DMA scheme. But you probably can't get 100MHz; that's only 10ns for each byte, which is down near the propagation delay for individual logic-gate chips...
GoForSmoke:
What you do with the data is going to make a difference. Hope it's not high-res face or voice recognition.
Nah, I had some dumbass idea to make a simple oscilloscope out of it. Just something to look at dv/dt.
westfw:
high-speed ADCs with parallel interfaces
You might be able to connect those via the memory interface, or via some sort of DMA scheme. But you probably can't get 100MHz; that's only 10ns for each byte, which is down near the propagation delay for individual logic-gate chips...
In the end if I can't get a microcontroller that can keep up I am thinking of a pure logic solution that just plows it into static RAM once the trigger voltage is hit, maybe with a CPLD or an FPGA, and then have the microcontroller read it out of memory and analyze it. I have to figure all that out, it is outside of my skill level right now but probably not for very long.
GoForSmoke:
Are you making square waves or reading waveforms?
You talkin' to ME? I will assume so...
I would be reading, not writing, if I was looking to pull data off an ADC. I was just using the data the guy posted about square waves being the likely upper limit for reading bits off the GPIO pins as well as writing to them. I am not sure if that is true, but I am going with that for the time being. My Raspberry Pi arrived from Newark today so I will have to get an image ready for it and see what it can really do.
It may be possible to read at 100MHz for long enough to take a useful sample, but getting a 100MHz ADC working well will be a challenge I think, you won't be able to play with is on a breadboard at that speed.
I played with a similar idea a while back, I eventually decided to use hardware for the sampling into external RAM and a fast uC for triggering etc.
That said some processors have a camera interface (I think that's what it's called), most notably the PICs. AFAIK this is designed to read a parallel port directly and DMA the results into memory. That may be a good option.
Isn't that a bit old? Shouldn't you be looking at ColdFire microcontrollers instead? (ok, I haven't checked whether there's a Coldfire+TPU version. There ought to be; 68332 is getting ancient!)
I have a 68331 development board around somewhere. It's left over from an actual 68331 development project that I was pretty deeply involved in (the cisco-500 Terminal Server!)
Being as the LPC1114 is the only DIP ARM around I'd say it will be a popular chip. You can get in a TSSOP as well and that will fit inside the DIP footprint IIRC. So you could make a board that allowed for PHT and SMD, one for hobbyists/protoyping and the other for production.
Coridium have loaded a BASIC interpreter, maybe Picaxe had better look out. I'd post about this on their forum but they are very touchy about posts regarding other products and they get summarily deleted.
Japan's Nissan Motor Co plans to equip some of its luxury cars with a system to control steering electronically, rather than mechanically, the first time so-called "steer-by-wire" technology will be used in mass-produced vehicles.
And, in theory, you could hook an Arduino into that too! ]