Dynamic C 9.40 bugs?

All,

These are technical issues. As a software developer I can just imagine if my software had bugs telling my client to "Get over it". It would be the last job I ever did! (Some of my software development is life safety and mission critical i.e. flight) It is a shame that for some reason in the world of software it has become common place and accepted that a certain number of bugs are OK. I for one would not wish to have a team member or an employee of mine with your attitude. ZWorld should strive to have the best quality product for their customers. I don't think anything is more frustrating to me when the tools get in the way of my development, whether it be software, hardware, mechanical, etc. Posting issues on this forum allow me to make an informed decision about my choices for tools. I also choose to use the compiler from Soft-Tools since from one release to the next of the ZW products, my programs would no longer compile or run. This should be unacceptable to all. Software users should not accept mediocre.

Regards,
Will Hookway
Advanced Computer Technology Start a New Thread

Hello,

Tuesday, March 14, 2006, 4:20:30, IDES wrote:

I> If you do not like the products, leave.

That is almost exactly that I said to my boss - and we planned to move
all new products to ARM-based microcontrollers. There is a lot of
choices in (ANSI-compliant) development tools, from free (but
production stable) GCC to expensive (but VERY good) solutions from ARM.

Choice of chips is also great - from less than $2 Philips LPC2101 for
small projects to a really powerful chips with USB host and built in
Ethernet hardware. All covered by same toolchain, no need to invest
thousands every time you meet with limitations of current platform.

There is also a choice of various RTOS available for ARM-based chips,
both free and commercial. FreeRTOS is almost as good as uC/OS-II, just
price tag differs drastically. ;-)

For someone who like the "processor core" approach - look for example
at that http://www.ethernut.de/en/hardware/enut3/index.html (coming
soon, and all previous AVR based releases are fully documented, with
board files published, I expect that release 3 will have same status
too)... There was also information that Nut/OS with TCP/IP stack is
being currently ported to this design, but even Linux can be run on
this target.

I will not discuss pricing questions here, but can say that some of
rabbitcores with faulty clock crystals or bad soldering joints cost us
more than $400 just to replace units installed at a hard to reach
locations. According to our support and service dept, we had over
$16000 of service-related expenses during last two years, only in
cases that was finally traced to faulty cores.

So, if there will be same situation with tools and cores quality, I
will stay with Rabbit for a lifecycle of current Rabbit-based
products, and not even a minute more.

I still stay with DC8.61, of course, just to support more than
thousand Rabbit-based units in the field.

I> Lets all get back to technical issues.

;-) I think, sometime it is necessary to discuss the root cause of most
technical issues. I.e. guys who "designed" most problems that
discussed here.

--
Best regards,
Yuri mailto:yuri@yuri... Start a New Thread

I agree.. Hence the rationale for my original posting.. I was/am very
curious about rather anyone is actually using 9.3/9.4 in a production
environment, not "griping" (but, yes I agree that some of what was
posted in the responses could be considered griping). I have used
9.10 since the beginning of 2005, and all of my shipping code is
compiled on that version and burned using the RFU.

The issues that I have run into (in 9.40) are related to the changes
in the macro structures in the bios. There SEEMS to be some errors in
the way the compiler is storing certain configuration macros (in some
modes they act as longs, and in others they act as ints with
corresponding changes to the way certain segment math works). There
ARE also some errors in the grouping of aggregated macro calulations
(paranthsesis are missing) causing undesirable effects on the
placement of code areas. I gladly pay the yearly support fee, and
have been in contact with Larry and Puck in Zworld's tech support
department. I would assume that fixes will be made, but the blatancy
of these errors causes me some discomfort about the level of errors
that also could exist.

As far as Softtools goes, when we started our projects I worked with
Bill from Softtools to evaluate the tool for my uses.. At that point,
(3? years ago) there were some significant limitations to the
softtools program that would have affected my development. Many times
since, I have considered evaluating my code for a port. And, someday,
I admit we probobly will port our code to softtools..

Our products are part of a life critical system (animal, not human)..
I have to be very sure that my code does what it's supposed to do
between versions.. I get worried when I see bugs like this.. ZWorld
has a good product, good software, and a good second source for
development. I only hope that they aren't being overly ambitious with
their new products (RabbitFLEX, R4000, RabbitSYS, etc).

Feel free to contact me via email "sryan at pmsi dot cc" if anyone
wants the specifics of what I found, and the modifications I made to
the bios files.

