After a couple hundred man hours... (yes, we are nuts probably...)
After submitting a support ticket and poning we finally got an answer that explains problems:
"
Under certain conditions, the use of dual priority interrupts
may cause a program instruction to be skipped entirely.
This has only been observed when both of the following apply:
* Both high and low interrupts are enabled, and
* A high priority asynchronous interrupt occurs in the
following cycle after any low priority interrupts.
The event causes the stack to get pushed twice,
and will eventually result in an overflow.
"
AAAAAAHHH !!!
And this is not in any errata, and still Microchip knows about it.
(although a month ago when we asked they did not know any bugs not described in the erratas)
OK... whatever...
Before we go on programming around that bug...
Any idea how we can get to know all bugs, not just the ones released in erratas?
> After submitting a support ticket and poning we finally got an answer that explains problems:
>
> "
> Under certain conditions, the use of dual priority interrupts
> may cause a program instruction to be skipped entirely.
> This has only been observed when both of the following apply:
>
> * Both high and low interrupts are enabled, and
>
> * A high priority asynchronous interrupt occurs in the
> following cycle after any low priority interrupts.
>
> The event causes the stack to get pushed twice,
> and will eventually result in an overflow.
> "
That's a very old errata going back to the first generation of 18F
parts (circa 2002). I'd be surprised if it were present in recent
silicon.
If you were getting hit by this errata, you'd know it, because you'd
have a hardware stack overflow, which causes a reset by default.
It's just one more example of what I have been bitching about.
They know about the problems but don't bother to advertise them.
I have YET to see ANY of the SPI problems I have uncovered advertised!
I get REAL tired of being their unpaid B-Site!!!
*
| __O Thomas C. Sefranek spam_OUTWA1RHPTakeThisOuTARRL.NET
|_-\<,_ Amateur Radio Operator: WA1RHP
(*)/ (*) Bicycle mobile on 145.41MHz PL74.4
ARRL Instructor, Technical Specialist, VE Contact.
hamradio.cmcorp.com/inventory/Inventory.html http://www.harvardrepeater.org
Den 2007-09-10 22:03:09 skrev John Temples <piclist3KILLspamxargs.com>:
> That's a very old errata going back to the first generation of 18F
> parts (circa 2002). I'd be surprised if it were present in recent
> silicon.
One reason I did choose PIC18 before dsPIC is that it is elder, and all bugs should have been found.
I *AM* surprised :(
> If you were getting hit by this errata, you'd know it, because you'd
> have a hardware stack overflow, which causes a reset by default.
We have had resets, seldom.
Strange function return values, often.
Even simple if-statements going wrong.
We have now put all interrupts in the same level.
- Problems gone.
(...except we have a bit more than acceptable latency for the service we before had in high prio... so as a whole the design is not working... need to redesign long-time blocking interrupt routines...)
> Den 2007-09-10 22:03:09 skrev John Temples <.....piclist3KILLspam.....xargs.com>:
>> That's a very old errata going back to the first generation of 18F
>> parts (circa 2002). I'd be surprised if it were present in recent
>> silicon.
>
> One reason I did choose PIC18 before dsPIC is that it is elder, and all bugs should have been found.
>
> I *AM* surprised :(
I wouldn't consider a response from Microchip technical support to be
the last word. Did they specifically say that this was an unreleased
errata for the processor you're using?
> We have had resets, seldom.
If you were getting stack overflow resets, the STKFUL bit would be
set.
> On Mon, 10 Sep 2007, Morgan Olsson wrote:
>
>> Den 2007-09-10 22:03:09 skrev John Temples <piclist3spam_OUTxargs.com>:
> I wouldn't consider a response from Microchip technical support to be
> the last word. Did they specifically say that this was an unreleased
> errata for the processor you're using?
I have asked back for more specifics.
> If you were getting stack overflow resets, the STKFUL bit would be
> set.
I think we tried looking for that but did not find it.
Before we now changed itnerrupts to all in one level we had too much problkem tpo have it runign at all.
We had it running with less errors using the CCS compiler last month.
The results of jumping wrong or missong an odd instruction could trigger the program to perform other then intended functions, one being restart.
>
> Den 2007-09-10 23:01:08 skrev John Temples <KILLspampiclist3KILLspamxargs.com>:
>
> > On Mon, 10 Sep 2007, Morgan Olsson wrote:
> >
> >> Den 2007-09-10 22:03:09 skrev John Temples <RemoveMEpiclist3TakeThisOuTxargs.com>:
>
> > I wouldn't consider a response from Microchip technical support to be
> > the last word. Did they specifically say that this was an unreleased
> > errata for the processor you're using?
>
> I have asked back for more specifics.
>
> > If you were getting stack overflow resets, the STKFUL bit would be
> > set.
>
> I think we tried looking for that but did not find it.
> Before we now changed itnerrupts to all in one level we had too much
> problkem tpo have it runign at all.
> We had it running with less errors using the CCS compiler last month.
> The results of jumping wrong or missong an odd instruction could trigger
> the program to perform other then intended functions, one being restart.
>
> --
> Morgan Olsson
> On Mon, 10 Sep 2007, Morgan Olsson wrote:
>
>> Den 2007-09-10 22:03:09 skrev John Temples <TakeThisOuTpiclist3EraseMEspam_OUTxargs.com>:
>>> That's a very old errata going back to the first generation of 18F
>>> parts (circa 2002). I'd be surprised if it were present in recent
>>> silicon.
>>
>> One reason I did choose PIC18 before dsPIC is that it is elder, and all bugs should have been found.
>>
>> I *AM* surprised :(
>
> I wouldn't consider a response from Microchip technical support to be
> the last word. Did they specifically say that this was an unreleased
> errata for the processor you're using?
They do not know if PIC18FxxJxx is affected. PIC18 is.
( We use PIC18F66J15 )
But if it is this bug, it is more to it; we also find more strange things...
" Now the code seems to work with both high and low priorities simultaneously. The only change that I have made is to enable interrupts globally (high and low) AFTER all interrupt priorities have been set. Before I started with no IE-flags enabled, then enabled interrupts globally, then changed priorities and in the last step I enabled the IE-flags. Is the old method I used a no-no that produces glitches? I need to be 100% certain that I have found the bug before I dare to go on, as undefined behaviour in this product might hurt people (industrial application). "
> After a couple hundred man hours... (yes, we are nuts probably...)
> After submitting a support ticket and poning we finally got an answer that explains problems:
>
> "
> Under certain conditions, the use of dual priority interrupts
> may cause a program instruction to be skipped entirely.
> This has only been observed when both of the following apply:
>
> * Both high and low interrupts are enabled, and
>
> * A high priority asynchronous interrupt occurs in the
> following cycle after any low priority interrupts.
>
> The event causes the stack to get pushed twice,
> and will eventually result in an overflow.
> "
>
> AAAAAAHHH !!!
>
>
> And this is not in any errata, and still Microchip knows about it.
> (although a month ago when we asked they did not know any bugs not described in the erratas)
>
> OK... whatever...
> Before we go on programming around that bug...
>
> Any idea how we can get to know all bugs, not just the ones released in erratas?
>
> forum.microchip.com/tm.aspx?m=280401&mpage=3
>
> " Now the code seems to work with both high and low priorities
> simultaneously. The only change that I have made is to enable interrupts
> globally (high and low) AFTER all interrupt priorities have been set.
> Before I started with no IE-flags enabled, then enabled interrupts
> globally, then changed priorities and in the last step I enabled the
> IE-flags. Is the old method I used a no-no that produces glitches? I
> need to be 100% certain that I have found the bug before I dare to go
> on, as undefined behaviour in this product might hurt people (industrial
> application). "
I can't help with 100% certainty, but I've never seen the behavior you are
describing -- but I always set up the priorities before globally enabling
interrupts (18F series).
Gerhard Fiedler wrote:
> Morgan Olsson wrote:
>
>
>>forum.microchip.com/tm.aspx?m=280401&mpage=3
>>
>>" Now the code seems to work with both high and low priorities
>>simultaneously. The only change that I have made is to enable interrupts
>>[...]
>
> I can't help with 100% certainty, but I've never seen the behavior you are
> describing -- but I always set up the priorities before globally enabling
> interrupts (18F series).
Go to AVR, do not look back. I finally did. An undocumented bug in
usart hardware that made code fully working on two chips fail weirdly
was the last straw. Fortunately since I knew the code was fine I only
lost a day and a half - had I been doing the original development with
this chip, it would have been a week gone. Microchip is run by the
marketing/sales dept. not engineering. I've been pretty impressed by
AVR studio + winavr (GCC port) though it has only been 3 projects so
far. Really - leave mchip behind.
> It's just one more example of what I have been bitching about.
> They know about the problems but don't bother to advertise them.
> I have YET to see ANY of the SPI problems I have uncovered advertised!
> I get REAL tired of being their unpaid B-Site!!!
>
> *
> | __O Thomas C. Sefranek WA1RHPEraseME.....ARRL.NET
> |_-\<,_ Amateur Radio Operator: WA1RHP
> (*)/ (*) Bicycle mobile on 145.41MHz PL74.4
>
> ARRL Instructor, Technical Specialist, VE Contact.
> hamradio.cmcorp.com/inventory/Inventory.html
> http://www.harvardrepeater.org
>
> -----Original Message-----
> From: EraseMEpiclist-bouncesmit.edu [RemoveMEpiclist-bouncesEraseMEEraseMEmit.edu] On Behalf Of
> Morgan Olsson
> Sent: Monday, September 10, 2007 3:37 PM
> To: Microcontroller discussion list - Public.
> Subject: [PIC] PIC18 interrupt bug
>
> After a couple hundred man hours... (yes, we are nuts probably...)
> After submitting a support ticket and poning we finally got an answer that
> explains problems:
>
> "
On 9/12/07, Jesse Lackey <RemoveMEjsl-mlspam_OUTKILLspamcelestialaudio.com> wrote:
> Go to AVR, do not look back. I finally did. An undocumented bug in
> usart hardware that made code fully working on two chips fail weirdly
> was the last straw. Fortunately since I knew the code was fine I only
> lost a day and a half - had I been doing the original development with
> this chip, it would have been a week gone. Microchip is run by the
> marketing/sales dept. not engineering. I've been pretty impressed by
> AVR studio + winavr (GCC port) though it has only been 3 projects so
> far. Really - leave mchip behind.
>
That is certainly not a good advice for the application -- an industrial
application. Atmel AVR is not known to last long but PIC is. On the
other hand, Atmel 8051 seems to be better.
For hobbyist or very low quantity or very large quantity, AVRs might
be ok with good support from Atmel. For medium size industrial
customers, Atmel is a bad choice, at least from my experience.
They obsolete their first generation AVR90S after only 4 years in
the market. Recently they just obsolete the another 5V EEprom
and recommend a 3.3V EEprom for "replacement". Very good,
I just changed the design to use a Microchip EEprom.
AVR is a good choice for hobbyists due to good support from
simple programmers and AVR-gcc.
And Atmel chips have bugs as well. Bugs are inevitable.
> Go to AVR, do not look back. I finally did. An undocumented bug in
> usart hardware that made code fully working on two chips fail weirdly
> was the last straw. Fortunately since I knew the code was fine I only
> lost a day and a half - had I been doing the original development with
> this chip, it would have been a week gone. Microchip is run by the
> marketing/sales dept. not engineering. I've been pretty impressed by
> AVR studio + winavr (GCC port) though it has only been 3 projects so
> far. Really - leave mchip behind.
>
On 9/11/07, Xiaofan Chen <RemoveMExiaofancTakeThisOuTspamgmail.com> wrote:
> AVR is a good choice for hobbyists due to good support from
> simple programmers and AVR-gcc.
>
> And Atmel chips have bugs as well. Bugs are inevitable.
Does anyone know of any detailed PIC vs. AVR documents out there?
On 9/13/07, Jon Philpott <EraseMEjon.philpottspamspamBeGonegmail.com> wrote:
> On 9/11/07, Xiaofan Chen <RemoveMExiaofancKILLspamgmail.com> wrote:
> > AVR is a good choice for hobbyists due to good support from
> > simple programmers and AVR-gcc.
> >
> > And Atmel chips have bugs as well. Bugs are inevitable.
>
>
> Does anyone know of any detailed PIC vs. AVR documents out there?
>
That depends on your target. They are both very good for hobbyists
and you can search "pic versus avr" on google and find quite some hits.
Many of them are biased.
I tend to think Microchip is a better company to work with than Atmel.
Atmel has good product but is not foucused enough and thus lose
money and is smaller in Market capital than Microchip despite being
a bigger company. Microchip support is excellent. I am biased as well...
On 9/12/07, Xiaofan Chen <KILLspamxiaofancspamBeGonegmail.com> wrote:
> And with dsPIC30/PIC24/dsPIC33 and the almost free GCC based
> C30, dsPIC is not bad as well for hobbyists.
I need to investigate dsPIC and PIC24 a little more! I like that some
of the PIC24s have 8k of RAM.
> That's got to be the most biased and inaccurate comparison I've
> ever seen.
It's not exactly biased, more like ... shallow and based on hearsay.
But I don't like it much either.
Too many of the comparisons are aimed at deciding which one is "better",
and I think the fact of the matter is that for most practical purposes,
either one is "good enough." I still like my summary opinion that PIC
does "small" better, and Atmel does "large" better. I haven't been able
to get at all enthusiastic about the PIC24/PIC30 series; by the time I
go to a 16 bit architecture, I expect it to have a bit more elegance
(ala PDP11.) OTOH, even as a hobbyist, I find Atmel's quick
discontinuation
of parts and lack of business success ... troubling.
You can find my thoughts on things here:
www.instructables.com/id/EKRQRQHQDIEWH1IMC9
(be sure to read the comments; a lot of people have added info...)
> > > Does anyone know of any detailed PIC vs. AVR documents out there?
>
> This is not *very* detailed, but a pretty good comparison
> nonetheless: http://www.ladyada.net/library/picvsavr.html
I have sent the guy (gall?) some more:
===========================================
a few contributions:
Beginning hobbyists might not be interested in very small packages, but
there are very little PICs in 6-pin SMD package. Size of a small SMD
transistor, and very cheap. No compareable AVRs exist, mainly (I think)
because the AVR hardware dedicates some pins to the programmaing
process. (PIC: +) OTOH dedicating some pins to the programming process
means that a cheap but reliable DIY AVR programmer can be much simpler
than a compareable PIC programmer (AVR: +)
All AVRs share the same internal architecture, from the small 8-pin
chips to the largest SMDs. The same is not true for PICs. The popular
12F and 16F series contain a mix primitive 12-bit core chips and
slightly better 14-bit core chips. The 16-bit core 18F chips have a much
better architecture, which is still quite similar to the 12 and 14 bit
core chips. The various dsPIC chips are very different. Who is the
winner here? I dunno, depends on your preferences. (winner: ?)
PICs have a very 'clear' numbering system. Chips with 6 pins are called
10F, 8 pins chips are called 12C or 12F. C is for EPROM chips, F for
flash, except 16C84 which is flash. 12 and 14 bit core chips with more
pins are called 16F. 18F's are 16-bit core chips. John Cleese could not
have done a better job. AVRs are all the same internally, except for the
very first one who had no RAM and a reduced instruction set (I forgot
the type number, and I think Atmel wants to forget this chip too). But
for no apparent reason the chips are called AVR, tinyAVR or megaAVR.
Winner: both companies are big losers in this aspect, but Microchip is
clearly in the lead (as loser).
PICs tend to run on higher clock frequencies that AVRs, but use 4 clock
cycles for each instruction, so in the end an AVR is often somewhat
faster than a PIC (in instructions per second), and often (but not
always) you will need slightly more PIC instructions than AVR
instructions to achive the same result. But be carefull which PIC
architecture you compare with! And note that some PICs have a PLL, so
they can run internally on 40 MHz (but that is only 10 MIPs) on a 10 MHz
crystal. (winner: AVR, but the margin is small)
Microchip, the manufacturer of PICs, has a good reputation for continued
support. A chip that is sold now will likely be available for the next
10 years, probably much longer, or a suitable drop-in replacement will
be made available. Atmel (manufacturer of AVRs) doe not have such a good
reputation in this aspect (some say: a very bad reputation). Is this
important? If you are a product manufacturer and you want to make your
product for a long time this might be more important than any other
argument, including price, architecture and performance. And because
such manufacturers exist, PIC skills are in demand in the professional
market. But if you are a hobbyist, or a manufacturer that needs a
product on the market now (and fast, tomorrow is not quick enough!) and
its lifespan is probably no more than a year, then you could not care
less.
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
> PICs have a very 'clear' numbering system. Chips with 6 pins are called
> 10F, 8 pins chips are called 12C or 12F. C is for EPROM chips, F for
> flash, except 16C84 which is flash.
I thought that chip had eeprom not flash program memory
> > PICs have a very 'clear' numbering system. Chips with 6 pins are
> > called 10F, 8 pins chips are called 12C or 12F. C is for
> EPROM chips,
> > F for flash, except 16C84 which is flash.
> I thought that chip had eeprom not flash program memory
Microchip indeed called the 16C84 EEPROM instead of flash, but as far as
I am concerned 'if it quacks like a duck...'.
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
> PICs tend to run on higher clock frequencies that
> AVRs, but use 4 clock
> cycles for each instruction, so in the end an AVR is
> often somewhat
> faster than a PIC (in instructions per second), and
> often (but not
> always) you will need slightly more PIC instructions
> than AVR
> instructions to achive the same result. But be
> carefull which PIC
> architecture you compare with! And note that some
> PICs have a PLL, so
> they can run internally on 40 MHz (but that is only
> 10 MIPs) on a 10 MHz
> crystal. (winner: AVR, but the margin is small)
>
Some of the AVR chips like the Atmega88 is pretty
fast. With instruction cycles as low as 1 clock and at
times 2 clocks. Perhaps it is a poor comparison when I
compare it with PIC16F876A or PIC16F873A. I do find it
useful when I am toggling bits at MHz for an AVR.
> Microchip, the manufacturer of PICs, has a good
> reputation for continued
> support. A chip that is sold now will likely be
> available for the next
> 10 years, probably much longer, or a suitable
> drop-in replacement will
> be made available. Atmel (manufacturer of AVRs) doe
> not have such a good
> reputation in this aspect (some say: a very bad
> reputation). Is this
> important? If you are a product manufacturer and you
> want to make your
> product for a long time this might be more important
> than any other
> argument, including price, architecture and
> performance. And because
> such manufacturers exist, PIC skills are in demand
> in the professional
> market. But if you are a hobbyist, or a manufacturer
> that needs a
> product on the market now (and fast, tomorrow is not
> quick enough!) and
> its lifespan is probably no more than a year, then
> you could not care
> less.
>
I would agree that Microchip is dead serious about
continuity. Each project I do I tend to side to PIC
Microchip due to availability.
John
____________________________________________________________________________________
Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV. http://tv.yahoo.com/
>> > F for flash, except 16C84 which is flash.
>>
>> I thought that chip had eeprom not flash program memory
>
>Microchip indeed called the 16C84 EEPROM instead of flash,
>but as far as I am concerned 'if it quacks like a duck...'.
Agreed.
The 16C84 is really the first chip they did with flash program memory - but
it also has EEPROM data memory. This being the first chip they had done like
this, they hadn't got to the point of thinking through what terminology they
would use to distinguish the different EEPROM memory areas, and it was only
later they realised that they should have replaced the 'C' with an 'F', so
they did that when they updated the chip to the 16F84 ...
>>>> F for flash, except 16C84 which is flash.
>>> I thought that chip had eeprom not flash program memory
>> Microchip indeed called the 16C84 EEPROM instead of flash,
>> but as far as I am concerned 'if it quacks like a duck...'.
>
> Agreed.
>
> The 16C84 is really the first chip they did with flash program memory - but
> it also has EEPROM data memory. This being the first chip they had done like
> this, they hadn't got to the point of thinking through what terminology they
> would use to distinguish the different EEPROM memory areas, and it was only
> later they realised that they should have replaced the 'C' with an 'F', so
> they did that when they updated the chip to the 16F84 ...
>
Err, yes, but the marketing types at Microchip do use the term 'Flash' to
distinguish the program memory EEPROM area from the 'EEPROM' data area. And
in a Microchip device they do tend to have different maximum number of write
cycle specifications.
I do appreciate that other manufacturers use the terms interchangeably for
the same device, while others tend to use the term 'Flash' for devices that
can be written at the same speed as the read cycle speed, and use 'EEPROM'
for devices that take a significant length of time (in cycle speed terms) to
do the write.
On Sep 13, 2007, at 2:06 AM, Jan-Erik Soderholm wrote:
> "Flash" *IS* "EEPROM", not ?
I think that the usual distinction is that EEPROM
is read/writable on an individual byte basis, while
"FLASH" tends to omit such in favor of high density.
But it's all marketing terms. I think that electricallly
speaking, the programable memory in most micros is
closer to "EEPROM" cells than the "flash" cells made
famous in the very-high density chips "NAND or NOR" flash.
On Wed, 2007-09-12 at 22:39 -0700, Jon Philpott wrote:
> On 9/12/07, Xiaofan Chen <@spam@xiaofanc@spam@spam_OUTgmail.com> wrote:
> > And with dsPIC30/PIC24/dsPIC33 and the almost free GCC based
> > C30, dsPIC is not bad as well for hobbyists.
>
> I need to investigate dsPIC and PIC24 a little more! I like that some
> of the PIC24s have 8k of RAM.
And even better if you look at the 33 series some have 16 and 32k of
RAM! :) TTYL
On Thu, 2007-09-13 at 09:44 +0200, wouter van ooijen wrote:
> All AVRs share the same internal architecture, from the small 8-pin
> chips to the largest SMDs. The same is not true for PICs. The popular
> 12F and 16F series contain a mix primitive 12-bit core chips and
> slightly better 14-bit core chips. The 16-bit core 18F chips have a much
> better architecture, which is still quite similar to the 12 and 14 bit
> core chips. The various dsPIC chips are very different.
Ahh, but this depends on how you're programming. This is an area where
an HLL REALLY helps. I've moved projects from 18F to 30F PICs with very
minimal code changes. Yes, some peripheral stuff is different, but a
quick read of the datasheet shows those differences. In the end, porting
one of my designs between the 16F, 18F and 30F series is very easy and
very quick.
It seems people take a quick look at the 30F series, see it's
"different", and run away scared. If you spent time to sit down and
actually have a closer look at the 30F (and related) series you'd
realize that yes, they are different, but they are also very "familiar"
to those used to the smaller families and the differences are in the end
quite minor.
The "freedom" when designing for these bigger chips is wonderful, and
the "feels like home" compared to the 16F and 18F series really makes
these chips a wonderful choice for anyone who's familiar with "PICs".
TTYL
> > All AVRs share the same internal architecture, from the small 8-pin
> > chips to the largest SMDs. The same is not true for PICs.
> The popular
> > 12F and 16F series contain a mix primitive 12-bit core chips and
> > slightly better 14-bit core chips. The 16-bit core 18F chips have a
> > much better architecture, which is still quite similar to
> the 12 and
> > 14 bit core chips. The various dsPIC chips are very different.
>
> Ahh, but this depends on how you're programming. This is an
> area where an HLL REALLY helps. I've moved projects from 18F
> to 30F PICs with very minimal code changes. Yes, some
> peripheral stuff is different, but a quick read of the
> datasheet shows those differences.
OK, but expanding that argument PIC, AVR, MSP430 and ARM are almost the
same. Just use C, and read the peripherals sections :) In a sense this
is true. But my text was more a warning that when *architectures* are
compared, throwing all PICs on one heap is only slightly less stupid
than throwing AVRs on the same heap too. When you compare PIC and AVR
architectures, please specify which PIC core. Of course, when you
compare chips at the C level the architecture matters much less.
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
>> All AVRs share the same internal architecture, from the small 8-pin
>> chips to the largest SMDs. The same is not true for PICs.
It's not THAT true for AVRs either. Presence or absence of RAM is a
relative big issue, but there are a fair number of other subtle
differences between different chips that will jump out and bite
you if you're not paying attention.
One of my biggest complaints about the AVR is that they tout this
great architecture with general purpose registers and etc, and then
you go to write assembler and THIS instruction only works on R16-R31,
and THAT instruction only works on the first 64 IO registers, and THE
OTHER instruction works on X,Y, or Z on THAT processor, but only Z on
the one I happen to be using... Grr.
Zik Saleeba wrote:
>
> Wow. That's got to be the most biased and inaccurate comparison I've ever
> seen.
Can you give some pointers to indicate updates I should make? (it -does- say
at the top that its a biased comparison ;)
> I particularly like the "I've never used X on the PIC but the AVR
> version is better!" comments that appear throughout.
Hmm, I searched the text and the only time "i've never used" is mentioned is
with "gpasm" and in that case I don't really compare the assembler as much
as the assembly. it -has- been a while since i did pic assembly (its also
been a while since i updated that page) but man did it suck (retlw,
accumulators, ugh!). I can't imagine the assembly -language- or architecture
has changed significantly...
Any constructive suggestions y'all can give are much appreciated, email is
best as I don't read every post to piclist. My email address is right there
at the top of the page, right next to where it says "I am not really an
expert here, so please help me fill in this page with more useful info,
email me at and make the topic something like "PIC v. AVR". Thanks!" :)
limor spamBeGoneladyadaKILLspamgmail.com
--
View this message in context: www.nabble.com/PIC18-interrupt-bug-tf4417939.html#a12659084
Sent from the PIC - [PIC] mailing list archive at Nabble.com.
> It's not THAT true for AVRs either. Presence or absence of
> RAM is a relative big issue,
Are there more beside that first chip that have no RAM?
> but there are a fair number of
> other subtle differences between different chips that will
> jump out and bite you if you're not paying attention.
Out of 'academic' interest (I don't use AVRs): what other issues are
there beside what you already mention? I read the architecture document
once (years ago) when I briefly considered JAL-for-AVR, but that never
happened. I recall that I could not easily see which instructions are
available on wich chips.
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
>
> >> All AVRs share the same internal architecture,
> from the small 8-pin
> >> chips to the largest SMDs. The same is not true
> for PICs.
>
> It's not THAT true for AVRs either. Presence or
> absence of RAM is a
> relative big issue, but there are a fair number of
> other subtle
> differences between different chips that will jump
> out and bite
> you if you're not paying attention.
>
> One of my biggest complaints about the AVR is that
> they tout this
> great architecture with general purpose registers
> and etc, and then
> you go to write assembler and THIS instruction only
> works on R16-R31,
> and THAT instruction only works on the first 64 IO
> registers, and THE
> OTHER instruction works on X,Y, or Z on THAT
> processor, but only Z on
> the one I happen to be using... Grr.
>
> BillW
> --
For assembly it is way way out... Even x86 assembly is
more understandable. PIC assembly is the easiest but
at times I do wish more instructions.
John
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/
On Sep 13, 2007, at 10:13 AM, wouter van ooijen wrote:
>
> Are there more beside that first chip that have no RAM?
ATtiny11, ATtiny12, ATtiny15, ATtiny28, AT90S1200. IIRC, you have that
bias toward bigger chips, while I have a bias to tiny chips. :-) I
think
pretty much all of the newer chips have RAM, and many of the chips that
don't have it are being discontinued. Of course, way back when, I
bought
a bunch ("hobbyist lifetime supply"?) of tiny11, tiny28s, and 90s1200
chips.
One might say I made particularly unlucky choices.
> Out of 'academic' interest (I don't use AVRs): what other issues are
> there beside what you already mention? I read the architecture
> document
> once (years ago) when I briefly considered JAL-for-AVR, but that never
> happened. I recall that I could not easily see which instructions are
> available on wich chips.
I'm not sure. As you say, they're not so good at pointing out the
differences between chips. It's like whenever I try to write a program
I get some clever idea that ends up requiring that I dig down trying
to figure out whether that feature is present on the chip I'm using,
and whether there are differences in how to use it. (the last case
was "lpm" (reading data from program memory) on tiny11 (present, but
doesn't support autoincrement addressing mode) (I guess 90s1200 is the
only device that completely lacks the lpm instruction.)
There are the x, y, and z registers for indexed and indirect addressing,
with assorted modes, but some chips don't have all of them, and don't
support all the addressing modes...
>> Are there more beside that first chip that have no RAM?
>
> ATtiny11, ATtiny12, ATtiny15, ATtiny28, AT90S1200.
OK, I remembered only the AT90S.
> There are the x, y, and z registers for indexed and indirect
> addressing, with assorted modes, but some chips don't have
> all of them, and don't support all the addressing modes...
I think I'll revise my idea about PIC archicture (bad) versus AVR
architecture (good) somewhat in disfavour of AVR :)
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
On 9/14/07, ladyada <TakeThisOuTladyada.....TakeThisOuTgmail.com> wrote:
>
> Zik Saleeba wrote:
> >
> > Wow. That's got to be the most biased and inaccurate comparison I've ever
> > seen.
>
> Can you give some pointers to indicate updates I should make? (it -does- say
> at the top that its a biased comparison ;)
I've responded to ladyada offlist. My apologies to them for being so
critical of their article. When I reread the article I realised it
wasn't as bad as I had first thought.
I've sent a number of factual corrections and suggestions as well.
On 9/13/07, Zik Saleeba <TakeThisOuTzikKILLspamspamzikzak.net> wrote:
> On 9/14/07, ladyada <.....ladyadaRemoveMEgmail.com> wrote:
> >
> > Zik Saleeba wrote:
> > >
> > > Wow. That's got to be the most biased and inaccurate comparison I've ever
> > > seen.
> >
> > Can you give some pointers to indicate updates I should make? (it -does- say
> > at the top that its a biased comparison ;)
>
> I've responded to ladyada offlist. My apologies to them for being so
her :)
thanks to everyone who has sent in notes, i am a bit busy wrapping up
this week but will integrate them into the page as soon as possible
limor
ps. the idea of a pic v avr page is, admittedly, completely stupid.
however, i get a lot of emails asking me this questions so at least
now i can just say "read this and if it doesnt answer your question
-then- you can come back to me!"
On 9/13/07, limor <RemoveMEladyadaspamBeGonegmail.com> wrote:
> ps. the idea of a pic v avr page is, admittedly, completely stupid.
> however, i get a lot of emails asking me this questions so at least
> now i can just say "read this and if it doesnt answer your question
> -then- you can come back to me!"
Perhaps versus isnt the right word. A page comparing them on their
merits and downfalls sounds better ;)
For me, PIC documentation is easier to understand than AVR
documentation. Whether the structure or the information contained in,
I give (+) for PIC on documentation.
On Sep 13, 2007, at 12:28 PM, wouter van ooijen wrote:
>> There are the x, y, and z registers for indexed and indirect
>> addressing, with assorted modes, but some chips don't have
>> all of them, and don't support all the addressing modes...
>
> I think I'll revise my idea about PIC archicture (bad) versus AVR
> architecture (good) somewhat in disfavour of AVR :)
I may be skewed by my choice of chips. It looks like perhaps only
the "legacy" chips have some of the limitations I'm complaining about,
with everything recent being "better." Of course, it's the lack of
making things CLEAR that I most object to. If you're going to claim
that you have an elegant architecture, but certain chips are missing
aspects of that architecture, it ought to be made CLEAR rather than
be hidden. The PIC is an example in the other direction; everyone
knows that the PIC architecture is a bit old and clunky, but it's
all very well ... explained, and ceases to be such a big issue.
> it -has- been a while since i did pic assembly (its also
> been a while since i updated that page) but man did it suck
Not in my opinion. It is different.
A decade ago i moved from HC05 to PIC16, and it felt like
a great upgrade once having learnt how to handle it.
I made lots of macros with snippets so it could for example do
comparision-and-jump with one "instruction".
That made it a lot mor readable and i could code much better...
(even better than other processors plain assembly, but then macros could be used on any uC)
-BUT then no other developer can read it easily unless he learns my macros...
Being a one man company i do not care much.
The instructions seem very weird but you can do lot of tricks when you learn how.
For exaple decude a status by gathering bits then add them to PC, and it jumps to the routine.
PICLIST.COM have gathered a klot of tricks, and i have a lot old gathered in a mail database too.
A lot of thrick however the compilers cannot do, so for optimal speed things must be done in assembly with a bit of knowledge...
On the other hand the compilers can help a lot when handlign strings or math, etc.
Having studied the code generated by C18 and CCs copmpiler si must say they can do lot of code size optimisaitons and register reuse, but speed optimisaitons is not that good... And interrupt context sace/restore sucks.
Mainly the problem is that a human knowing the assembly and hardware can optimize/select the method to do things and then code directly in assembly. Some hints ant tricks just not possible to express in C.
The recent problem however have learnt me it is MUCH more difficult do debug C code than assembly when the hardware is not working correctly, plus there is no real ICE available (Real-ICE is far from a real ICE, but it has the advantage that the target is running the code with all hardware bugs real.) and the software for the "ICE" is pretty lousy too...
Adding the problems my collegue have had translating between differnet C dialects i think C seem very overrated for machine level programming alltogether of any quality is needed... But i still intend to learn some day.
Yeah....the "replacement" EEPROM was a different footprint...so one guy I know had to spin his board JUST for that. Thats the biggest reason ive not gone the ATMEL path...long term support
Xiaofan Chen <TakeThisOuTxiaofancspamgmail.com> wrote: On 9/12/07, Jesse Lackey wrote:
> Go to AVR, do not look back. I finally did. An undocumented bug in
> usart hardware that made code fully working on two chips fail weirdly
> was the last straw. Fortunately since I knew the code was fine I only
> lost a day and a half - had I been doing the original development with
> this chip, it would have been a week gone. Microchip is run by the
> marketing/sales dept. not engineering. I've been pretty impressed by
> AVR studio + winavr (GCC port) though it has only been 3 projects so
> far. Really - leave mchip behind.
>
That is certainly not a good advice for the application -- an industrial
application. Atmel AVR is not known to last long but PIC is. On the
other hand, Atmel 8051 seems to be better.
For hobbyist or very low quantity or very large quantity, AVRs might
be ok with good support from Atmel. For medium size industrial
customers, Atmel is a bad choice, at least from my experience.
They obsolete their first generation AVR90S after only 4 years in
the market. Recently they just obsolete the another 5V EEprom
and recommend a 3.3V EEprom for "replacement". Very good,
I just changed the design to use a Microchip EEprom.
AVR is a good choice for hobbyists due to good support from
simple programmers and AVR-gcc.
And Atmel chips have bugs as well. Bugs are inevitable.
> Having studied the code generated by C18 and CCs copmpiler si must say
> they can do lot of code size optimisaitons and register reuse, but speed
> optimisaitons is not that good...
If you want to speed-optimize C, you need to learn how to optimize speed
with the compiler you're using on the target you're using. Some things are
rather common for a class of targets (e.g. a decrementing loop is usually
faster than an incrementing loop on small or risc type processors), others
are dependent on the way a specific compiler generates code for a specific
target.
> And interrupt context sace/restore sucks.
This is /very/ much compiler dependent and not a feature of C. Ideally the
compiler only saves what is needed, but most compilers are more or less far
away from that ideal.
> Some hints ant tricks just not possible to express in C.
There are few things that can not be done. If you know how the compiler
works, in most cases you can generate C code that gets translated almost
1:1 into assembly.
> The recent problem however have learnt me it is MUCH more difficult do
> debug C code than assembly when the hardware is not working correctly,
I don't quite understand why you think this. While there are of course pros
and cons to both, hardware access in C doesn't seem to be any different
from hardware access in assembly. When I write "myProblemRegister =
0b00101100;" that gets translated into pretty much (probably rather
'exactly') the same sequence you'd use in assembly. If the 0b00101100 is
wrong, it's wrong the same way in both...
> Adding the problems my collegue have had translating between differnet C
> dialects i think C seem very overrated for machine level programming
I don't think that's the problem. I think C is overrated for high-level
programming: for me, C is /not/ a HLL (High Level Language), it is more
something like an RPA (Reasonably Portable Assembler). Once you understand
it, I think you'll find much more commonality between C and assembly than
between C and a language that is actually /high/ level (even though some of
them borrowed the basic C syntax).
One of the major problems for C programmers who learned on Unix, Windows or
other high level systems and hardware is to understand how smaller systems
work. It's not so much the language that changes but the programming
techniques, due to the different environment. You can't necessarily expect
a (good) PC C programmer to write good code for an 8-bit embedded
programmer without having to learn a few things. And if he doesn't take the
time to learn these things, the code will be too complicated, too slow and
difficult to debug.
As far as I can tell the original poster said nothing about the
application, industrial or otherwise nor part availability 5+ years from
now being a requirement. For requirements like that, issues beyond
dealing with buggy hardware and dev toos take priority.
J
Xiaofan Chen wrote:
> On 9/12/07, Jesse Lackey <jsl-mlEraseMEcelestialaudio.com> wrote:
>> Go to AVR, do not look back. I finally did. An undocumented bug in
>> usart hardware that made code fully working on two chips fail weirdly
>
> That is certainly not a good advice for the application -- an industrial
> application. Atmel AVR is not known to last long but PIC is. On the
> other hand, Atmel 8051 seems to be better.
>
On 9/14/07, Morgan Olsson <RemoveMEost011EraseMEspam_OUTosterlen.tv> wrote:
> Having studied the code generated by C18 and CCs copmpiler
> si must say they can do lot of code size optimisaitons and register
> reuse, but speed optimisaitons is not that good... And interrupt
> context sace/restore sucks.
>
> Mainly the problem is that a human knowing the assembly and
> hardware can optimize/select the method to do things and then code
> directly in assembly. Some hints ant tricks just not possible to express in C.
>
I will leave this to the C expert here.
> The recent problem however have learnt me it is MUCH more difficult
> do debug C code than assembly when the hardware is not working
> correctly, plus there is no real ICE available (Real-ICE is far from a
> real ICE, but it has the advantage that the target is running the code
> with all hardware bugs real.) and the software for the "ICE" is pretty
> lousy too...
When the hardware is not working properly, how do you debug the
firmware?? The firmware designer can write the code based on
well defined hardware interface but the hardware/firmware integration
is definetly necessary. Often you can simplified the hardware and
build a fast prototype board for the firmware designer.
I think this is a valid concern with big 18J device and many PIC24/dsPIC33
device. Only ICD2 and RealICE support them but not ICE2000/ICE4000.
I have not used RealICE but I got the impression it is just a glorified
ICD2. To be honest I do not like ICD2 as a debugger because I started
to work with PIC in year 2000 with ICE2000 and HiTech PICC 7.85 and
Promate II. This setup helped me to jump start from knowing nothing
about PIC and C to finish a relative simple but important project in
relative fast time. ICE2000 certainly helped me.
John Temples thought that Howard was wrong. But apparent Howard
is correct. ICE2000/4000 really do not support PIC18J/K, PIC24 and
dsPIC33 as of now (MPLAB 7.62).
> Adding the problems my collegue have had translating between
> differnet C dialects i think C seem very overrated for machine
> level programming alltogether of any quality is needed... But i still
> intend to learn some day.
>
If you are referring to the Microchip forum thread and I think your
firmware designer needs some mindset changes in the MCU word.
I am certain he must be good in C coding (much better than I anyway)
but he needs some time to adapt in the PIC world. http://forum.microchip.com/tm.aspx?m=280401
C is good for embedded design but a good C programmer in the
embed world must know quite some hardare and assembly as well.
> I started to work with PIC in year 2000 with ICE2000 and HiTech PICC
> 7.85 and Promate II. This setup helped me to jump start from knowing
> nothing about PIC and C to finish a relative simple but important
> project in relative fast time. ICE2000 certainly helped me.
Yes, the ICE 2000 was certainly much better for debugging than any of
the current serial devices, although it was cumbersome to use, with
all of the pieces you had to assemble, and then carefully arrange the
whole thing adjacent to your board, taking care that the transition
socket remained seated. You can't beat the simplicity of plugging in
the REAL ICE and getting to work, especially if you're working on five
different projects in the same day.
> Initially when I read the forum post I am a bit doubtful about the
> debugging options for the 3.3V PICs/dsPICs.
> http://forum.microchip.com/tm.aspx?m=196742
>
> And I started a thread in PIC list about the Debugging Options
> for pure 3.3V PIC parts (PIC18J, 18K, dsPIC33, PIC24).
>
> John Temples thought that Howard was wrong. But apparent Howard
> is correct. ICE2000/4000 really do not support PIC18J/K, PIC24 and
> dsPIC33 as of now (MPLAB 7.62).
Howard was wrong; he corrected himself in the last post of the thread.
He said, "Also keep in mind that the ICE2000/4000 will not support any
3.3V operating part." What he meant was "any of the newer 3.3V-only
parts." The MPLAB ICE 2000 does support 3.3V operation, as the help
file states: "MPLAB ICE 2000 also supports low voltage emulation, from
2.0V to 4.6V." The fact that it doesn't support the 18FJ/PIC30 has
nothing to do with an inability to support 3.3V.
I have no idea what the obstacles are to making a real (lower case)
ICE that supports the 18FJ/PIC30 parts, but it seems that's not going
to happen any time soon.
On 9/15/07, John Temples <@spam@piclist3RemoveMEEraseMExargs.com> wrote:
> On Sat, 15 Sep 2007, Xiaofan Chen wrote:
>
> > I started to work with PIC in year 2000 with ICE2000 and HiTech PICC
> > 7.85 and Promate II. This setup helped me to jump start from knowing
> > nothing about PIC and C to finish a relative simple but important
> > project in relative fast time. ICE2000 certainly helped me.
>
> Yes, the ICE 2000 was certainly much better for debugging than any of
> the current serial devices, although it was cumbersome to use, with
> all of the pieces you had to assemble, and then carefully arrange the
> whole thing adjacent to your board, taking care that the transition
> socket remained seated. You can't beat the simplicity of plugging in
> the REAL ICE and getting to work, especially if you're working on five
> different projects in the same day.
>
Wow, life is so stress for you. :-)
I never have five diffierent projects in the same YEAR. Actually
most of my past projects runs more than one
year and at most two project at the same time (not counting
support production). I only managed to finish three major
projects (involving firmware) in my previous job (1999-2006
with a gap in 2003) and 3 small projects (no firmware).
The firmwares were all quite simple even though sometimes
the hardware were quite challenging due to cost and space
contraint.
One of the "very simple" field bus terminator was a side
project for me last time but it took us more than one year to
develop it due to lack of understanding of the standards. It
was only using four resistors, a capacitor and a TVS. ;-)
Now I am in a different job but the project cycle is still
quite long since I am in the same industrial automation
segment.
Xiaofan Chen wrote:
> but the project cycle is still quite long since
> I am in the same industrial automation segment.
Why is that so? Does it take all that time to design the product or is
the testing part long.
> On 9/15/07, John Temples <EraseMEpiclist3@spam@xargs.com> wrote:
>> On Sat, 15 Sep 2007, Xiaofan Chen wrote:
>>
>>> I started to work with PIC in year 2000 with ICE2000 and HiTech PICC
>>> 7.85 and Promate II. This setup helped me to jump start from knowing
>>> nothing about PIC and C to finish a relative simple but important
>>> project in relative fast time. ICE2000 certainly helped me.
>> Yes, the ICE 2000 was certainly much better for debugging than any of
>> the current serial devices, although it was cumbersome to use, with
>> all of the pieces you had to assemble, and then carefully arrange the
>> whole thing adjacent to your board, taking care that the transition
>> socket remained seated. You can't beat the simplicity of plugging in
>> the REAL ICE and getting to work, especially if you're working on five
>> different projects in the same day.
>>
>
> Wow, life is so stress for you. :-)
>
> I never have five diffierent projects in the same YEAR. Actually
> most of my past projects runs more than one
> year and at most two project at the same time (not counting
> support production). I only managed to finish three major
> projects (involving firmware) in my previous job (1999-2006
> with a gap in 2003) and 3 small projects (no firmware).
> The firmwares were all quite simple even though sometimes
> the hardware were quite challenging due to cost and space
> contraint.
>
> One of the "very simple" field bus terminator was a side
> project for me last time but it took us more than one year to
> develop it due to lack of understanding of the standards. It
> was only using four resistors, a capacitor and a TVS. ;-)
>
> Now I am in a different job but the project cycle is still
> quite long since I am in the same industrial automation
> segment.
>
> Regards,
> Xiaofan
On 9/15/07, Mohit Mahajan <@spam@mohit.listsspam_OUT.....gmail.com> wrote:
> Xiaofan Chen wrote:
> > but the project cycle is still quite long since
> > I am in the same industrial automation segment.
> Why is that so? Does it take all that time to design the product or is
> the testing part long.
The electronics design is the fun part but it takes only about
1/3 of the time. Sometime the mechanical design can be
challenging or the limiting factor. The testing is always
taking quite some time (CE testing, UL testing, other
certification testing). Some certification takes a long time.
Trobleshooting EMC is not fun. Sometimes it takes years to
solve an EMC problem. You have a lot of guidelins for EMC
but you can not simply following them often because of space
constraints. Engineering is about compromise.
Typically two to three iteration is necessary. Sometimes it
takes forever to get it right and the project got cancelled.
Den 2007-09-15 04:37:59 skrev John Temples <spamBeGonepiclist3EraseMExargs.com>:
> You can't beat the simplicity of plugging in
> the REAL ICE and getting to work,
Heh, as per my post weh had Real Problem, until we understood that the pulldowns in Real ICE and PortB together made it sit at avoltage level so noise triggered the PortB change Interrupt...
(Also, pluggin in and out Real ICE sometimes makes MSWin go stupid, but that is a MS issue.. which could be avoided by selecting a better OS for the tools in the first place of course...)
> I have no idea what the obstacles are to making a real (lower case)
> ICE that supports the 18FJ/PIC30 parts,
I think that the problem for any *real* ICE is making it have exactly the same bugs no more no less than the intended target.
I think the idea with debugging built into the intended produciton chip is really nice.
Stupidly Fake-ICE is not more useable in assembler than ICD2, and it is not yet supported by any other compiler than C18, and not even there yu can incestigate the cariable stack that C18 use heavily. = not much debugging at all...
> On 9/14/07, Morgan Olsson <RemoveMEost011@spam@spamBeGoneosterlen.tv> wrote:
>
> When the hardware is not working properly, how do you debug the
> firmware?? The firmware designer can write the code based on
> well defined hardware interface but the hardware/firmware integration
> is definetly necessary.
If i had written the interrupt system in assembly i could much more easily have followed what is happening, ans put in code to track, and sucessively track down the problem much more easily, than when writing it in C.
> Often you can simplified the hardware and
> build a fast prototype board for the firmware designer.
The board cannot get much simpler than it is.
I would like to pull the PIC chip to pieces....
> I think this is a valid concern with big 18J device and many PIC24/dsPIC33
> device. Only ICD2 and RealICE support them but not ICE2000/ICE4000.
"Real-ICE" can not trace with detail, and can not easily be used at pure assembly, and even a lot of C variables are untraceable as we could not find a way to analyse the stack.
> On 9/15/07, John Temples <.....piclist3@spam@EraseMExargs.com> wrote:
>
>> On Sat, 15 Sep 2007, Xiaofan Chen wrote:
>>
>>> I started to work with PIC in year 2000 with ICE2000 and HiTech PICC
>>> 7.85 and Promate II. This setup helped me to jump start from knowing
>>> nothing about PIC and C to finish a relative simple but important
>>> project in relative fast time. ICE2000 certainly helped me.
>>>
>>
>> Yes, the ICE 2000 was certainly much better for debugging than any of
>> the current serial devices, although it was cumbersome to use, with all
>> of the pieces you had to assemble, and then carefully arrange the whole
>> thing adjacent to your board, taking care that the transition socket
>> remained seated. You can't beat the simplicity of plugging in the REAL
>> ICE and getting to work, especially if you're working on five different
>> projects in the same day.
>>
>>
> Wow, life is so stress for you. :-)
Welcome to the world of the engineer working for a small(er) company or the
independent consultant!
> I never have five diffierent projects in the same YEAR. Actually most of
> my past projects runs more than one
> year and at most two project at the same time (not counting support
> production). I only managed to finish three major projects (involving
> firmware) in my previous job (1999-2006 with a gap in 2003) and 3 small
> projects (no firmware). The firmwares were all quite simple even though
> sometimes the hardware were quite challenging due to cost and space
> contraint.
I would say I average about 6 projects per year. Most of the time I have 2
or 3 projects in progress at the same time and at various stages of
completion. As an independent consultant it's the only way I can make sure
I'll have any kind of "normal" cash flow and keep a roof over my head and
food on the table.
So far this year I've worked on 6 projects; (1) ARM7 project, (2) PIC
projects and (3) MSP430 projects. Most of my work is in high reliability
electronics: Fire Suppression systems, Medical Devices and Over-the-Road
Trucking equipment (ABS and tire monitoring systems). I also do quite a bit
of industrial control work as well, similar to you. Almost all the products
I design have pretty significant regulatory and reliability requirements.
Few of the projects are "quickies" and I would say the average project
lasts 6-9 months, mostly dependent on the regulatory requirements.
> One of the "very simple" field bus terminator was a side project for me
> last time but it took us more than one year to develop it due to lack of
> understanding of the standards. It was only using four resistors, a
> capacitor and a TVS. ;-)
>
> Now I am in a different job but the project cycle is still quite long
> since I am in the same industrial automation segment.
I've noticed that the larger the company, typically the longer the
development cycle is. I almost hate to say this but most larger companies
I've observed waste an incredible amount of time and resources with
politics and bureaucracy. A design that I can do in a couple weeks takes
them several months. Prototype boards that I can have built in two weeks,
they take two months to complete. Same boards, same components, same
specifications. Testing I can do in a few weeks takes them a few months.
Same test specifications.
Two of my biggest clients now are larger companies that use me
for their design work because I can get almost any project done faster and
cheaper than they can internally. The projects I do for them still have all
the same regulatory requirements and testing but I can normally deliver
working prototypes in about 1/3 the time their internal engineering can.
This kind of work is turning out to be a "sweet spot" for me, I work
relatively fast and even at my normal engineering rates am cheaper to them
by comparison. I can't compete with the sweatshops of India and China but I
don't try. There are things I do that they cannot seem to do, or at least
do well. But they do cheap very well... ;-)
Smaller companies usually don't have the engineering in-house and are
usually underfunded so they typically want the project done well and as
cheaply and quickly as possible. Most smaller companies that don't do much
product development work simply can't believe how much time and cost there
is to do the job right. There is almost always time and cost pressure with
these companies. Of course that's a generalization but has proven mostly
true over my 20+ years as a consultant.
In the past 12-18 months I've also started to pick up new work that were
failed projects with offshore engineering groups. I suspect that I'll see
more of this in the near future.
> I've noticed that the larger the company, typically the longer the
> development cycle is. I almost hate to say this but most larger companies
> I've observed waste an incredible amount of time and resources with
> politics and bureaucracy. A design that I can do in a couple weeks takes
> them several months. Prototype boards that I can have built in two weeks,
> they take two months to complete.
So True, Matt :)
I guess that's why small companies do still exist and prosper, in spite
of larger world-wide firms...
On 9/16/07, Matt Pobursky <.....piclistRemoveMEmps-design.com> wrote:
> I've noticed that the larger the company, typically the longer the
> development cycle is. I almost hate to say this but most larger companies
> I've observed waste an incredible amount of time and resources with
> politics and bureaucracy. A design that I can do in a couple weeks takes
> them several months. Prototype boards that I can have built in two weeks,
> they take two months to complete. Same boards, same components, same
> specifications. Testing I can do in a few weeks takes them a few months.
> Same test specifications.
> Two of my biggest clients now are larger companies that use me
> for their design work because I can get almost any project done faster and
> cheaper than they can internally. The projects I do for them still have all
> the same regulatory requirements and testing but I can normally deliver
> working prototypes in about 1/3 the time their internal engineering can.
> This kind of work is turning out to be a "sweet spot" for me, I work
> relatively fast and even at my normal engineering rates am cheaper to them
> by comparison. I can't compete with the sweatshops of India and China but I
> don't try. There are things I do that they cannot seem to do, or at least
> do well. But they do cheap very well... ;-)
Yes I know that there are a lot of independent consultant working in US
and quite successful. This may work for Europe as well. But not in
Asia where independent Engineering consultant are not popular and
not trusted by the average company.
And to the defence of the engineers working in a large company, we
are not idling. We are working hard as well. ;-)
And it is often necessary to have an engineer to support
the work of an outside consultant. The consultant can go disappear but
we still need to support the product. So there is a balance.
> Smaller companies usually don't have the engineering in-house and are
> usually underfunded so they typically want the project done well and as
> cheaply and quickly as possible. Most smaller companies that don't do much
> product development work simply can't believe how much time and cost there
> is to do the job right. There is almost always time and cost pressure with
> these companies. Of course that's a generalization but has proven mostly
> true over my 20+ years as a consultant.
Kind of true. I am moving from a medium size company to a relative
large company and I can see some differences, not big though.
> In the past 12-18 months I've also started to pick up new work that were
> failed projects with offshore engineering groups. I suspect that I'll see
> more of this in the near future.
That is true. From my limited working experience, I can see that for
Germany companies, it seems to me they keep their core competency in
Germany
quite well. Too well for the people working in their oversea subsidiaries to
feel not worth working for them in Engineering. US companies are better to
transfer some technology to their oversea subsidiary. But the core
competency is still in the corporate headquarter. Offshore engineering
groups often do not get the same support (from inside the company or
from the outside vendors) as their counterpart in US/Europe. So I will
say there are still plenty of engineering opportunities in US/Europe.
ARRL.NET
