1. Home
  2. Embedded Programming
  3. A little Rabbit test for me?

A little Rabbit test for me?

I'm somewhat interested in using the Rabbit 3000 in a product. However, I need to compare performance against an ARM chip which is only a little more expensive, and decide if it's worth the effort. I

*really* don't want to spend the money on a development kit which I might never use again after this one test.

My benchmarking applet is an embedding-tweaked port of the JPEG6B reference library, with a custom memory manager and an embedded piece of representative image data so a filesystem isn't required to run the test. What I'd like is for some kind person to turn on whatever speed optimizations the Dynamic C compiler offers, build and upload the code, and measure the time between printf("start\n"); and printf("stop\n");. This test is macroscopic enough that a stopwatch time estimate is more than adequate. What I'm looking for here is the difference between three seconds, ten seconds, or thirty seconds, and it's a test of the compiler's view of my code as much as the core.

The advantages I'm seeking in Rabbit are slightly (VERY slightly) lower cost, slightly simpler board layout, lower power requirement and an easier EMC pass, since this appliance must get FCC/CE/UL if it's to be saleable.

By the way, if the response to my posting is "Dynamic C won't compile the JPEG reference sources without extensive tweaking" then thank you

- that's what I needed to know - Rabbit is out of the question in that case!

If you'd be willing to help me out, then please either post here or email. I need a couple of days to get my sample app pruned enough (it's an excerpt from an old piece of firmware that is still quite jealously guarded), and then we can begin.

BTW, I'd also be interested to know if anyone is trying to maintain a project that shares common code modules between a Rabbit device and an "other" device whose firmware is built with gcc. As far as possible, I'd like to keep this new device sharing code with existing products, and all our existing products are built with gcc.

Reply to
Lewin A.R.W. Edwards
Loading thread data ...

Can't help directly, but the difference *should* be chalk and cheese, with a Dhrystone performance of about 6,500 / s on the rabbit at about 50MHz and about 75,000 for even an Arm7 at equivalent clock frequency (and more like

150,000 at 100MHz). Now if it was a Rabbit 2000, I could help.

We have an ongoing campaign to exterminate rabbits down here.

Cheers Alf snipped-for-privacy@remove.the.obvious.ieee.org

formatting link

Reply to
Unbeliever

Also Dynamic C, while a C-like language ain't C. It doesn't have the normal .h and .c files, instead having its own .lib source files which are included into the one big source file at compile time. You'll either have to combine all your files into one or painstakingly convert any supporting modules (the ones that don't contain main()) into Dynamic C library files.

Some other differences from C are: initalized variables are constants. static variables are not initialized to 0 you can't use arguments in indirectly called functions #if defined and converse not supported no bit fields

don't know if any of these affect you.

Cheers, Alf Katz snipped-for-privacy@remove.the.obvious.ieee.org

formatting link

Reply to
Unbeliever
[...]

I suspect, then, your answer is "Dynamic C won't compile the JPEG reference sources without extensive tweaking."

However, Dynamic C isn't your only choice with the Rabbit. See

formatting link
I haven't tried it, and I really don't know anything about it other than they claim ANSI compatability. But it's probably worth a look. Maybe they can run your code for you...?

Dynamic C is OK if you have a small amount of code that doesn't need to run anywhere else. Otherwise, forget it.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

Just to clarify something here: My aim is not to determine exactly how much faster the ARM chip is. The aim is to determine if the Rabbit is, subjectively, fast enough for the application in question. The ARM is known to be overkill.

Reply to
Lewin A.R.W. Edwards

Hi Dave,

Okay, that's pretty much forced the issue. I'm not able to spend anything extra on tools for this project; I have no budget for it. I have one other 8-bit candidate to evaluate but it seems likely I'll use the ARM part. The upside to the ARM part is that it's all-in-one (flash, SRAM). Downside is it will be harder to get the hardware debugged. Oh well.... :)

Thanks for the reply.

Mmm... we don't have the manpower to keep two totally radically different code streams up-to-date. And the "Rabbit-candidate" project is definitely the lower priority of the code streams. So it looks like ARM for me. Ho, hum :)

Reply to
Lewin A.R.W. Edwards

I'm now sure, this is a crazy test! and is testing nothing at the end.

