New Dynamic C Redesign needed!!!

So, rabbit has been around for a while now, and I keep wondering to myself when in the world are they going to implement 2 common sense things.

#1) Its a network product so lets get with the program and incorporate a monitor so that when I want to download my firmware I can use the network and not this silly serial cable that takes forever to download the firmware. Rabbit, hello its a network product, why even bother to have a serial programming cable connection ???

#2) Dynamic C is such a pain to work with, there is so much about it that is not typical of a programming environment. Here is a small list of things that are just flat out silly.

#1) No ability to make projects and have .c or .h files listed in a tree.
#2) No website folder where I can just drag my website into it and it automatically converts it, so there is no fuss or muss.
#3) the ram static, & global variable implementation is just flat out idiotic, should be made to ANSI C standard.
#4) cannot declare and initialize a variable in the same line.

I could go on, but the main point is this, I cringe in just thinking about porting another working project from another manuf. To Dynamic C, for a typical product port it would take hours and hours to port over. Whereas from other manuf. to go from one platform to another only takes minutes to make some system changes. Dynamic C, is so off from the path that it makes it painful to port things over to.

Rabbit is not going to respond to this ?

Has anyone else heard of another compiler for Rabbit products ?

Try Softools compiler. It is ANSI C compatible.

I had no idea there was another solution:):slight_smile:

I will give it a try

For those reading this post, here is the response from softools.

"We do not support the 4000 or 5000 and have no plans to do so. The lack of referrals and assistance from Rabbit made the Rabbit 2000/3000 tools a losing proposition, the same would result for the 4000/5000. "

So it looks like back to the drawing board :mad:

Last night i was reading Circuit Cellar magazine, there was an add for a Rabbit Dynamic C class. I said to myself they need those classes because DC is so F-up’ed that people get lost using it. If it was a good compiler people would not even need to take the class.

Rabbit, this next section is for your eyes.

I don’t know who’s head is in the sand up there. The way i see it you have to have at least a couple yoyo’s there. the first is in management, who allows the continuation of this piece of crap DC compiler. the second yoyo is the one who designed it. For the politically correct challenged people, i will replace yoyo with “not so smart”. Lets face it, to have a company as large as rabbit put out a compiler like this just makes no sense at all.

Rabbit, have you ever looked at other C compilers?
Have you ever noticed that 99.9% of them are code compatible with each other ? There is a reason for that! Since it obvious that you missed that point, i will point it out for you. Lets say i am using an old Motorola uP, and then as they often do, one day they decide to discontinue it. So now i am left scrambling for a new uP. I come across Rabbit. i download the compiler and try to port my code over when i realize i cannot #import anything as DC does not support something as simple as #import. Instead, somebody thought it was a better idea to change the #import to #use. Ya, that was genius of an idea. Then next i find out that you cannot do other simple things like create and initialize a variable in the same line, on top of that all my code that are in separate .c files i cannot use. i have to turn them all into this silly .lib files.
there is so much i would bore you listing them here. In case you have not caught on yet, its all about time and money. if going from the Mot. uP to yours is going to cost me hours and hours of time to port already working code over to yours then spend more time debugging what’s the point ? I might as well go to someone else who has a ANSI C compiler or close to one and just drag my code over to their compiler and make some small changes and be done.

Now onto the firmware updates silliness. say a company makes a network product, would it not make sense to update it via the network? Of course it would. Take a look a Net-burner, Tibbo, Lantronix, or DIGI (strange) ? All these products can upload their firmware through the network.
The only downside to Net-burner that most of their modules are not ind. temp which is a huge thing for me. As far as Tibbo goes, i like that very much, super small, low cost. the only downside on that is that its a basic compiler, and it runs to slow for me. Your new RCM5700 i think is a great product, small and great price, though why they are not being sold with an RJ45 connector on them is another mystery to me and does not make much common sense.

Why cant you implement this into your firmware: since you have co-statements. you could have 2 of them running. the first would setup a TCP listener for a firmware update signal. the second would call my main app.
In the event someone wrote something that would lock it up, you could add a jumper so that when the first co-statement ran it would look at this jumper and if enabled would not allow the second one to run and lock it up. then one could download the new firmware and then remove the jumper. The way this is done would be to have the “boot loader” code at the top of flash. I.E. say the boot loader size is 0x100, you would place that code from 0x0000 to 0x0100 and when the user uploads his firmware it would place it from 0x0101 to the end of flash. this way the user never gets to overwrite the boot loader.
the boot loader upon TCP upload signal would then copy itself to ram, and then start running from there while its flashing the new firmware to flash. when its done it reboots and all is well. if there is a power fail during the process no biggie since the boot loader copied itself to ram and only programs the flash area from 0x0100 to 0xffff it will never overwrite itself.

