Re: Re: Digi's treatment of Rabbit products

Hi,
It would be nice to have a linux version of DC10, or a set of library that
work
with sdcc


Mathieu


On Tue, Jan 5, 2016 at 2:43 PM, Tom Collins [email protected] [rabbit-semi] <
[email protected]> wrote:


>
>
> 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
>
>
> 
>






-- 
A te quaeso, sicut in Aeneidos libro quarto Aeneas, elocutus desiderium
erigendi suum obeliscum in templo Venereo Didonis, ab ea quaesivit, tuae
domi an meae?