Hi.
I think the Rabbit® 6000 MCU is very good, but the interface used for Dynamic C is very old and has not changed in a long time. Debugging is a headache since communication with the module is often lost. I see that other manufacturers of microcontrollers improve software development tools every day, but Digi I think is leaving this microcontroller aside.
Any comments or suggestions are welcome
I can’t speak to why Digi isn’t updating the IDE, but they are actively maintaining the libraries and sample programs on GitHub, including TLS updates and fixes for WPA vulnerabilities (for the RCM6600W which unfortunately was discontinued). https://github.com/digidotcom/DCRabbit_10
What are you doing when the debugger loses its connection? Unless you’re blocking for a long period of time in a function flagged as “nodebug”, you shouldn’t be losing the debugger. It’s possible to crash the debug kernel with bugs in your code, but during normal code execution and debugging, the debugger should remain connected and allow for single-stepping and variable watching.
Regarding the RCM6600W, I think it was due to the temperature. I designed a product that works in tropical environments and the temperature reached more than 55 degrees (which seems to me to be the maximum working temperature) and finally after one month, it stopped working. Previously, flash memory was altered or erased. We had to redesign the project with a similar device from another manufacturer.
Personally, I wonder about the future for the Rabbits. At distributors, a lot of them are marked as “not recommended for new designs”. Here at Digi, when looking at SBC evaluation boards, all Rabbit ones are marked “matured”, while none of the “featured” ones has a Rabbit.
So it might be that Digi doesn’t want to put too many resources into something nearing EOL.
But that is just speculation.
After all they are putting effort into clearing up and opensourcing some of the Rabbit software:
https://github.com/digidotcom/DCRabbit_9
https://github.com/digidotcom/DCRabbit_10
This also opens the way to a possible future for Rabbit development. It already helped with the revival of OpenRabbit (https://github.com/spth/OpenRabbit), and there could be a way to a modern development environment:
Then one could target Rabbits using any modern IDE that supports SDCC (e.g. Code::Blocks) with on-target debugging using gdb via OpenOCD. Such a toolchain already works for the STM8.
That would be a lot of effort to support a commercial product only available from a single vendor (Digi). When they EOL products (like the RCM6600W), there aren’t alternative sources from which to purchase those products.
A lot of effort, indeed. And I currently don’t intend to work on OpenOCd or gdb or porting of libraries. Not sure about Rabbit 4000/5000/6000 support yet.
ELF support in SDCC should be easy; we already have it in the hc08, s08 and stm8 backend.
But maybe others will fill in the gaps once we have a basic free toolchain working. As happened for STM8.