Your latest purchase

Ahhhh, the difference an OS makes. Is there an M$ Windoze for the PI?

Chagrin:

JoeN:
Why is the Pi relatively slow?

If you want to re-run his tests on your own I think it would be interesting to either:

  1. Optimize the operating system; shut down all unnecessary processes (notably X), disable networking, etc. and see if you can get more speed.
  2. 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 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.)

IIRC it takes an 8080 2 to 4 cycles to do most anything and way more to do some things.

On a 6502 the same happens in 1 cycle. ... or 2.

westfw:

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

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. :frowning: I'd rather write code than figure out how to get a FPGA to work.

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

What you do with the data is going to make a difference. Hope it's not high-res face or voice recognition.

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.

Are you making square waves or reading waveforms?

GoForSmoke:
Are you making square waves or reading waveforms?

You talkin' to ME? :slight_smile: 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.


Rob

today i get my 68332 cpu

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!)

I bought 3 HC-SR04 Ultrasonic range finders from AZtronics for$5 each!!!

They are really accurate, easy to use, but you can see the side lobes coming into play.

I figured for $5 a piece I'd give them a try.

Because the output is digital there is a lot of "information" that you'll miss, such as the "quality" of the echo.

The way I'd normally do it gives me an idea of what the echo came from, just like watching an old school "fish finder" on a boat.

The other surprise I got was my free sample from Coridium!
One of these!

http://www.coridium.us/prod-specs1.html

I was thinking of making a shield for it!

Overkill?

Hell yeah!

a 50Mhz ARM sitting on an Arduino seems like a good idea! 8)

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.


Rob

It's not a Basic interpreter!

The HackaDay article was really misleading, it runs compiled code.

HackaDay seem to be going down hill at a rate of knots!

The "just plug an FTDI cable in and pretend it's 1986" was a crock.

In the comments section the bloke from Coridium address's a few of the claims the writer made.

Yes I see, it's a compiler.


Rob

cyberteque:
HackaDay seem to be going down hill at a rate of knots!

yea ... I really should start writing for them again, then it will go down 3x as fast hehe

retrolefty:
A total steer by wire would be pretty scary for me

Well, now now you can find out if it really would.

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! ]:smiley:

I broke down and bought a lamp/magnifier that has 36 white LED's rather than a weird circular flouro tube.
It seems whiter than my last illuminated magnifier, maybe a tad brighter as well.

Certainly runs cooler than a flouro one!

Beginning to realise I need glasses!