Hallo! Hat hier sonst noch wer so schlechte Erfahrungen mit der Qualität der dsPIC33-Serie? Ich hab in den 80ern angefangen mit uCs zu arbeiten (Motorola, PIC16) und war es gewohnt, dass man die Fehler im Datenblatt an einer Hand abzählen konnte und der Chip das tat, was im Datenblatt stand. 2009 hab ich dann angefangen mit der PIC33 Familie zu arbeiten und hab seither duzende Fehler in der Hardware gefunden, die alle nicht in den Errata-Sheets dokumentiert waren. Meine jeweiligen Versuche, irgendeine intelligente Antwort dazu von Microchip zu bekommen sind jeweils am First-Level-Support gescheitert, der meist nicht mal das Problem verstand. Kleines Beispiel: Wenn man die UART im dsPIC33FJ*MC auf maximalem Speed fährt, also BRG=0 und Bit BRGH gesetzt, dann reicht eine Abweichung der Baudrate um einige wenige ppm aus, dass der Empfang nicht mehr sauber funktioniert weil das Stopbit nicht mehr sauber erkannt wird. Hab ich ausgetestet mit gleichem, externen Takt an 2 PICs und hab dann die PLL's ganz leicht verstellt. Microchip First-Level-Support: Hat 2 PICs zusammengehängt, beide mit internem RC-Oszillator (!) und hat gemeint, dass es ja eh geht. Ja eh - zufällig. Ich hab's dann aufgegeben, wollt' nicht unhöflich werden. Grüsse, Gernot
Lieber Herr Schreiner, ich würde Ihnen als mein ehemaliger N5c/1985-Schüler ja sehr gerne einige Nachhilfe-Tipps dazu geben, aber ich bin heute (!) 69 Jahre alt und empfinde mich nicht mehr total am neuesten Stand der µC-Technik, schon gar nicht der PIC-Technik, weil ich ja schon immer der Meinung bin, dass ein PIC gar kein µC ist ...... Das soll aber nicht heißen, dass ich mit der Technik nicht mehr verbunden bin, denn ich habe seit 1. Februar 2017 ein EU-Patent über neue dehnungsmessstreifenlose (!!!!!!!) Verfahren zur Messung von Kräften, Drehmomenten, Positionen, Drücken usw., und weil's irgendwie dazu gehört auch ein Ö. Patent für die elektronischen Schaltungen dazu. Ein zweites EU-Patentverfahren ist noch im Laufen. Zu der ganzen Sache schreibe ich derzeit ein Buch, aber ich bin im Konzept erst auf (A4-)Seite 517 ...... Dass in die neuartigen Sensoren irgendwelche µC-Flöhe hinein gehören, ist klar, und von Microchip gibt es ja einen ganz winzigen, wie ich weiß. In allernächster Zeit zwar nicht, aber gleich danach (....) werde ich Sie mal auf ein Bier einladen! Noch viel Spaß beim Fehlersuchen! Franz Braunschmid
Franz Braunschmid schrieb: > denn ich habe seit 1. Februar 2017 ein EU-Patent Hat das in diesem Kontext auch nur irgendeine Relevanz? Wenn ja: Hilft mir einer, sie zu erkennen?
Rufus Τ. F. schrieb: > Franz Braunschmid schrieb: >> denn ich habe seit 1. Februar 2017 ein EU-Patent > > Hat das in diesem Kontext auch nur irgendeine Relevanz? > > Wenn ja: Hilft mir einer, sie zu erkennen? Langsam und sorgfältig durchlesen, dann kommt der Kern des Beitrags zum Vorschein. Das Aha-Erlebnis ist ziemlich witzig.
Gernot S. schrieb: > Ich hab in den 80ern angefangen mit uCs zu arbeiten > (Motorola, PIC16) und war es gewohnt, dass man die Fehler im Datenblatt > an einer Hand abzählen konnte und der Chip das tat, was im Datenblatt > stand. Diese Zeiten sind aber eben vorbei. Heutzutage ist -- ganz offensichtlich -- Funktionsvielfalt (und damit Komplexität) wichtiger als die Zuverlässigkeit. Es ist auch einfach unmöglich von solche komplexen Controllern alles zu testen und vor allem alle Fehler zu beheben. Das will heutzutage niemand mehr bezahlen. Selbst wenn Microchip so einen Fehler beheben würde, dann würde das vermutlich kaum jemandem auffallen, geschweige denn würden sie die Kosten dafür je wieder reinholen. Wenn du ein Automotive Zulieferer bist der 500k Stück abnimmt ist das sicher was anderes. Aber irgendwelche kleinen Klitschen oder gar Privatanwender interessiert Microchip nicht das kleinste Stück. Die bringen ja auch keinen Cent. Wir als Hobbyisten oder kleine Firmen haben das Glück, dass die Großen gibt -- die bezahlen für uns die Entwicklung der Controller. Und wir haben dann das Glück, dass wir die zu Schleuderpreisen bekommen. Wenn jeder Hobbybastler bereit wäre 25€ für einen PIC18F auszugeben dann wäre das sicher was anderes. Aber so ... Gernot S. schrieb: > Kleines Beispiel: Wenn man die UART im dsPIC33FJ*MC auf maximalem Speed > fährt, also BRG=0 und Bit BRGH gesetzt, dann reicht eine Abweichung der > Baudrate um einige wenige ppm aus, dass der Empfang nicht mehr sauber > funktioniert weil das Stopbit nicht mehr sauber erkannt wird. Hab ich > ausgetestet mit gleichem, externen Takt an 2 PICs und hab dann die PLL's > ganz leicht verstellt. Genau das ist ja irgendwie die Sache. Niemand aus einer professionellen Liga käme je auf die Idee sowas zu machen. Es ist doch irgendwie logisch, dass der Betrieb am Limit eher instabil ist. Um konkurrenzfähig zu bleiben versucht natürlich jeder Hersteller seinen Controller als den tollsten anzubieten. Je mehr im Datenblatt steht desto wahrscheinlicher wird er genommen. Inwiefern dieses Verhalten der Hersteller vertretbar oder gut ist, das ist auf einem anderen Blatt geschrieben. Es gehört einfach auch zu den Aufgaben eines Ingenieurs eben das zu erkennen und bewerten zu können. Wenn du ein Übertragungsverfahren *am Limit des Datenblattes* fährst, dann hast du etwas falsch gemacht. Und zwar in deiner Systemarchitektur / Systemplanung. Gernot S. schrieb: > Microchip First-Level-Support: Hat 2 PICs > zusammengehängt, beide mit internem RC-Oszillator (!) und hat gemeint, > dass es ja eh geht. Ja eh - zufällig. Ich hab's dann aufgegeben, wollt' > nicht unhöflich werden. Du erwartest jetzt also, dass sich jemand ernsthaft kostenlos mit deinem Problem auseinander setzt? Am besten noch einer ein Silicon Designer oder Testingenieur? Weil du einmal 5 Stück gekauft hast? Das ist sicherlich möglich, wenn du genügend Geld bezahlst oder genügend Stückzahl abnimmst. Genau das Problem das du beschreibst ist die Aufgabe eines Elektrotechnikers heutzutage. Sich in dem Bereich auszukennen und unterscheiden zu können was drin ist und was ein haltloses Werbeversprechen ist.
GHD schrieb: > Gernot S. schrieb: >> Kleines Beispiel: Wenn man die UART im dsPIC33FJ*MC auf maximalem Speed >> fährt, also BRG=0 und Bit BRGH gesetzt, dann reicht eine Abweichung der >> Baudrate um einige wenige ppm aus, dass der Empfang nicht mehr sauber >> funktioniert weil das Stopbit nicht mehr sauber erkannt wird. Hab ich >> ausgetestet mit gleichem, externen Takt an 2 PICs und hab dann die PLL's >> ganz leicht verstellt. > > Genau das ist ja irgendwie die Sache. Niemand aus einer professionellen > Liga käme je auf die Idee sowas zu machen. Es ist doch irgendwie > logisch, dass der Betrieb am Limit eher instabil ist. Kann es sein, daß du die Problembeschreibung nicht verstanden hast? Ein UART sollte einige Toleranz bei der Baudrate haben, denn das A steht ja gerade für asynchronous. Gängiger Daumenwert sind 1% Abweichung. Der TE spricht aber von wenigen ppm. Sagen wir 10ppm, dann ist das im Vergleich zu 1% um Faktor 1000 sensitiver. Ich weiß jetzt nicht, was im Datenblatt steht. Vermutlich spezifiziert MC die erlaubte Baudratentoleranz im angesprochenen Higspeed-Modus des UART einfach nicht. Damit sind sie natürlich fein raus.
GHD schrieb: > Es ist auch einfach unmöglich von solche > komplexen Controllern alles zu testen und vor allem alle Fehler zu > beheben. Deswegen muss man auch akzeptieren,dass hin und wieder mal ein Patient auf dem OP-Tisch stirbt,weil ein uC gerademal nicht so will,wie es im Datenblatt beschrieben ist. Auch Flugzeuge,duerfen auf Grund undurchfuehrbarer Kontrollen gerne mal vom Himmel fallen .. is halt mal so.?
Toxic schrieb: > in und wieder mal ein Patient > auf dem OP-Tisch stirbt,weil ein uC gerademal nicht so will,wie es im > Datenblatt beschrieben ist. > Auch Flugzeuge,duerfen auf Grund undurchfuehrbarer Kontrollen gerne mal > vom Himmel fallen Und weil ausgiebige Tests der Flugzeugtechnik oder der medizinischen Geräte heute als uncool gelten
Das Poblem ist (leider) sehr vielschichtig und einige Aspekte wurden hier schon genannt. Man (die Chiphersteller) müssen sich am Markt behaupten und ständig neue, billigere, bessere Derivate liefern. Ich gehe schon davon aus, dass das Design auch getestet wird aber eben nicht bis ins letzte Bit. Es dauert ca. 1-2 Jahre bis das Chip-Design steht und in Produktion geht. Es kann sich niemand leisten einen Chip zu entwickeln, diesen dann 10 Jahre lang auf Herz und Nieren zu prüfen und erst dann in den Markt zu bringen. In dieser Zeit sind die Mitbewerber meilenweit voraus, die eingesetzte Technologie ist veraltet und keiner will das Ding mehr haben. Fehler werden nur dann korrigiert, wenn sich viele (zahlende) Anwender beschwerern und ein Verlust von Markanteilen droht. Dann versucht man typischerweise das Problem in Software oder durch "anpassen" der Spec in den Griff zu bekommen. Erst wenn das nicht mehr hilft wird eine neue Revision des Chips auf den Markt gebracht. Ich arbeite in der Automobilindustrie und wir setzen eigene ASICs ein. Der erste Schuss passt nie, es gibt immer irgendwelche Bugs. Trotzem wird immer abgewogen ob es ein solch gravierender Bug ist, dass es eine neue Chip-Revision geben muß. Oft reicht es auch aus die Spec anzupassen und der Bug ist wegdefiniert ;-) (Bsp. Wenn im Datenblatt 5V Betriebsspannung steht, aber die spezifizierte maximale Stromaufnahme nicht passt, geht man eben auf 4.5V oder 3.3V runter. Oder wenn das Dinges bei 100 MHz anfängt unstabil zu laufen weil man einen Bug in den Clock-Tree eingebaut hat, spezifiziert man einfach auf 80MHz um und gut is.) Du als Privatmann (Kleinstmengenabnehmer) hast keine Chance da was zu reißen. Klar du kannst auf das Problem aufmerksam machen und hoffen dass viele tausend Anwender dieses Problem auch haben. Dann besteht Hoffnung auf einen Fix. Wenn du 100k pro Jahr abnehmen würdest, sehe die Sache vlt. auch schon etwas anders aus. Dann hättest du eine gewisse Chance das dein Problem ernst genommen würde bzw. dass du dich nicht nur mit der netten Dame am Telefonsupport unterhalten darfst. Früher gab es einige wenige Controller auf dem Markt. Heute hast du pro Familie zig Ableger. Die alle zu testen ist nicht möglich. Man baut die Maximalversion, testet die wichtigsten Eigenschaften/Anwendungsfälle und wirft dann Module raus im kleinere Derivate zu bauen. Die werden natürlich dann nicht mehr komplett getestet (man hat ja nur Teile entfernt). Das ist ein Problem, denn auch beim Entfernen können Fehler gemacht werden. Das Problem ist halt, dass die Dinger immer komplexer und flexibler werden und man unmöglich alles abtesten kann (U.a. auch weil man gar nicht an einen Anwendungsfall gedacht hat.) Schau dich mal im Netz um wieviele Lösungen es gibt um das WS2812 Protokoll nachzubauen. DMA, SPI, UART waren dazu nie gedacht, werden aber verwendet weil es eben (meistens) geht. Erratas werden nur geschrieben wenn wirklich viele Anwender betroffen sind. Schließlich muss man eingestehen dass ein Produkt fehlerhaft ist bzw. man den (Entwickllungs-)Prozess nicht im Griff hat. Das ist ein allgemeines Thema. Jeder Chiphersteller baut Bugs ein und versucht sie so lange wie möglich zu verschweigen. Das ist leider menschlich oder gibst du gerne zu, dass du Fehler gemacht hast ?
Mich würde interessieren, wie der To aus demselben Takt die pll um ein paar ppm verstellen konnte. So wie ich die pll von microchip kenne geht dies absolut nicht.
Bastler schrieb: > Erratas werden nur geschrieben wenn wirklich viele Anwender betroffen > sind. Ich kann nur hoffen, daß das die Hersteller nicht so sehen. > Schließlich muss man eingestehen dass ein Produkt fehlerhaft ist bzw. > man den (Entwickllungs-)Prozess nicht im Griff hat. Ja. Und? Jeder macht Fehler. Die Frage ist, wie man damit umgeht. Wer seine Fehler nicht zugibt, der kann auch nicht aus ihnen lernen. > Das ist ein allgemeines Thema. Jeder Chiphersteller baut Bugs ein und > versucht sie so lange wie möglich zu verschweigen. Das ist leider > menschlich oder gibst du gerne zu, dass du Fehler gemacht hast ? Das hat gar nichts damit zu tun, ob man das gern macht oder nicht. Jeder bekannte, aber verschwiegene Fehler kann zu verlorener Arbeitszeit beim Kunden führen. Und in der Folge zum Verlust eines Auftrags. Das kann der Hersteller vorher nicht wissen. Deswegen ist es auch in seinem Interesse, die Macken seiner Produkte umfassend zu dokumentieren. Nach Möglichkeit, bevor ein Kunde darauf stößt. Wenn es richtig krass wird, können sogar Folgekosten entstehen, die in keinem Verhältnis zum Egoverlust stehen. Wenn z.B. irgendwo eine Industrieanlage hochgeht. Man denke nur zurück an den FDIV Bug.
Ich hab mir mal vor 35Jahren eine Nacht mit einer Z80-SIO um die Ohren geschlagen, die einen Vorteiler hatte, mit der die Baudrate multipliziert wurde, um den eigentlichen Takt zu ermitteln. Also z.B. 9600Hz Takt und Teiler 4 macht 1200B/s. Um das einfach zu halten, stellte ich den Vorteiler auf 1. Was im Handbuch nicht explizit stand: der Vorteiler bestimmte auch wie oft das Signal abgetasten werden soll. Tags darauf mit 16fach-Abtastung ging dann alles. So ähnlich könnte der "Pic33-Bug" auch entstanden sein.
Axel S. schrieb: > Wenn es richtig krass wird, können sogar Folgekosten entstehen, die in > keinem Verhältnis zum Egoverlust stehen. Wenn z.B. irgendwo eine > Industrieanlage hochgeht. Man denke nur zurück an den FDIV Bug. Welche Industrieanlage ist deswegen hochgegangen? Allerdings betrachtete Intel bis zu diesem Zeitpunkt Errata als Betriebgeheimnis, nur gegen NDA zu erfahren. Danach wurden sie öffentlich. Dafür werden sie aber gelegentlich so formuliert, dass man erst hinterher merkt, dass man es eigentlich hätte vorher merken können. AMD hatte beim K6 einen Bug, gross wie ein Scheunentor, der ziemlich sicher alle betraf, die ihn mit genug Speicher verwendeten. Nur nicht bei jedem häufig genug, um den Zusammenhang zu erkennen. Der stand sogar sehr früh im Errata Sheet, war aber anfangs so kunstvoll unter "self modifying code" versteckt, dass er kaum einen Hund hinter dem Ofen hervorlockte. Nach dem Wirbel kam dann ein Passus hinzu, der verdeutlichte, dass die Erkennung von self modifying code nur relativ wenig Adressleitungen nutzt und deshalb auch in ganz normalem Code zuschlägt.
:
Bearbeitet durch User
A. K. schrieb: > Axel S. schrieb: >> Wenn es richtig krass wird, können sogar Folgekosten entstehen, die in >> keinem Verhältnis zum Egoverlust stehen. Wenn z.B. irgendwo eine >> Industrieanlage hochgeht. Man denke nur zurück an den FDIV Bug. > > Welche Industrieanlage ist deswegen hochgegangen? Keine mir bekannte. Aber die Möglichkeit wurde damals wohl erstmalig(?) ernsthaft in Betracht gezogen. Und war da nicht auch mal was mit einer gescheiterten NASA Mission und einem falsch rechnenden Excel? > Allerdings betrachtete Intel bis zu diesem Zeitpunkt Errata als > Betriebgeheimnis, nur gegen NDA zu erfahren. Danach wurden sie > öffentlich. So gesehen also doch eine gute Sache.
nur weil ich gerade mit einer neuen Charge Toshiba µC das gleiche Problem habe: Fährst Du den PIC auf der höchsten Quarzfrequenz?
Achim S. schrieb: > nur weil ich gerade mit einer neuen Charge Toshiba µC das gleiche > Problem habe: Fährst Du den PIC auf der höchsten Quarzfrequenz? dsPIC33FJ64MC804-H/PT Externes Oszillator-Modul SG-310 SCF C mit 16.0MHZ & 100ppm ;(Fin = 16MHz) / (PllPre = 2) => Fref = 8MHz ;(Fref = 8MHz) * (PllDiv = 20) => Fvco = 160MHz ;(Fvco = 160MHz) / (PllPost = 2) => Fosc = 80MHz => Fcyc = 40MHz zulässige Bereiche: externer Takt, Fin: 0..40MHz Fref: 0,8..8MHz Fvco: 100..200MHz Fosc: ..80MHz Fcyc: ..40MHz Welches gleiche Problem? Geht beim Toshiba die UART auch nicht richtig?
UARTs scheinen herstelleruebergreifend Sorgenkinder zu sein. Auch TI hat nach einigem hin und her folgendes Erratum veroeffentlicht: SLLZ058A - TL16C752C/TL16C754C/TL16C2752 Short STOP Bit Errata "If the transmitter sends a STOP bit of shorter duration, e.g., 98 ms instead of 104 ms, the TL16C75xC can miss a subsequent START bit." Die Baudrate ist 9600 und statt ms sind wohl us gemeint :-) Zum dsPIC33: Die dsPIC33 habe ich wegen ihrem enormen Stromhunger nie ernsthaft in Erwaegung gezogen. Da ich aber, fuer Kleinkram, mittlerweile auch die alten Midrange-PICs einsetze, gucke ich ihn mir vielleicht doch noch mal an. Gibt es da einen empfehlenswerten kleinen?
(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· schrieb im Beitrag #4901029: > UARTs scheinen herstelleruebergreifend Sorgenkinder zu sein. > Auch TI hat nach einigem hin und her folgendes Erratum > veroeffentlicht: > > SLLZ058A - TL16C752C/TL16C754C/TL16C2752 Short STOP Bit Errata > > "If the transmitter sends a STOP bit of shorter duration, > e.g., 98 ms instead of 104 ms, the TL16C75xC can miss > a subsequent START bit." > > Die Baudrate ist 9600 und statt ms sind wohl us gemeint :-) Ja, typisch, gleicher Fehler. Anfänger. Hab im Herbst grad für ein Demo-Car für die CES einen LIN-Slave auf einem PIC24 implementiert. Der setzt das Receiver-Interrupt-Flag bereits in der Mitte des Stop-Bits. Wenn du dann auf eine PID (Sendeaufforderung) sofort antwortest, schneidet dein dominates Startbit die zweite Hälfte vom Stopbit ab und die Response wird für die anderen Teilnehmer unter Umständen unverständlich, weil sie halt auch die Start-Flanke zu früh bekommen. Also Workaround: Zusätzlicher Timer-Interrupt um eine halbe Bitzeit zu warten mit dem Sendebeginn. Würd' mich interessieren in wievielen Automotive-Produkten mit PICs dieses Problem übersehen wurde. Und weil ich nur den internen RC-Oszillator verwendet habe (PCB-Size), habe ich die LIN-Baud-Sync-Funktion der UART verwendet. Die hat natürlich auch einen Bug und ich hab einen zusätzlichen Flanken-Interrupt einbauen müssen. Anscheinend haben die diese Funktion zuerst falsch spezifiziert und dann nicht ein einziges Mal getestet. Im Errata steht natürlich auch nix... Programmieren von Peripherie-Modulen: 90er Jahre: Wenn was nicht geht hast was falsch programmiert. Heute: Wenn's nicht geht such den Bug im Chip. > Zum dsPIC33: > Die dsPIC33 habe ich wegen ihrem enormen Stromhunger nie > ernsthaft in Erwaegung gezogen. Ja, Strom ziehen die ordentlich. Allerdings war 2009 die Anforderung 10MBaud auf der UART eines von den Auswahlkriterien und ich hab etliche grosse Hersteller (ST,ARM,NEC,Freescale,TI usw.) durchgeschaut und nur den PIC mit einem Gehäuse unter 100 Pins gefunden der das kann. Alle anderen sind nur so ca. bis 3MHz gegangen. > Da ich aber, fuer Kleinkram, mittlerweile auch die alten > Midrange-PICs einsetze, gucke ich ihn mir vielleicht doch noch > mal an. Gibt es da einen empfehlenswerten kleinen? Wenn Du wenig Betriebs-Stromaufnahme willst, dann sind die Neuesten am Besten, die brauchen die wenigsten A/Hz (mA/MHz). Also die dsPIC33E Familie. Da gibt's sogar die EV-Familie, die noch mit 5V funktioniert, das ist bei manchen Designs ganz praktisch. Wenn Du allerdings einen besonders kleinen Sleep-Strom brauchst, sind wahrscheinlich die PIC24 mit XLP besser.
Hallo Hr. Professor! > ich würde Ihnen als mein ehemaliger N5c/1985-Schüler ja sehr gerne Wow! Gutes Gedächtnis, dafür dass sie uns nie in einem Fachgegenstand unterrichtet haben sondern "nur" in der Fünften im Labor. > einige Nachhilfe-Tipps dazu geben, aber ich bin heute (!) 69 Jahre alt > und empfinde mich nicht mehr total am neuesten Stand der µC-Technik, > schon gar nicht der PIC-Technik, weil ich ja schon immer der Meinung > bin, dass ein PIC gar kein µC ist ...... Wenn er kein uC ist, was ist er dann? Oder was ist dann ein uC? > Dass in die neuartigen Sensoren irgendwelche µC-Flöhe hinein gehören, > ist klar, und von Microchip gibt es ja einen ganz winzigen, wie ich > weiß. Ja PIC10. 6-poliges SOT23-Gehäuse. Ist süss, hab ich auch schon mal verwendet. > In allernächster Zeit zwar nicht, aber gleich danach (....) werde ich > Sie mal auf ein Bier einladen! Ja, gerne, vieleicht treffen wir uns ja auch im November in der Schule. > Noch viel Spaß beim Fehlersuchen! Wenn's doch bloss Spaß machen würde... 2 Wochen zu versuchen einen Workaround für den CAN-Bug zu finden weil der Kunde Abbrüche beim Umflashen hat ist nicht mehr lustig. (CAN meldet, dass Telegramm einwandfrei versendet. Alle Empfänger meinen, dass da garnix war. Workaround wird sein: Derivat tauschen auf eines mit 2 CAN's. Zweiten CAN zur Überwachung des Ersten nehmen.) Grüsse, Gernot Schreiner
chris schrieb: > Mich würde interessieren, wie der To aus demselben Takt die pll um ein > paar ppm verstellen konnte. So wie ich die pll von microchip kenne geht > dies absolut nicht. Ich hab's mir jetzt noch mal angeschaut, ist ja doch schon 8 Jahre her. "Ein paar ppm" ist wohl etwas drastisch formuliert. Sag' ma ein paar duzende ppm. Die Abweichung zweier gleicher Oszillator-Module mit +/-100ppm Toleranz die ich auf beiden Seiten verwendet habe hat ausgereicht, dass mir das Problem überhaupt aufgefallen ist. Die Empfangstoleranz der UART ist jedenfalls deutlich geringer als die üblichen 10000ppm (1%). Die PLL lässt sich recht fein tunen, da gibt's auch schon Schrittweiten so um 250ppm. Einfach alle Kombinationen durchpermutieren und dann nach Ausgangsfrequenz sortieren.
> Genau das ist ja irgendwie die Sache. Niemand aus einer professionellen > Liga käme je auf die Idee sowas zu machen. Naja, dafür dass ich nicht professionell bin kann ich ganz gut leben davon.
Gernot S. schrieb: > Welches gleiche Problem? Geht beim Toshiba die UART auch nicht richtig? nein, bei meiner charge Toshiba klappt die Kombinatorik auf einmal bei einem Modul nicht mehr und verzögert sich um einen internen Takt wenn die Frequenz maximal ist. Beim den 18er Pics bin ich immer wieder von deren Errata eingeholt worden: Bei 8Bit+Parity werden Daten zerstört, wenn Senden UND Empfangen gleichzeitig passiert. Da bin ich echt traumatisiert, auch wenn ich viel und gerne mit den gemacht habe.
Der TO hat nicht unrecht. Auch ich habe schon Fehler in PIC24 gefunden, die ja nicht unähnlich sind. Beispiel: Beim PIC24FJ128GC006 funktioniert ein LCD-Pin nicht. Das hat mir eine Platine gekostet. Bis heute findet sich das nicht im Erratasheet. Hier kann man mehr lesen: http://www.microchip.com/forums/m900661.aspx Andererseits ist das bei anderen Chips und Herstellern auch nicht besser: So hatten wir bei den SAM7 schon Probleme mit dem Flash, da hat uns ATMEL dann als Reaktion die waitstates für das Flash bei 50MHz hinaufgesetzt. Das fiese: Nur uns, alle anderen dürfen so weitersuchen, und sich dann wundern... Von Renesas hört man bei uns in der Firma ähnliche Geschichten. Beim STM32 fixen unsere Firmwerker permanent Bugs in der Peripheral Lib, cube soll nur vor Fehlern strotzen. Drum: Das ist kein Microchip-spezifisches Problem. Ein moderner Controller ist ein komplexes Gerät. Alles testen ist unmöglich. Feherfreie Hardware gibt es nicht.
Hallo zusammen, ich bin da auch ein gebranntes Kind, was die dokumentierten und undokumentierten Errata bei Microchip angeht... Auch die Qualität der Datenblätter lässt oft zu wünschen übrig. Da steht im dritten Nebensatz die entscheidende Information wie was funktioniert. Oder auch innerhalb gleicher Familien funktioniert die Peripherie völlig unterschiedlich, sodass man Code nicht so ohne weiteres wiederverwenden kann. Das eine I2C generiert ein ACK automatisch, beim nächsten muss man es selbst tun. Dann gibt es da Betriebsmodi, die können gar nicht funktionieren... Wenn ich überlege wie oft selbst einfachste Dinge nicht so funktionieren wie es im Datenblatt steht oder es einfach nur behämmert beschrieben ist, dann sind andere Controller echt eine Wohltat! Bei Atmel funktioniert es ja wenigstens so wie es im DB steht...auch ist die Anzahl der Errata oft deutlich geringer als bei Microchip. Ich bin mal gespannt wie es weitergeht...ob Microchip endlich bessere Qualität an den Tag legt oder die ehemaligen Atmel Produkte schlechter werden. Dass man einen komplexen Controller nicht komplett testen kann, lasse ich so nicht gelten! Die Tests können vollständig automatisiert werden und auch das Beschreiben der Tests ist eine endliche Aufgabe. Microchip nimmt es da wohl eher nicht so genau... Schaut man sich zum Beispiel die Cypress PSoCs an, dann ist es echt erfrischend wie wenige Fehler die Dinger trotz der enormen Komplexität haben. Da funktioniert einfach alles so wie beschrieben...Wahnsinn, oder? Microchip ist zwar günstig, aber wenn ich nachher Wochen verheizen tue, um ein undokumentiertes Silicon Errata zu finden und zu umschiffen, dann relativiert sich der Kostenvorteil sehr schnell! Viele Grüße! Sven
Sven L. schrieb: > Microchip ist zwar günstig, aber wenn ich nachher Wochen verheizen tue, > um ein undokumentiertes Silicon Errata zu finden und zu umschiffen, dann > relativiert sich der Kostenvorteil sehr schnell! Microchip ist eben typische mittlere Qualität. Im Gegensatz zu TI haben sie einen funktionsfähigen Support, im Gegensatz zu Maxim liefern sie ihre Chips auch wirklich aus (die Verfügbarkeit von Microchip ist allgemein relativ gut). Im Gegensatz zu NXP haben sie keine Scherzabkündigungen am laufenden Band. Im Gegensatz zu diversen "IOT Powerhouses" muss man nicht betteln, um Datenblätter zu bekommen. Dafür hat man ein Fehlerchen mehr, und die Featuers sind meist ein bisserle schlechter als anderswo. Es könnte deutlich schlimmer sein. Aber auch besser. Ich kann damit leben. Was die Datenblätter angeht: Es gibt deutlich schlimmeres. Ich finde sie mindestens brauchbar. Cypress ist allerdings wirklch ein Positivbeispiel, da muss ich dir zustimmen.
Axel S. schrieb: > Bastler schrieb: >> Erratas werden nur geschrieben wenn wirklich viele Anwender betroffen >> sind. > > Ich kann nur hoffen, daß das die Hersteller nicht so sehen. Sie sehen es so. Genau da liegt ja das Problem. > Jeder bekannte, aber verschwiegene Fehler kann zu verlorener Arbeitszeit > beim Kunden führen. Und in der Folge zum Verlust eines Auftrags. Das > kann der Hersteller vorher nicht wissen. Deswegen ist es auch in seinem > Interesse, die Macken seiner Produkte umfassend zu dokumentieren. Nach > Möglichkeit, bevor ein Kunde darauf stößt. Trotzdem bekommt man viele Errata Sheets erst nachdem das NDA unterschrieben ist, und auch erst nachdem man dem Lieferanten den Bug mehr oder weniger deutlich nachgewiesen hat. Vorher kann sich keiner vorstellen, dass das was nicht funktionieren sollte. Was Transparenz angeht ist der große Japaner eigentlich vorbildlich. Holländer, Texaner, die anderen Texaner und Norweger eher nicht so.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.