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.
