Home/Support/Support Forum/Why Dynamic C doesn't update and still has an old interface?
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Why Dynamic C doesn't update and still has an old interface?

+1 vote

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
asked May 6, 2020 in Rabbit Software by DominusDRT New to the Community (1 point)

Please log in or register to answer this question.

2 Answers

+1 vote
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:

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:

* Port Rabbit support from OpenRabbit to OpenOCD
* Add Rabbit support to gdb
* Add ELF support in the Small Device C Compiler (SDCC) Rabbit backends
* Port the libraries from Dynamic C to SDCC
* Add support for Rabbit 4000/5000/6000 in SDCC

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.
answered Sep 21, 2020 by spth New to the Community (24 points)
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.
0 votes
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.
answered May 7, 2020 by TomCollins Veteran of the Digi Community (2,222 points)
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.