Now, i just gave you a GREAT idea. lets see how long you take to implement it.

Lastly and take this to the next board meeting. Ever wonder how many customers you lost because your so much out of the norm with the compiler. Ever wonder how many customers you lost because you don’t share your information with other companies who could make a better compiler ?
Ever wonder how many customers you lost because you cannot update any of your products via Ethernet ? I personally know of 7 engineers from 7 different companies that have said basically the same thing; “I would use it but i cannot deal with the strangeness of DC, and the lack of firmware uploading is another killer”. Do you really thing these customers unlike myself are going to take the time to write something like this to tell you your shortcomings ?
NO! they are just going to go to the next google search or next uP favorite manuf. and move on. I took the time to tell you all this so that you may make these key changes and get what you so much desire, “MORE CUSTOMERS”

Some of this may be hard to swallow, you have done it this way for so long… You need new blood at that company, a person who is not afraid to make some sensible and common sense changes.

If you want to prove what i am saying create a poll and ask these questions.

#1) would you like a revamp of DC to make it more ANSI C compatible.
#2) would you like Rabbit to support firmware updates.
#3) woule you like Rabbit to release processor information out to third parties to allow them to make their own rabbit 4000/5000 compilers.

Supply and demand my friend; if you dislike Rabbit use somthing else…Which begs the next question; what else is there to use?

The company I do research for has been using Rabbits for years, but since I’ve taken over the project I’ve been thinking about switching to something else.

The parent post is right – I could add to that laundry list of complaints for Dynamic C. We tried to port over some API from a Northstar system (robotic system that uses ceiling-mounted lights for navigation), with endless frustration. In addition to all the items he cited, the lack of support for calloc, malloc, new, and other similar items had us rewriting the API into this cryptic xallac style, or just saying to hell with efficiency and declaring huge arrays to get the job done.

I’d like to reiterate another’s post – What alternatives are there to the Rabbit (and, more importantly, Dynamic C)? (Softools doesn’t count cause we’re using the 4000 boards, which they don’t support.)

if you dislike Rabbit use something else…Which begs the next question; what else is there to use?

Bingo. I don’t want people to get me wrong here, Rabbit has a great products. They could increase their sales greatly if they would just get with the norm of things. Its kinda like making the perfect tire, it wont spin in summer, wont hydroplane in water, wont slip in winter, but if you only make it in a size that cannot be put on a rim whats the point.

How about an ARM Linux board electrically and mechanically compatible with a Rabbit board? Then you could use GCC, Python etc. and all the excellent Linux dev. tools available.

My business partner and I are thinking of making an ARM Linux board the size of a Rabbit Core Module. I’ve posted on these forums to try and gauge interest in other people in such a product. It would solve a lot of the limitations of Dynamic C and the Rabbit CPUs.

I also agree with the OP.
Essentially on one of my products I am vendor locked at the moment, but as soon as we have a redesign of the product, I believe we will be looking hard if Rabbit is the preffered solution for us. In my mind, in the uC world the debugging tools is just as important as the product itself.

In my mind, in the uC world the debugging tools is just as important as the product itself.

Really? i have been doing uP work for over 20 years now, and i have yet to see a need for debugging tools. I also have not yet met someone who can give me a reason for using it to the point where its a must have. So i am searching for a answer to see if i am missing the boat. but i don’t think so.

Lets say you got a bug.
a few printf’s here and there will help you isolate the problem and solve, never failed me yet.

Now lets take it further, lets say you don’t have a serial port. Well a few port pin ticks placed here and there while monitoring on scope will also find the problem. I have to use this method 2 times in the last 20 years.

Really? i have been doing uP work for over 20 years now, and i have yet to see a need for debugging tools.

Hehe, yes you can get by without debugging tools, but… in a world where time is money, developing an application with a good set of debugging tools goes much quicker, meaning better profits.

Ok the next argument is valid - A good and experienced software developer has less need for debugging tools, since less mistakes are made, and usually the developer can guess what the problem is. But a good and experienced developer isn’t always available, and sometimes the more junior guys has to develop some parts of a project, and its here where debugging tools really shine through.

Lastly debugging tools might help you to better QC your final software, since various error conditions can be checked for simultaneously. But I am willing to get spanked for this last statement.