vedo che i pic sono pieni di bug... succede così anche per altri micro di altre case?
-ice-
vedo che i pic sono pieni di bug... succede così anche per altri micro di altre case?
-ice-
Chiedilo a Marco Trapanese.... :)
Cmq si, ogni tanto ci possono essere problemi.
saluti coals
ice ha scritto:
No capisco che vuoi dire... Ti riferisci alle revisioni dei chip per caso?
Ciao!
-- Stefano Martini (Italy) Sito web: http://www.lemming.it Memento Audere Semper (G. d'Annunzio)
Il 09 Ott 2008, 09:58, "ice" ha scritto:
Può capitare, anche nelle migliori famiglie. :) La Atmel ha aggiustato un problemino di endianess della porta SPI sull'allora ARM di punta, AT91RM200, o qualcosa del genere. Prima di sistemare il silicio nelle revisioni successive, ha fornito il workaround, e cioè una serie di routine che si occupavano di reversare l'endianess dal registro, prima di spingere fuori il trenino di bit. :-)
Saluti.
-------------------------------- Inviato via
intendo dire che non ho ancora visto un dspic o altro pic recente che non abbia un errata dove spiegano tutti i comportamenti NON-voluti che si presentano dopo che il chip è già in produzione
il fatto è che devi capire bene ogni volta che problema ha il micro che scegli e poi verificare se il complilatore che usi tiene conto del bug... altrimenti devi intervenire a mano... sempre se è possibile
è simpatico quando si legge che il problema X interessa il registro Y quando viene caricato con il dato Z... workaround: non usare il registro Y oppure non caricarlo con il dato Z :) (grazie, fin lì ci arrivavo anche io)-ice-
coals ha scritto:
Sgrunt :)
Marco / iw2nzm
ice ha scritto:
o di=20
purtroppo si, i ragazzi del silicio combinano vaccate come tutti noi; alcune restano latenti anche per decenni, fino a quando un povero cristo ci incappa.
saluti
ma se una ditta produce una scheda con un certo micro e questo micro si scopre che ha un bug dopo molto tempo, chi ne risponde al cliente? la casa produttrice del micro, la ditta o nessuno?
-ice-
Dovrebbe essere che il cliente si rifà su di te che hai scelto i componenti e tu ti rifai sulla casa produttrice. Fatto sta che son cose sempre molto complicate. Ma per fortuna stiamo in Italia, quindi il problema non si pone, al cliente verrà dato un buono (
coals
noi ultimamente siamo particolarmente bravi a scegliere micro con bug latenti e poi inventarci i workaround perché la casa madre non li ha ancora trovati :-(
Ste
-- Ogni problema complicato ha una soluzione semplice...per lo piu` sbagliata [cit. Franco, i.h.e. 20.01.2007]
dipende...chi ha gli avvocati più bravi ne esce pulito
Ste
-- Ogni problema complicato ha una soluzione semplice...per lo piu` sbagliata [cit. Franco, i.h.e. 20.01.2007]
ice ha scritto:
se il business e' grande, risponde il produttore (che vorrebbe mettere tutto a tacere); se il business e' piccolo, ti attacchi.
saluti bacati
ciao PeSte, è un po' che non ti vedevo da queste parti (il motivo penso di saperlo cmq era solo x dire che mi fa piacere rileggerti!!!)
leggendo gli errata microchip mi viene da pensare che il progetto per realizzare un micro si faccia in "fretta e furia" per uscire presto sul mercato e gli utilizzatori finali diventano poi i beta-tester... non dico che possa esistere un micro bug-free ma qui prendiamo la piega microsoft :)
-ice-
ice ha scritto:
Ciao! Sì, come ti hanno spiegato gli altri, a volte chi produce i chip, non si accorge di alcuni bug (features? :-D Come dice il buon F. Bertolazzi), e quindi fa una revisione del die per correggerli. Purtroppo è una cosa che fanno tutti i produttori, non solo Microchip o Atmel, ed anche per chip meno complessi dei microcontroller.
Ciao!
-- Stefano Martini (Italy) Sito web: http://www.lemming.it
di
Eccome! Nei manuali, poi, trovi errori di cui ti accorgi solo per aver lavorato sul micro. Errori pesanti tipo cambio di posizione di bit in un registro di controllo. Trovai anche in AVRstudio un baco mostruoso relativo alle direttive .org: se erano spazialmente contenute in una pagina di 16 byte, non mi assemblava del codice! O una cosa similie... Persi due giorni per capirlo.
Negli AVR AT90S2313, ad esempio, era indicata la possibilit=E0 di programmarli in bassa tensione (3 volt). Io non ci riuscii. Se ne accorsero anche loro.
Gli errori di stampa nei datasheet sono poco inferiori come gravit=E0 a quelli hardware in un primo momento.
Piccio.
ice wrote: [...]
grazie
già :-(
rispetto a microsoft è più facile però cambiara part number se ci sono problemi :-)
Ste
-- Ogni problema complicato ha una soluzione semplice...per lo piu` sbagliata [cit. Franco, i.h.e. 20.01.2007]
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.