>> limited to teaching basic
Because the people that NEED help get over looked over by people just shooting
of their opinions.
When you posted all this junk then busy working professions who could help get
bogged down reading worthless posts like this.
What question or issue did you solve with this last post?? All you had to say
was "SoftTools, worked for me, tryit"
Don't want to flame anybody just want people to get the real help they need
for what this group is for.
Ryan
Dynamic C 9.40 bugs?
Started by ●March 13, 2006
Reply by ●March 14, 20062006-03-14
Reply by ●March 14, 20062006-03-14
> just want people to get the real help they need for
what this group
is for.
The REAL HELP I NEEDED was provided by those who kindly replied. My
original "technical" posting presented evidence of serious compiler
and HW issues which have the potential to cost my company half a years
revenue if they could not be solved. Discovering information about a
history of compiler and hardware quality issues is the most valuable
piece of "technical" information I have found even after combing the
entire archive over several days. Thanks again for your concern and
for allowing so many of us to distract you with such unimportant
things! ...back to basic bugs...
is for.
The REAL HELP I NEEDED was provided by those who kindly replied. My
original "technical" posting presented evidence of serious compiler
and HW issues which have the potential to cost my company half a years
revenue if they could not be solved. Discovering information about a
history of compiler and hardware quality issues is the most valuable
piece of "technical" information I have found even after combing the
entire archive over several days. Thanks again for your concern and
for allowing so many of us to distract you with such unimportant
things! ...back to basic bugs...
Reply by ●March 14, 20062006-03-14
Roughly 99% of the topics on this list are of no immediate use to me.
Guess what? It's easy to pick the fly crap out of the pepper. My guess
is most professionals can do this without even thinking about it. Guess
what else? One person's fly crap is another person's pepper.
I found this particular discussion interesting. It certainly could be
applicable to my future work. Having followed the thread may save me
considerable headaches in the future.
Rob
Guess what? It's easy to pick the fly crap out of the pepper. My guess
is most professionals can do this without even thinking about it. Guess
what else? One person's fly crap is another person's pepper.
I found this particular discussion interesting. It certainly could be
applicable to my future work. Having followed the thread may save me
considerable headaches in the future.
Rob
Reply by ●March 14, 20062006-03-14
If you select few do not like running ANY SOFTWARE which MAY contain flaws, then
remove ALL Microsoft software from your systems (if installed). I had more
problems with Excel than DC(any version).
In 98 I designed a micro pump control system for Vulcan Chemical, which was counting each .000007 Liter stroke of an adjustable micro-liter pump, and the system needed to keep track of the total volume in liters over time. The DC system had a problem once the total volume exceeded 9.999 liters
The DC version of the time did not support simple FP math with a decimal point difference of 8 places or more.
I dealt with it.
I moved the floating point math to ABS math, then scaled for display and serial output. The customer wanted to keep track in FP, but I fixed it.
It was about three more DC revisions before the math problem was resolved. (best of my memory).
There are ways around just about every coding problem encountered, and when you can not figure it out yourself, call technical support, that is what they are there for.
In 1988 I started a multi-processor design for a voice/data encryption system for Chips International, I choose the C15 DSP processor from Texas Instruments. Once the development tools were purchased and the samples of the DSP chips were received, I proceeded to develop code.
Within the first week I found 32 mistakes in the C compiler and hundreds of errors in the documentation produced by TI (yes big-o-TI) a massive company with thousands of employees, each of which specialize in their areas of expertize. I corrected the documentation with a pen, and sent the entire book to a department head at the DSP group at TI. I also created a list of compiler flaws and sent that to the C compiler company (third party).
I received acknowledgment from the compiler company within a week along with the corrected software. Communications process worked!
It took three weeks for TI to update the mistakes in the documentation and the corrected firmware and paper documentation was delivered in person by the department head (a 5 hour drive, one way), he also delivered three tubes of C15 windowed DSP-MPUs as an apology. Communications process worked again!
EVEN the BIG DOGS HAVE PROBLEMS!
I have also had problems with Intel, Microchip, Zilog, and Motorola, MPU/CPU's.
Communications with the manufacturers technical support personnel is very important when YOU find problems.
Just griping about it does not resolve the issue.
I have in the past visited with ZWorld, and they will help you any way they can to resolve the products including DC.
They can not help if you do not let them know the problems.
I was part of the RabbitSYS Beta team, and I can tell you I put the RabbitSYS through HELL, before I passed it as OK in my opinion.
Yes ZWorld/Rabbit Semiconductors has Beta programs and it is the authorized developers which do the majority of the beta testing.
Do you understand what I mean by "just deal with it".
It means to take the initiative, identify the problem and report the problem, then expect results by ZWorld technical support.
They will perform better than you expect, if you stay on top of the issue.
I do not think they monitor this group, so it would be better to call them (530) 757-8400.
1-530-757-8400
I am through with this thread, you all can keep beating you heads against you monitors, but it will not help, until you take the initiative.
The "just deal with it" man! I think I will make that my new motto.
JIMA
In 98 I designed a micro pump control system for Vulcan Chemical, which was counting each .000007 Liter stroke of an adjustable micro-liter pump, and the system needed to keep track of the total volume in liters over time. The DC system had a problem once the total volume exceeded 9.999 liters
The DC version of the time did not support simple FP math with a decimal point difference of 8 places or more.
I dealt with it.
I moved the floating point math to ABS math, then scaled for display and serial output. The customer wanted to keep track in FP, but I fixed it.
It was about three more DC revisions before the math problem was resolved. (best of my memory).
There are ways around just about every coding problem encountered, and when you can not figure it out yourself, call technical support, that is what they are there for.
In 1988 I started a multi-processor design for a voice/data encryption system for Chips International, I choose the C15 DSP processor from Texas Instruments. Once the development tools were purchased and the samples of the DSP chips were received, I proceeded to develop code.
Within the first week I found 32 mistakes in the C compiler and hundreds of errors in the documentation produced by TI (yes big-o-TI) a massive company with thousands of employees, each of which specialize in their areas of expertize. I corrected the documentation with a pen, and sent the entire book to a department head at the DSP group at TI. I also created a list of compiler flaws and sent that to the C compiler company (third party).
I received acknowledgment from the compiler company within a week along with the corrected software. Communications process worked!
It took three weeks for TI to update the mistakes in the documentation and the corrected firmware and paper documentation was delivered in person by the department head (a 5 hour drive, one way), he also delivered three tubes of C15 windowed DSP-MPUs as an apology. Communications process worked again!
EVEN the BIG DOGS HAVE PROBLEMS!
I have also had problems with Intel, Microchip, Zilog, and Motorola, MPU/CPU's.
Communications with the manufacturers technical support personnel is very important when YOU find problems.
Just griping about it does not resolve the issue.
I have in the past visited with ZWorld, and they will help you any way they can to resolve the products including DC.
They can not help if you do not let them know the problems.
I was part of the RabbitSYS Beta team, and I can tell you I put the RabbitSYS through HELL, before I passed it as OK in my opinion.
Yes ZWorld/Rabbit Semiconductors has Beta programs and it is the authorized developers which do the majority of the beta testing.
Do you understand what I mean by "just deal with it".
It means to take the initiative, identify the problem and report the problem, then expect results by ZWorld technical support.
They will perform better than you expect, if you stay on top of the issue.
I do not think they monitor this group, so it would be better to call them (530) 757-8400.
1-530-757-8400
I am through with this thread, you all can keep beating you heads against you monitors, but it will not help, until you take the initiative.
The "just deal with it" man! I think I will make that my new motto.
JIMA
Reply by ●March 15, 20062006-03-15
My company has been using the RCM3000 & RCM2000 for about 4-years now.
We've never had a failure of the 2000 and only a couple of failures on the
3000. And we've shipped over 500 products.
That said, it seems to me that many, if not most, of the module problems reported in this group occur with companies that are outside the U.S. This is anecdotal evidense at best, but could it be that the supplier of rabbit products to those outside the U.S. is different than the supplier to the U.S.? And that their quality is different as well?
That said, it seems to me that many, if not most, of the module problems reported in this group occur with companies that are outside the U.S. This is anecdotal evidense at best, but could it be that the supplier of rabbit products to those outside the U.S. is different than the supplier to the U.S.? And that their quality is different as well?
Reply by ●March 15, 20062006-03-15
I have been using rabbits for over 7, 8 years in Mico but getitdirectly
from ZWorld and no failure at all with maybe 200 different units, all kind: Z80,
OP6700, cores 2000,3000. Reading that so many failures I was thinking may be the
failures are in USA becuse is far easy to returnthem there, that from outside,
soam I getting an export better-quality?
Reply by ●March 15, 20062006-03-15
Reply by ●March 15, 20062006-03-15
I couldn't agree more. I am sticking with 8.01 beacause:
1. I can't upgrade without making significant changes to the code. I don't have time to do it anyway.
2. Now I know about most of the bugs in 8.01 and how to get around them.
3. Upgrading necessarily doesn't mean bugs have been fixed.
-----Original Message-----
From: rabbit-semi [mailto:rabbit-semi] On Behalf Of Mike van Meeteren
Sent: Tuesday, March 14, 2006 9:16 PM
To: rabbit-semi
Subject: Re: [rabbit-semi] Re: Dynamic C 9.30/9.40
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
1. I can't upgrade without making significant changes to the code. I don't have time to do it anyway.
2. Now I know about most of the bugs in 8.01 and how to get around them.
3. Upgrading necessarily doesn't mean bugs have been fixed.
-----Original Message-----
From: rabbit-semi [mailto:rabbit-semi] On Behalf Of Mike van Meeteren
Sent: Tuesday, March 14, 2006 9:16 PM
To: rabbit-semi
Subject: Re: [rabbit-semi] Re: Dynamic C 9.30/9.40
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
Reply by ●March 15, 20062006-03-15
I'm sure Nathan could shed a little more light on this, at least from us
down under as he works for the Aus distributor. Most of the 'failures'
i've read about on this list have nothing to do with faulted hardware,
but faulty users. As far as i know, the RCM's i get are exactly the same
as the US ones. Is this right, Nathan?
The only ones dead in my office, either myself or another engineer have
killed during testing. We make them into Rabbit stew :)
This whole "DC kills my code" argument bothers me as a programmer. My
practice is to wrap ALL of the DC specific (i.e. non-ANSII) commands
into my own functions, or to simply strip the Rabbit source into my own
function. That then lives in it's own library. Why? Well... it only
takes me a day to port my DC code to Linux or M$ because i know where
all of the platform specific code is and just sub the right library or
header! I expect life will be much harder if every line of your main
code references some Z-World function or you don't create your own small
and manageable libraries. Yes, DC can be 'flakey' - but good coding
practice fixes the most flakey of IDE's. Long term - bad code leads to
IDE dependency, not bad IDE's.
Scott Morris.
down under as he works for the Aus distributor. Most of the 'failures'
i've read about on this list have nothing to do with faulted hardware,
but faulty users. As far as i know, the RCM's i get are exactly the same
as the US ones. Is this right, Nathan?
The only ones dead in my office, either myself or another engineer have
killed during testing. We make them into Rabbit stew :)
This whole "DC kills my code" argument bothers me as a programmer. My
practice is to wrap ALL of the DC specific (i.e. non-ANSII) commands
into my own functions, or to simply strip the Rabbit source into my own
function. That then lives in it's own library. Why? Well... it only
takes me a day to port my DC code to Linux or M$ because i know where
all of the platform specific code is and just sub the right library or
header! I expect life will be much harder if every line of your main
code references some Z-World function or you don't create your own small
and manageable libraries. Yes, DC can be 'flakey' - but good coding
practice fixes the most flakey of IDE's. Long term - bad code leads to
IDE dependency, not bad IDE's.
Scott Morris.
Reply by ●March 15, 20062006-03-15
At 07:13 PM 3/14/2006 -0800, you wrote:
>That said, it seems to me that many, if not most, of the module problems
>reported in this group occur with companies that are outside the U.S. This
>is anecdotal evidense at best, but could it be that the supplier of rabbit
>products to those outside the U.S. is different than the supplier to the
>U.S.? And that their quality is different as well?
We're in the US, and lately we've had an alarmingly large number of 2nd
flash failures on our RCM3000 cores. I suspect soldering is at the core of
the problem but I don't have the tools to diagnose it further (unlike one
of my our of country collegues that found unsatisfactory soldering quality).
The only test I can do is a flash dump and compare with a known good binary
image. When the flash has a repeating pattern of corruption, it's pretty
apparent that there's something wrong physically with the core. (And no,
it's not software blowing the flash away, because once it's bad it cannot
be reprogrammed).
These cores were purchased from Digikey (one of the largest if not the
largest Rabbit distributor of Rabbit products in the US). The bad cores
get returned to them, at which point we get issued credit. Hopefully the
products make it back to Rabbit for evaluation so their process can be
fixed for future shipments.
These are new problems BTW. They've cropped up in the last 6 months.
-Mike
--
Mike vanMeeteren fast351@fast... FASTechnologies Corp.
Track Hauler: 2001 F150 Track toy: 89 Mustang LX 351W 10.93 @ 122.5 MPH
>That said, it seems to me that many, if not most, of the module problems
>reported in this group occur with companies that are outside the U.S. This
>is anecdotal evidense at best, but could it be that the supplier of rabbit
>products to those outside the U.S. is different than the supplier to the
>U.S.? And that their quality is different as well?
We're in the US, and lately we've had an alarmingly large number of 2nd
flash failures on our RCM3000 cores. I suspect soldering is at the core of
the problem but I don't have the tools to diagnose it further (unlike one
of my our of country collegues that found unsatisfactory soldering quality).
The only test I can do is a flash dump and compare with a known good binary
image. When the flash has a repeating pattern of corruption, it's pretty
apparent that there's something wrong physically with the core. (And no,
it's not software blowing the flash away, because once it's bad it cannot
be reprogrammed).
These cores were purchased from Digikey (one of the largest if not the
largest Rabbit distributor of Rabbit products in the US). The bad cores
get returned to them, at which point we get issued credit. Hopefully the
products make it back to Rabbit for evaluation so their process can be
fixed for future shipments.
These are new problems BTW. They've cropped up in the last 6 months.
-Mike
--
Mike vanMeeteren fast351@fast... FASTechnologies Corp.
Track Hauler: 2001 F150 Track toy: 89 Mustang LX 351W 10.93 @ 122.5 MPH