Sean Ryan
Poultry Management Systems Start a New Thread

At 09:18 AM 3/14/2006 -0500, you wrote:
>mission critical i.e. flight) It is a shame that for some reason in the
>world of software it has become common place and accepted that a certain
>number of bugs are OK.

You can blame Microsoft (in large part) and the movement to a single user
environment with PCs for that. Back in the days where most computing was
done in a mainframe situation, software crashes that took the entire
mainframe down were unacceptable, and having to reboot to restore the
system to a stable condition was out of the question.

Then came the single user environment where the penalty was low for
rebooting (IE it only inconvenienced one person) and OS MTBF was measured
in hours, not weeks. If I remember right the target for Windows 95 when it
was first released was a MTBF of greater than one (1!) hour. 8 reboots in
an average work day was "acceptable". This naturally moved to software
from operating systems, and all of a sudden a software bug that didn't take
the whole machine down didn't seem so bad. (I remember thinking in NT how
cool it was you could kill a crashed app with task manager and keep
running, even though I had that functionality in Unix 20 years earlier).

Anyway, these days most of software development is spent on glitsy
interfaces and cool new features like dancing paperclips. Making the core
functionality of a piece of software seems secondary (unfortunately).

> I for one would not wish to have a team member or an employee of mine
> with your attitude. ZWorld should strive to have the best quality
> product for their customers. I don't think anything is more frustrating
> to me when the tools get in the way of my development, whether it be
> software, hardware, mechanical, etc. Posting issues on this forum allow
> me to make an informed decision about my choices for tools. I also
> choose to use the compiler from Soft-Tools since from one release to the
> next of the ZW products, my programs would no longer compile or
> run. This should be unacceptable to all. Software users should not
> accept mediocre.

I would guess with most of the readers here who have been professional
developers for years, you're preaching to the choir.

One thing I have noticed is that alot of people here jump on the upgrade
bandwagon whenever a new release of DC comes out. Like I always tell my
customers when they consider upgrading firmware, unless there is a specific
issue you're addressing when you think about upgrading, you should leave
well enough alone (of course most don't listen, because they also have been
conditioned that the latest software MUST be the best).

-Mike Start a New Thread

Will,
I couldnt agree with you more. I try to take pride in everything
I do and I would feel bad giving a customer anything less than what
I thought was a good job. I'm not one of the people that can just
walk away and say "Thats good enough" which sometimes seems to be
a disadvantage.

I for one always appreciate everyones comments on anything releated
to hardware/software for Rabbit no matter what the topic. If I dont
care for a topic it's easy to press delete or just dont say anything.

Regards,
Matt Start a New Thread

Guys can we get back to rabbit tech. issues?

If you see a 9.4 issue post it so other don't think they are going nuts but keep the opinions and complaining out of the group.

Ryan Start a New Thread

The last time (about 3 years ago) that this site became full of vitrole
about Rabbit, everyone was going to dump Rabbit for a then exciting new
module called Fastburner. I suspect those that did move are now licking
their wounds. My company has been using Rabbit modules since the start
(1996?), have over 1000 RCM3000 modules in the field and have never had a
failure due to the Rabbit itself, nor do we have much complaint about
DC8.51; the compiler level we're using. We have purchased Softools, and may
use it for upcoming completely new projects, but it's not really an
imperative, and requires an awful lot of rewriting of our code. We
evaluated DC9.40 and found issues, so stayed with 8.51. Zworld deserves the
dissing it is getting for releasing 9.4; clearly that release was tied up
with the support for the new modules, and there was a lack of coordination
internally between the hardware and software developers. DC9.4 is a quick
(and nasty ) fix, which will no doubt be surplanted by DC10 once the R4000
reaches commercial release. As Mike says don't upgrade if you don't need
to. The release of DC10 and the R4000 is going to be an interesting and
exciting time for both Rabbit developers and Digi/Zworld. It will be fun.
Their success is our profit. Start a New Thread

I cannot thank the posters in this particular thread enough.

THANK YOU!

The idea that "technical" posts should be limited to teaching basic
programming skills is absurd. It is not up to any individual to
declare a thread unimportant to everyone. Technology makes it very
simple for anyone not interested in a thread to "Get over it", just
click on the next thread topic and YOU will be over it. The many of
us who are legitmately concerned about the issues in this thread
deserve some respect. In my case, human lives actually do depend on
getting correct behavior from my chosen processors and tools. My team
spends an enormous amount of time and money investigating the
technical and non-technical aspects of a candidate component before
authorizing its use in any product. Gaining insight through an
occasional thread like this is, as they say, priceless. Open exhange
is open to all but the close minded!

