The Rabbits

r?

I'll let someone else answer for your first questions, as I don't know how much it is used right now.

But concerning the tools, I used Softools for the development on Rabbit 3000. I worked well for me.

S=E9bastien

Using a lot of RCM3309 modules at the moment. Considering using Net Burner for future projects. We use UC/OSII and the fact that NB supports this is very handy.

Just use Dynamic C. Looked at SoftTools compiler. Looks good but never managed to push through the change for it.

Pulls up chair & opens pop corn......

I have no idea how much they are used in real projects. I have always had = a bit of a downer on them because of the non standard Dynamic C (well even = more non standard than all the other flavours of embedded C that I have use= d). =20

I was once asked to look at porting a rather badly written application to a= new processor. The combination of the poorly written software (one file o= ver 250000 lines long with 10 comments) and the non standard language meant= that we just threw it away and started again.

With all of the other processor architectures out there now, IMHO there are= many better than the Rabbit.

Unless, of course, you're developing a dead-end product that you'll never need to port to a new platform, etc. (i.e., where *this* choice has no long term consequences).

Ask yourself why you *aren't* looking at, e.g., an ARM-based solution. At least the code you write will be portable at the

But isn't source code portability just a tools issue that will go away when a standard-compliant C compiler for the Rabbit becomes available?

Philipp

(some of) Dynamic C's features aren't compliant. So, if you *use* those features, your code won't be portable. IME, the effort required to remove non-portable features from an implementation is often considerable and error-prone. The more "involved" the features become with the operation of the code itself, the greater the cost/risk.

That's not to say it isn't "do-able"... just another cost that you have to consider. But, keep in mind, when it comes to the reuse issues that are implicit in the thinking behind "Model 2" of a product, a big issue is the assumption/belief that there will be extra development economies realized because "We can *just* reuse most of the code from Model 1".

I try to religiously avoid compiler-specific "extensions" in my sources. Any "special tweeks" are moved into header files or "accessory functions" that provide interfaces, e.g., between assembly language portions of the system and HLL portions (i.e., *knowing* that these will have to be rewritten for a new compiler... but *only* these!)

r?

A quick web scan finds they have a lot of modules, but Distributor stocking of the chips thins out. The R4000 shows just 40 in stock, and no sign of the R5000 or R6000. The R2/3000 look popular (1000+ in stock at Mouser)

Usually devices like this self-selects, mainly on peripherals not core. At one time, if you needed a LOT of serial ports, Rabbit made sense. Or, if you wanted modules, ready to go, and were not price- sensitive...

What peripheral features are there that have you looking at Rabbit ?

Am 07.10.2011 22:28, schrieb Jim Granville:

I'm not looking at the Rabbit for a concrete project. I'm a sdcc developer wondering how many users (and what type and which features they most care about) there would be for our Rabbit 2000/3000 backend, that will probably be ready for the 3.1.0 release.

Philipp

How about concentrating on newer and more classy processors.

Z80 is dead, dead, dead.

Yes, and I am sure you can create a compiler for the 8051 family as well.

Dead, dead, dead

wondering how many users (and what type and which features

I wouldn't write-off either of those families prematurely. They are reasonably small cores so easy to place in an FPGA. Certainly more appealing than designing you own core and then having to write a set of tools to develop for it!

E.g., the military still uses 6502 based designs (or, at least, they seem to express an unusual interest in that skillset!). I'm pretty sure there was a rad-hardened 8080 (or 85?) many years *after* the 808x had retired.

Some of these older designs scaled to today's technology would be really speedy little devices!

Why would someone put the effort into creating a new standards compliant C = compiler now? What is the business case? There are many more lucrative pr= ocessor architectures around now that will give the compiler makers a good = return on their investment. Rabbit are unlikely to fund its development as= they have their own, non compliant tools that lock developers into using t= heir devices.

The number of times that I have had to move up through processor families t= o support more functionality on later generation products makes me very war= y about locking in to some proprietary processor/language combination that = limits my porting options.

Am 12.10.2011 10:34, schrieb snipped-for-privacy@gmail.com:

I do not see the need for a business case or return on investment. They might make it slightly more likely that some software gets written, but that's it.

Well, there already is the SoftTools compiler claiming standard conformance. And while the sdcc Rabbit backend is still lacking support for an address space larger than 64K, it otherwise does quite well.

Philipp

"I do not see the need for a business case or return on investment." Most compiler vendors like to eat and do not want to live in cardboard boxes by the side of the road!

by the side of the road!

I doubt that there are many projects on sourceforge.net that have a solid business case.