Re: Re: Digi's treatment of Rabbit products

Steve,

It's unfortunate that none of the Dynamic C 10 work benefitted DC 9.  But as someone who's used DC 10 a lot, I dread having to go back to 9.  My consulting focus is on the libraries and samples for Dynamic C, so I'll answer your message with that perspective.

Many of your issues could be addressed by porting your project to one of the newer products (4000-based and later) and using Dynamic C 10.  The quality of the compiler improved greatly.  A lot of work went into making it more ANSI compliant, and I feel that our team was able to get most of the commonly-used features.  In Dynamic C 10.72, you can declare variables and initialize them on the same line, declare variables at the start of any scope (between any open curly brace and statements).  It's still a C compiler, so no function overloading.  But full support of far pointers, and even "const correctness" for function parameters.

You mention the lack of an Ethernet push option for Remote Program Updates, and maybe that's something that could be addressed.  It can pull from an FTP, TFTP or HTTP server, but the only demonstrated push option is HTTP upload (which makes sense if your product already makes use of a web interface).

I don't know what Scott's protocol look like for sending the firmware binary, but it might be possible to implement it as a plug-in for the Remote Program Update library in DC 10.  How about if you could have a TFTP server on the Rabbit to receive firmware updates from a TFTP client?

Note that Dynamic C 10 includes a library (addp.lib) and Windows utilities for device discovery and network configuration, but does not include a method of performing firmware updates (typically done via HTTP upload on other Digi products).

Are there other software issues holding you back from using the Rabbit 6000 modules instead of Rabbit 3000?

-Tom


On Jan 4, 2016, at 4:43 PM, Steve Trigero seecwriter-/[email protected] [rabbit-semi] wrote:

> Well, I stand corrected. I honestly did not recall that the R4/5/6k lines were done under Digi.
> And has it been 10-years since Digi bought Rabbit? Wow! Time flies.
>  
> If compiler updates are being made, why doesn't the Digi website show any compiler updates
> or bug fixes? 
>  
> I always upgraded to the latest version of compiler whenever they were released. According to
> my records, v9.62 was released in 2008, with one patch in 2011. So it's been 8-years since the last
> release of DC9 and 5-years since the last bug fix. That doesn't strike me as much support.
>  
> DC10 is little more recent. It looks like DC 10.72 was released in early 2013 (maybe late 2012),
> with a patch released 6-months or so later.
>  
> Also, my experience with Digi tech support the last few years is much like the original poster,
> no response.  They used to respond in the early days after the buyout. But my experience is that
> it has slowly trickled off to nothing. The last few times I pinged them with a question I received
> no response.
>  
> I admit that I don't have a lot of tech support requirements anymore. Partly due to having solved
> or found work-arounds for most issues and partly due to my company's moving to a new platform. 
> And the move to a new platform is primarily due to the lack of support from Digi and the memory
> wall.
>  
> We are up against the memory wall with the R3k series. The R3k is capable of addressing more than
> 512k, why can't Digi release new modules that expand the program memory of the R3k series?
>  
> I really like the R6k modules, but you can't program them over Ethernet using a utility like Scott's.
> You have to set a URL and tell the module go look for an update. This is a slow process and doesn't
> work for field upgrades.
>  
> The RCM3000, which we use in quite a number of products, is only 10Base-T, and I believe it is only
> half-duplex . We continue to get complaints from customers about it's poor performance, and our
> solution for those that are unwilling to accept the performance is to swap it out for an RCM3900 which
> is 10/100 Base-T and full duplex. Why can't the RCM3000 be upgraded with a better network controller?
> Why can't all the R3k modules get a speed boost by using faster crystals? They are way under clocked.
>  
> Then there's the issue of DC introducing or exposing compiler bugs and not producing good code when
> the compiled program starts approaching the high 400k of program memory. Moving a function from one
> place in the program to another is enough to either cause a compiler error or remove a compiler error.
>  
> And using the DC bugger with DC9 is a roll of the dice as to whether it will work or not. There are many times
> when it just won't connect to the Rabbit, or loses track of the program forcing you to close it and reopen, or
> taking a single step that never returns requiring the use of the Program Manager to kill it. It won't evaluate
> expressions any longer. It won't show variable values when the mouse hovers over the variable name any
> longer. I have to use printf statements to view variables.
>  
> It would be nice if some simple C++ constructs could be added to DC. Things like being able to declare
> a variable and initialize it on the same line, being able to declare a variable anywhere in a function, and
> being able to overload functions. Being able to use pointers in DC9 to access extended memory, like you
> can do with DC10, would also be nice.
>  
> The list is large.
>  
> I did not know of the work in Github. I will check it out.
>  
> Steve