I will definitely evaluate SoftTools before passing a final verdict on
Rabbit hardware, and I'll refrain from posting my verdict so as to
avoid offending anyones favorite pet.

THANKS AGAIN EVERYONE... Start a New Thread

Hello, Ross.

Tuesday, March 14, 2006, 23:27:38, Ross Lyn wrote:

R> The last time (about 3 years ago) that this site became full of vitrole
R> about Rabbit, everyone was going to dump Rabbit for a then exciting new
R> module called Fastburner. I suspect those that did move are now licking
R> their wounds.

I imagine how many wounds will have my company, if Digi suddenly decide
sometime that Rabbits not generate enough income or make unnecessary
competition for some other perspective product....

Rabbits is not so bad, but it is a single source product. People
using softools will have not so much problems if something happens
with Rabbits (I suspect, many of them will just design and manufacture
pin-compatible processor modules with other processors), but people
who uses DC co-stuff will have very hard days...

Even large and stable manufacturers sometimes may suddenly
discontinue their standard products without explanations and excuses.
I remember our shock when Motorola discontinued most flavours of their
68HC(7)05 family...

Friend of mine working for a company that used Samsung communication
processors that was suddenly discontinued - they ended up with
purchasing a couple of hundreds scrapped ADSL modems that use this
chip to fulfill last contract, and all techs and engineers was
"mobilized" for a week to manually desolder processors from modem
boards and solder them to their units. Redesign take almost half year,
and when new design was in final testing - oops, Samsung returned
discontinued chips to production. You can imagine amount of obscene
words that I heard from them about Samsung management.

Another colleague used Motorola M12+Timing GPS modules for
synchronization in their product. When Motorola decided to discontinue
everything and sell whole division to SiRF, their small company was
forced to purchase at once about 450 modules (quite expensive, of
course) to keep their production until redesign will be made and
necessary certificates for new model is received (also, not free process).

R> My company has been using Rabbit modules since the start
R> (1996?), have over 1000 RCM3000 modules in the field and have never had a
R> failure due to the Rabbit itself,

You are lucky man. We have about 1100 units with RCM3110 and about 240
units with RCM3100 in the field now (three different projects). Plus
300 more RCM3110 just ordered.

When I last checked our junkbox, there was 1 (one) RCM-3100 and about
45 RCM-3110. Plus we repaired and put back in use about 60 more
RCM3110, all with factory solderiing problems.

There is also about twenty RCM-3000 cores used in a custom products,
but we never had any hardware problems with them.

I have some photos at work - RCM3110 boards with removed flash chip
(we are using hot air soldering station). One side of chip have some
solder at about half of pads area - the rest is virgin immersion gold.
That was standard problem in one of lots that we receive in a 2005.
Another lot (500 pcs) had massive failure rate due to faulty clock
crystals. I have samples that have 1 second error for each 15 sec of
elapsed time. Not sure what to do with them, because of conformal
coating around clock circuitry. Due to stupid customs rules it is
almost equally expensive to send it back or just throw away and
purchase new cores.

At the same time, single RCM3100 that I have in junkbox is not a
Rabbit/ZWorld/their contract manufacturer fault. All modules was
purchased in 2003 and beginning of 2004 (if memory serves me
correctly) and work fine.

R> nor do we have much complaint about DC8.51; the compiler level
R> we're using. We have purchased Softools, and may use it for
R> upcoming completely new projects, but it's not really an
R> imperative, and requires an awful lot of rewriting of our code.

I purchased DC9 upgrade, but was unable to migrate to DC9 with my
project due to PPP module problems, so still use 8.61. Tried to
install DC9.40 and PPP2.02 recently, but no much fun... For sure, I
will not pay anymore for next DC upgrades. Even DC9 and PPP2 upgrade
was wasted money.

--
Best regards,
Yuri mailto:yuri@yuri... Start a New Thread

But you see,,, this is not vitrole. In your own post you share
valuable information pertient to this thread. You found that 8.51
has been stable so you stuck with it. Newcomers get whatever
shipped with their modules so we don't have the luxury of starting
with a known quality level. Most of the posters have graciously
shared similar information about what has and has not worked for
them. EXTREMELY VALUABLE INFO when your products, customers, and
reputation depends on stability. Thanks again! Start a New Thread