Gerard

Reply to
Gerard

Grrrrrrrr. It is in NO WAY a crazy test. It is an *extremely relevant* and *proven highly predictive* test of the ability of Rabbit to perform adequately a task that very closely simulates my target application, which happens to be decompressing low-resolution JPEGs. Likely, it has less or no useful predictive capability w.r.t. (say) cracking crypto keys or sequencing rat DNA, but that's totally irrelevant to me. I could care less about how the CPU suits someone else's application - I'm interested in how it works in mine.

I did not pick the benchmark applet or the source data arbitrarily. I have found from experience with testing numerous candidates that simply testing the 6B ref source in fast integer mode over a complex image provides a very accurate way of estimating the overall system performance, even though the real application has to implement a filesystem and post-scaling of the data. For example, if CPU A takes 1 second to run my reference algorithm over my reference data, and CPU B takes 3 seconds, I know that the *total* time required to run my actual application will be approximately 2.5-3x as long if I build in CPU B. This predictivity has been adequately true for tests on Dragonball, MIPS, ARM7, Geode (x86), Via Eden (x86), ARM7 and PowerPC, so I see no intrinsic reason why it should be different on Rabbit. The only big unknown is the Dynamic C compiler, which appears to be an insurmountable stumbling block anyway, so I'm glad I asked before buying a useless EVB.

This whole situation is exactly analogous to my asking someone the following question: "Can you please dig a 1 cubic meter hole using your shovel, and tell me how long it took? I need to dig a 10 cubic meter hole, and I have a week to do it. I have the option of buying a shovel or renting a backhoe. I know the backhoe will be faster, but I also know the shovel will be cheaper. Because I'm poor, I need to know if the shovel will allow me to complete my task in the allotted time".

Reply to
Lewin A.R.W. Edwards

thanks, that was very helpfull. I was planning on using the rabbit products, but the +-$200 price tag for a dev kit with Dynamic C included is a bit much for me, and spending $200 (or more) merely to evaluate something is beyond my budget right now.

(200USD = +- 1500ZAR, and the salary of a developer here in SA is +- 10000ZAR p/m).

Is there a link to *all* the deviations of Dynamic C from ANSI ? I looked for one on the rabbit website, but didn't find anything.

tia goose,

Reply to
goose

These could be helpful:

formatting link
formatting link

I have used Rabbit 2000 and Dynamic C premier 7.32P in one project and I won't use it again. This compiler/linker/locator is way too buggy to do anything bigger than "hello world" application and I had to debug TCP/IP stack myself to get it work. Plus million smaller bugs. Blahhh... I don't know if v8 is better, at least it should have somewhat better UI.

K0nrad

Reply to
Konrad

formatting link

"Porting to Dynamic C". Don't get me wrong, it's not a bad language per se, has lots of I/O predefined which makes coding from scratch a breeze, but the name might give you the false impression that it's C. Still it's probably easier to port from C to Dynamic C than it is to port from older versions of Dynamic C to newer ones. Yeah and the Aussie dollar (aka pacific peso) isn't too much better than the rand.

Cheers.

-- Alf Katz snipped-for-privacy@ieee.org

formatting link
(03) 9781 2341 Mob. 0419 898 834

Reply to
Unbeliever

as i understand you search for possibly cheapest micro with at least 20bit adress space. look ez80f92 from Zilog, it has ANSI C compiler and 16mb adress space. also some 8051 derivatives have 20 or even23 bit PC.

r.

Reply to
raivo leini

One of the big problems I have with these modules is the lack of a file system. The static storage of content data with that crazy compiler.

There are a lot of other modules with 'normal' compilers and far better processors and OS (TCP/IP stacks), but....... they (zworld) are very popular,.... that's a fact.

John

Reply to
John carlton

Lack of filesystem depends on project - yes. I had a similar problem and out of this developped a FAT filesystem using Dynamic C. Porting it to another CPU was farily straight foreward. There ARE differences but all in all if you know the code you use, proting is not really rocket sience. Even AFTER doing this FAT filesystem I was more than surprized how small I could keep it and how much resources were left over for the "real" task. IMHO those bunnies are not that bad - again, provided you use them wisely.

Markus

Reply to
Markus Zingg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.