On Sat, 20 Mar 2010 16:37:08 -0000, Eng wrote:
> --- In l..., "rtstofer" wrote:
>
>> They buy some chips, build some boards and send them down the pipeline.
> Yes, and we suppose they received all micros at the same rev. level. So,
> they could mark their boards with a unique rev. ID.
>
>> They buy some more chips, build some more boards and send them along as
>> well.
> Ok, if they just changed the boards rev. ID, all customers could know
> that.
Board revision is not chip revision. In all my years of purchasing Olimex
boards, I've only ever had one board-level issue. I take what I'm
given,
and I buy extra boards when chip revisions change. Note that I said I
purchase these boards; Olimex does not donate them to me.
>> Let the chip mature in the marketplace by a year or
so. Let other
>> developers discover the glitches.
> Let's do a brief calculus: from 2007 (B rev. from NXP) to 2009 (Olimex
> boards sold to us), that is... 2 years !
> Is it enough time to receive B rev. micros ?
You seem to think that this is an Olimex problem. It's not. You said you
ordered from a distributor, so how long do you think the distributor had
it on his shelves? Do distributors segregate boards into delivery dates?
They have an infinite shelf life, unlike milk, and if they don't operate a
FIFO system then you get what they have in stock. I assume they didn't
drop-ship, it would be too expensive.
>> If it weren't for Olimex boards, I
wouldn't be able to play with any of
>> this technology.
> We were used to buy from many other vendors. Never found these problems:
> we need clear documentation and transparency.
> As we do for our customers; they too expect from us repeatable products,
> not a mixture of features.
This is simple: specify the chip revision when you buy chips. I don't
think you'll have much luck specifying the chip revision of every chip of
an eval board, though.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
Bad support from Olimex: LPC-2378STK with various rev. micros
Started by ●March 20, 2010
Reply by ●March 20, 20102010-03-20
Reply by ●March 20, 20102010-03-20
--- In l..., "Paul Curtis" wrote:
>
> On Sat, 20 Mar 2010 16:37:08 -0000, Eng wrote:
>
> > --- In l..., "rtstofer" wrote:
> >
> >> They buy some chips, build some boards and send them down the pipeline.
> > Yes, and we suppose they received all micros at the same rev. level. So,
> > they could mark their boards with a unique rev. ID.
> >
> >> They buy some more chips, build some more boards and send them along as
> >> well.
> > Ok, if they just changed the boards rev. ID, all customers could know
> > that.
>
> Board revision is not chip revision. In all my years of purchasing Olimex
> boards, I've only ever had one board-level issue. I take what I'm given,
> and I buy extra boards when chip revisions change. Note that I said I
> purchase these boards; Olimex does not donate them to me.
>
> >> Let the chip mature in the marketplace by a year or so. Let other
> >> developers discover the glitches.
> > Let's do a brief calculus: from 2007 (B rev. from NXP) to 2009 (Olimex
> > boards sold to us), that is... 2 years !
> > Is it enough time to receive B rev. micros ?
>
> You seem to think that this is an Olimex problem. It's not. You said you
> ordered from a distributor, so how long do you think the distributor had
> it on his shelves? Do distributors segregate boards into delivery dates?
> They have an infinite shelf life, unlike milk, and if they don't operate a
> FIFO system then you get what they have in stock. I assume they didn't
> drop-ship, it would be too expensive.
>
> >> If it weren't for Olimex boards, I wouldn't be able to play with any of
> >> this technology.
> > We were used to buy from many other vendors. Never found these problems:
> > we need clear documentation and transparency.
> > As we do for our customers; they too expect from us repeatable products,
> > not a mixture of features.
>
> This is simple: specify the chip revision when you buy chips. I don't
> think you'll have much luck specifying the chip revision of every chip of
> an eval board, though.
>
> --
I have replaced the chip to a newer version on an older demo board before. That is another option too sometimes.
boB
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
>
>
> On Sat, 20 Mar 2010 16:37:08 -0000, Eng wrote:
>
> > --- In l..., "rtstofer" wrote:
> >
> >> They buy some chips, build some boards and send them down the pipeline.
> > Yes, and we suppose they received all micros at the same rev. level. So,
> > they could mark their boards with a unique rev. ID.
> >
> >> They buy some more chips, build some more boards and send them along as
> >> well.
> > Ok, if they just changed the boards rev. ID, all customers could know
> > that.
>
> Board revision is not chip revision. In all my years of purchasing Olimex
> boards, I've only ever had one board-level issue. I take what I'm given,
> and I buy extra boards when chip revisions change. Note that I said I
> purchase these boards; Olimex does not donate them to me.
>
> >> Let the chip mature in the marketplace by a year or so. Let other
> >> developers discover the glitches.
> > Let's do a brief calculus: from 2007 (B rev. from NXP) to 2009 (Olimex
> > boards sold to us), that is... 2 years !
> > Is it enough time to receive B rev. micros ?
>
> You seem to think that this is an Olimex problem. It's not. You said you
> ordered from a distributor, so how long do you think the distributor had
> it on his shelves? Do distributors segregate boards into delivery dates?
> They have an infinite shelf life, unlike milk, and if they don't operate a
> FIFO system then you get what they have in stock. I assume they didn't
> drop-ship, it would be too expensive.
>
> >> If it weren't for Olimex boards, I wouldn't be able to play with any of
> >> this technology.
> > We were used to buy from many other vendors. Never found these problems:
> > we need clear documentation and transparency.
> > As we do for our customers; they too expect from us repeatable products,
> > not a mixture of features.
>
> This is simple: specify the chip revision when you buy chips. I don't
> think you'll have much luck specifying the chip revision of every chip of
> an eval board, though.
>
> --
I have replaced the chip to a newer version on an older demo board before. That is another option too sometimes.
boB
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
>
Reply by ●March 20, 20102010-03-20
--- In l..., "Eng" wrote:
>
> > ALWAYS CHECK THE SILICON REVISION OF YOUR BOARDS; NEVER ASSUME THE BOARD
> > YOU ORDER WILL HAVE THE LATEST REVISION OF SILICON.
> I just asked Farnell about Olimex rev. boards. They can't guarantee anything about revision of micros. It's always a surprise !
>
If you have to buy Olimex boards maybe it would be better to buy direct from Olimex? From what you say it appear that they don't accept returns from resellers so there is less likelihood they will still have old stock themselves.
Otherwise, I'd recommend dealing with Embedded Artists. They say the following about chip revisions on their boards:
"We do not sell a specific chip revision. Normally it is the latest, but when new revisions are released by NXP there can be a transition period."
http://www.embeddedartists.com/support/faq.php?action=showfaq&faqid=9
One revision level out of date sounds reasonable to me. Again I would think that buying direct from them would be safer unless you are dealing with a reseller that has a quick turnaround - monitoring their stock levels could be an indicator of that.
>
> > I assume you
> > did specify the revision of the chip to use in your order?
> No we didn't, that's our fault.
>
Certainly you should do so in future where it matters to you. At least then you would be justified in expecting a refund / replacement if they delivered a defective older revision.
--
Chris Burrows
CFB Software
Armaide: ARM Development System for Pascal programmers.
http://www.armaide.com
>
> > ALWAYS CHECK THE SILICON REVISION OF YOUR BOARDS; NEVER ASSUME THE BOARD
> > YOU ORDER WILL HAVE THE LATEST REVISION OF SILICON.
> I just asked Farnell about Olimex rev. boards. They can't guarantee anything about revision of micros. It's always a surprise !
>
If you have to buy Olimex boards maybe it would be better to buy direct from Olimex? From what you say it appear that they don't accept returns from resellers so there is less likelihood they will still have old stock themselves.
Otherwise, I'd recommend dealing with Embedded Artists. They say the following about chip revisions on their boards:
"We do not sell a specific chip revision. Normally it is the latest, but when new revisions are released by NXP there can be a transition period."
http://www.embeddedartists.com/support/faq.php?action=showfaq&faqid=9
One revision level out of date sounds reasonable to me. Again I would think that buying direct from them would be safer unless you are dealing with a reseller that has a quick turnaround - monitoring their stock levels could be an indicator of that.
>
> > I assume you
> > did specify the revision of the chip to use in your order?
> No we didn't, that's our fault.
>
Certainly you should do so in future where it matters to you. At least then you would be justified in expecting a refund / replacement if they delivered a defective older revision.
--
Chris Burrows
CFB Software
Armaide: ARM Development System for Pascal programmers.
http://www.armaide.com
Reply by ●March 20, 20102010-03-20
> I have replaced the chip to a newer version on an
older demo board before. That is another option too sometimes.
>
> boB
What a terrific justification for replacing the chip I just fried!
Hm...
Richard
>
> boB
What a terrific justification for replacing the chip I just fried!
Hm...
Richard
Reply by ●March 21, 20102010-03-21
Facing the same issue of varying rev level CPUs on same board types, I just
coded to accommodate the oldest rev CPU. For the '2106, this meant
don't use edge triggered EINTs - in my project.
The alternative was to get the funds to order enough from Olimex to inspire them to to a new inventory build. That might be a few hundred. But the '2106 is, as they say, a bit long in the tooth now, with the Cortex in favor.
The alternative was to get the funds to order enough from Olimex to inspire them to to a new inventory build. That might be a few hundred. But the '2106 is, as they say, a bit long in the tooth now, with the Cortex in favor.
Reply by ●March 21, 20102010-03-21
engsistemi schrieb:
>
>
> We are a team of designers [snip]
>
Really? Then stop whining and do your job (like reading errata sheets,
takeing care of chip revisions and write code that works on all chip
versions you intend to support).
Besides, what's the deal with ordering yet another board for your
project to replace the "-" version? The costs of one of those boards
compared to your developement efforts truly should be neglectable.
Sorry, just my 2
Markus
>
>
> We are a team of designers [snip]
>
Really? Then stop whining and do your job (like reading errata sheets,
takeing care of chip revisions and write code that works on all chip
versions you intend to support).
Besides, what's the deal with ordering yet another board for your
project to replace the "-" version? The costs of one of those boards
compared to your developement efforts truly should be neglectable.
Sorry, just my 2
Markus
Reply by ●March 21, 20102010-03-21
On 21/03/2010 15:05, Markus Zingg wrote:
> engsistemi schrieb:
>> We are a team of designers [snip]
>>
> Really? Then stop whining and do your job (like reading errata sheets,
> takeing care of chip revisions and write code that works on all chip
> versions you intend to support).
>
> Besides, what's the deal with ordering yet another board for your
> project to replace the "-" version? The costs of one of those boards
> compared to your developement efforts truly should be neglectable.
>
> Sorry, just my 2
Or, buy one of the newer chips and replace the one on the board. It only
takes a few minutes.
Leon
--
Leon Heller
G1HSM
> engsistemi schrieb:
>> We are a team of designers [snip]
>>
> Really? Then stop whining and do your job (like reading errata sheets,
> takeing care of chip revisions and write code that works on all chip
> versions you intend to support).
>
> Besides, what's the deal with ordering yet another board for your
> project to replace the "-" version? The costs of one of those boards
> compared to your developement efforts truly should be neglectable.
>
> Sorry, just my 2
Or, buy one of the newer chips and replace the one on the board. It only
takes a few minutes.
Leon
--
Leon Heller
G1HSM
Reply by ●March 21, 20102010-03-21
Il comportamento di Olimex e/o del distributore italiano non sono da
condannare, ne pensabile che la revisione di una scheda debba seguire
le revisioni dei singoli componenti, quanto meno una scelta interna
del produttore non legata ad uno standard specifico. Personalmente
ritengo che abbiate dimostrato una certa inesperienza ed anche una certa
mancanza di elasticit per un problema di una fornitura di entitbr /> davvero minima (2 schede) visto che il modo pirapido di uscirne (e
tutto sommato anche economico) di ordinarne una terza con il
microcontrollore della giusta revisione e nel caso di ulteriori
forniture specificare oltre alla revisione della scheda anche quella del
microcontrollore dimostrando di saper imparare dai propri errori.
Se vi puconsolare chi nel settore da una decina d'anni e magari come
me ha anche avuto l'opportunitdi lavorare facendosi fare pidi un
microcontrollore "su misura", potrebbe elencarvi decine di casi di
microcontrollori o anche di altri tipi di componenti di una certa
complessitche hanno subito revisioni in seguito ad errori da parte del
produttore almeno dai tempi dei Motorola 68HC11K4, 68331, 68340 cosbr /> come pirecentemente di alcuni modelli di Z8Encore; ma in generale
tutti i maggiori produttori hanno avuto problemi simili o anche
peggiori. Riguardo al caso specifico innegabile che il 2378 sia stato
minato da release iniziali non proprio fortunate, coscom'altrettanto
chiaro che un produttore di evaluation boards possa approvvigionarsi da
pidi un fornitore a meno di essere un cliente preferenziale di NXP e
questo giustifica il fatto che possa montare nello stesso periodo schede
con microcontrollori di di revisioni diverse. Tuttavia a differenza di
molti altri produttori Philips prima, NXP poi, dimostra una certa
rapidited una onestdi base nella pubblicazione degli errata non
nascondendo i difetti dei propri componenti (cosa che non tutti fanno) e
mettendovi rimedio in tempi ragionevoli.
Il 20/03/2010 17.37, Eng ha scritto:
>
>
> --- In l... ,
> "rtstofer" wrote:
> >
> > I guess I missed something!
> May be...
>
> > They buy some chips, build some boards and send them down the pipeline.
> Yes, and we suppose they received all micros at the same rev. level.
> So, they could mark their boards with a unique rev. ID.
>
> > They buy some more chips, build some more boards and send them along
> as well.
> Ok, if they just changed the boards rev. ID, all customers could know
> that.
>
> >Let the chip mature in the marketplace by a year or so. Let other
> developers discover the glitches.
> Let's do a brief calculus: from 2007 (B rev. from NXP) to 2009 (Olimex
> boards sold to us), that is... 2 years !
> Is it enough time to receive B rev. micros ?
>
> > If it weren't for Olimex boards, I wouldn't be able to play with any
> of this technology.
> We were used to buy from many other vendors. Never found these
> problems: we need clear documentation and transparency.
> As we do for our customers; they too expect from us repeatable
> products, not a mixture of features.
>
> engsistemi
condannare, ne pensabile che la revisione di una scheda debba seguire
le revisioni dei singoli componenti, quanto meno una scelta interna
del produttore non legata ad uno standard specifico. Personalmente
ritengo che abbiate dimostrato una certa inesperienza ed anche una certa
mancanza di elasticit per un problema di una fornitura di entitbr /> davvero minima (2 schede) visto che il modo pirapido di uscirne (e
tutto sommato anche economico) di ordinarne una terza con il
microcontrollore della giusta revisione e nel caso di ulteriori
forniture specificare oltre alla revisione della scheda anche quella del
microcontrollore dimostrando di saper imparare dai propri errori.
Se vi puconsolare chi nel settore da una decina d'anni e magari come
me ha anche avuto l'opportunitdi lavorare facendosi fare pidi un
microcontrollore "su misura", potrebbe elencarvi decine di casi di
microcontrollori o anche di altri tipi di componenti di una certa
complessitche hanno subito revisioni in seguito ad errori da parte del
produttore almeno dai tempi dei Motorola 68HC11K4, 68331, 68340 cosbr /> come pirecentemente di alcuni modelli di Z8Encore; ma in generale
tutti i maggiori produttori hanno avuto problemi simili o anche
peggiori. Riguardo al caso specifico innegabile che il 2378 sia stato
minato da release iniziali non proprio fortunate, coscom'altrettanto
chiaro che un produttore di evaluation boards possa approvvigionarsi da
pidi un fornitore a meno di essere un cliente preferenziale di NXP e
questo giustifica il fatto che possa montare nello stesso periodo schede
con microcontrollori di di revisioni diverse. Tuttavia a differenza di
molti altri produttori Philips prima, NXP poi, dimostra una certa
rapidited una onestdi base nella pubblicazione degli errata non
nascondendo i difetti dei propri componenti (cosa che non tutti fanno) e
mettendovi rimedio in tempi ragionevoli.
Il 20/03/2010 17.37, Eng ha scritto:
>
>
> --- In l... ,
> "rtstofer" wrote:
> >
> > I guess I missed something!
> May be...
>
> > They buy some chips, build some boards and send them down the pipeline.
> Yes, and we suppose they received all micros at the same rev. level.
> So, they could mark their boards with a unique rev. ID.
>
> > They buy some more chips, build some more boards and send them along
> as well.
> Ok, if they just changed the boards rev. ID, all customers could know
> that.
>
> >Let the chip mature in the marketplace by a year or so. Let other
> developers discover the glitches.
> Let's do a brief calculus: from 2007 (B rev. from NXP) to 2009 (Olimex
> boards sold to us), that is... 2 years !
> Is it enough time to receive B rev. micros ?
>
> > If it weren't for Olimex boards, I wouldn't be able to play with any
> of this technology.
> We were used to buy from many other vendors. Never found these
> problems: we need clear documentation and transparency.
> As we do for our customers; they too expect from us repeatable
> products, not a mixture of features.
>
> engsistemi
