Hallo Leute! Ich habe mich jetzt ein wenig von der AVR-Welt getrennt und beschäftige mich nun mit ARM-Prozessoren. Die Rede ist vom 2106 und dem 2138. Grundsätzlich finde ich diese beiden Prozessoren echt toll, da sie Features besitzen, die man bei anderen Kontrollern schmerzlich vermisst. Z.B. Die Timer sind 32-Bit-breit, 16 Byte Hardware-Buffer für die UART, IAP-Programming, viel Flash, viel SRAM, AD und DA-Wandler ,fast jede Einheit ist doppelt vertreten. Setz- und Clearregister mit denen man sich das Verunden und Verodern spart. Doch leider schwindet die Euphorie, wenn man sich die Errata-Datenblätter ansieht. Zugegeben, jeder Chiphersteller macht seine Fehler bei der Chipherstellung, aber bei Philips funktionieren ganz grundsätzliche Dinge nicht und das Tolle dabei ist, dass der 2138 fast dieselben Fehler aufweist, wie der 2106, obwohl der 2138 eine Neuentwicklung ist. Anscheinend hat Philips nichts dazugelernt. Zudem ist auch noch der Support unschlagbar schlecht, da man keinen deutschsprachigen Profi an die Strippe kriegt. Die sitzen irgendwo in Holland. Ich zähle mal jene Fehler des 2138 auf, die ich am störendsten finde und wonach man den Prozessor meiner Meinung nach direkt in den Mülleimer befördern sollte. Gott sei Dank sind die neuen Prozessoren von Philips bleifrei, sonst müsste man auch noch eine Strafe wegen Umweltwerschmutzung zahlen. Der Brown-Out-Reset funktioniert nicht. Ich habe es selbst getestet und es steht auch im Errata-Sheet. TimerIRQs gehen verloren, wenn beim Löschen des IRQ-Register zur gleichen Zeit ein benachbarter IRQ auftritt, dasselbe gilt für die PWM-Einheit, auch bei der UART gibt es Probleme mit den enstbrechenden Registern Überigens scheint mir das Gehirn der Entwickler bei der Entwicklung der UART deutchlich nachgelassen zu haben, denn auf welche Weise manche IRQ-Flags gelöscht werden müssen, ist für mich nicht verständlich und macht das ganze sehr fehleranfällig und umständlich. So Leute - Jetzt möchte ich wissen was ihr davon haltet. Habt ihr einen besseren ARM einer anderen Firma in Benutzung? Was haltet ihr von den beschriebenen Fehlern? Danke für eure Antworten Tschüss Mario
Ist denn die UART der LPC21xx nicht direkt kompatibel zum 16550 von National Semiconductor? Wie die zu programmieren ist, sollte bestens bekannt sein, da sie in so gut wie jedem PC in Form der seriellen Schnittstelle eingebaut ist. Den Support "unschlagbar schlecht" zu nennen, nur weil er nicht deutschsprachig ist, finde ich übrigens reichlich seltsam. Daß Philips als holländische Firma in Holland ansässig ist, sollte eigentlich auch nicht wirklich verwundern ... Davon abgesehen: Natürlich sind Fehler in Prozessoren äußerst ärgerlich. Immerhin scheint Philips diese zu dokumentieren, was andere Firmen durchaus anders betreiben.
Dann kann ich dir nur Hyperstone ans Herz legen. Auf deren Webseite finde ich zwar kein Wort deutsch, aber die sitzen jedenfalls in Deutschland, gleich hier ums Eck in Konstanz: http://www.hyperstone.com/
Es handelt sich aber trotzdem um einen anderen Baustein, den man ganz anders ansteuert, nämlich über ein CPU-Bussystem. Natürlich muss der Baustein in irgendeiner Form kompatibel sein, sonst könnte man den µC nicht an den PC anschließen, aber ich bezweifle sehr stark, dass alle Register dieser beiden verschiedenen Bausteine identisch sind. Aus diesem Grund sind sie auch verschiedenartig zu programmieren. Normal ist es aber so, dass eine größere Firma Zweigstellen in vielen Ländern besitzt, noch dazu wo sich Firma Philips brüstet, der weltweit größte Elektrohersteller zu sein. Die Firma hat auch Zweigstellen in anderen Ländern, nur aber anscheinend kein Geld Leute anzustellen, die sich mit µC auskennen. Also meiner Erfahrung nach dokumentieren auch viele andere Firmen ihre Fehler. Firmen, die das nicht tun sind meiner Meinung nach sowieso unseriös. Wenn man z.B. Firma Atmel hernimmt. Dort kann man erkennen, welche Fehler wann korrigiert wurden. Aber mir scheint, wie wenn die Firma Philips kein Interesse hat, diese Fehler zu beseitigen, sonst hätte der neue Prozessor nicht dieselben Mängel wie der alte.
Hast schon recht, was Erratas angeht sind die unschlagbar. Zum Support kann ich nichts sagen, kenne mich da nur bei TI und AD aus und dort ist er super, wenn auch nicht deutsch. Englisch sollte man bei so einem Tätigkeitsfeld zumindest in Schriftform beherrschen.
meine erfahrung mit den lpcxxx - wie ich eine lib zeichen wollte, ist mir schon im datasheet ein fehler aufgefallen, ist wurde einfach eine pinnummer zweimal vergeben, dafür fehlte einer. ich hab gleich eine mail an den support geschckct, und hab prompt eine antwort bekommen, sie bedankten sich, hmm muss mal nachsehen ob der fehler noch drin ist ;-). ist aber nicht das erste mal dass ich im datasheets fehler finde (gerade in appnotes etc. von philips ist das sehr häufig leider :-( ) so hab ich leider noch zu wenig erfahrung mit dem lpcxxx aber das komtm jetzt in den nächsten drei monaten intensiv, dann kann ich dir mehr sagen (hoffetnlich nicht über fehler ;-))
hab gerade nachgesehen: http://www.semiconductors.philips.com/acrobat_download/datasheets/LPC2119_2129-03.pdf haben noch immer nichts geändert, dass finde ich echt wirklich voll toll. fehler können ja passierne (vielleicht nicht so viele wie bei denen ;-) ) aber wenn schon wer auf einen fehler hinweist, dann sollte man zumindest diesen schnellst möglich korregieren!?! page 6 P0.25-P0.13 hihi P0.25 gehört eigentlich auf pin 9. wenn ich ein datasheet lese, dann möchte ich nicht "wer findet den versteckten fehler? vergleichen sie seite 4 mit 6 im suchbild!" :-))))) schon teilweise großer schrott was die produzieren!
Den Problemen mit den Datenblättern muss ich leider zustimmen, habe schon einige Male auf Fehler hingewiesen. Leider findet sich dort niemand, der die Datenblätter in Ordnung bringt. Stephan.
. "Es handelt sich aber trotzdem um einen anderen Baustein, den man ganz anders ansteuert, nämlich über ein CPU-Bussystem. Natürlich muss der Baustein in irgendeiner Form kompatibel sein, sonst könnte man den µC nicht an den PC anschließen, aber ich bezweifle sehr stark, dass alle Register dieser beiden verschiedenen Bausteine identisch sind. Aus diesem Grund sind sie auch verschiedenartig zu programmieren." Hier liegt wohl ein Missverständnis vor. Die im LPC2106 verwendeten UARTs sind zwei 16550. Natürlich nur als IP-Cores, nicht als vierzigpolige externe Bausteine, aber das Konzept dürfte eigentlich nachvollziehbar sein. Zitat Datenblatt 210x: "Multiple serial interfaces including two UARTs (16C550)," und "Register locations conform to 550 industry standard." Das bedeutet, daß die UARTs des 210x exakt so zu programmieren sind, wie die in PCs verwendeten UARTs. Natürlich unterscheidet sich der Rest (Interruptcontroller etc.), und die erste UART hat ihre Handshakeleitungen nicht nach "draußen" geführt, aber das ändert nichts an der Registerkompatibilität. Philips hat im LPC210x UARTszwei n den einen IP-Core eines 16550
(letzte Zeile in vorangehendem Posting bitte ignorieren)
Armutszeugnis für so einen rießen Konzern wie Philips, daß sie weder deutschsprachige Experten haben noch das sie nicht auf Hinweise der Kunden bez. Fehler in Datenblättern reagieren. Naja, vielleicht war der zuständige ja krank und es ist einfach vergessen worden. Oder aber es werden Fehler erst dann korrigiert, wenn eine bestimmte Anzahl von Fehlermeldungen eingegegangen sind. Ich hatte mal im Datenblatt des VS1001 ein Fehler gefunden und es den Leuten in Finnland gemailt. Am nächsten Tag gabs ne neue Version des Datenblatts. So muß das laufen!! Ok, VLSI wird nicht annähernd so viele Mails bekommen wie Philips, aber trotzdem. Gruß Thorsten
Ein Armutszeugnis stelle ich Dir für Deine Deutschkenntnisse aus.
Naja, da du Lehrer bist, kannst du es mir ja beibringen. Gerne auch unter off-topic oder per Mail.
Das ist ja interessant, was ich da so zu lesen bekomme. Bin ich froh, dass ich nicht der einzige bin, der hier Probleme sieht. Im Allgemeinen sind auch mir vereinzelt Fehler im Datenblatt aufgefallen. Z.B. RTC-IRQ auch im Power-Down-Modus einschalten. Hier ist das Register im Datenblatt fehlerhaft beschrieben. Auch das habe ich schon gemeldet. Im Großen und Ganzen finde ich aber die Datenblätter ganz gut erklärt, wobei sie ab und zu etwas mehr ins Detail gehen sollten, um offene Fragen, die sich stellen zu beantworten. Ich habe von einem Insider mal gehört, dass Ferialpraktikanten oft mit der ehrenvollen Aufgabe betraut werden, die Datneblätter zu schreiben. Ob das jetzt bei Philips auch so läuft weiß ich allerdings nicht. @Rufus Zitat: Multiple serial interfaces including two UARTs (16C550)," OK, das mag ja alles stimmen und andere µC haben das auch in irgendeiner Form so im Datenblatt stehen. Trotzdem habe ich noch nie zwei verschiedene µC gesehen z.B. Philips ARM mit AVR128Mega, die gleiche Register für die Ansteuerung haben. Ich beziehe die Kompatibilität, die du hier ansprichst lediglich auf das Übertragungsprotokoll, aber nicht auf das Innenleben des Bausteins - Also die Registeransteuerung. Der C167 hat z.B. einen voll kompatiblen CAN-Controller inkludiert. -Kompatibel mit der Can-Spezifikation. Dann gibt es den AVRS90CAN128, der auch einen kompatiblen CAN-Controller drauf hat. OK! Wenn beide Prozessoren richtig konfiguriert sind, können sie Daten austauschen, aber die internen Register der Prozessoren sind bei den Can-Einheiten verschieden. Sie haben verschiedene Größen, verschiedene Namen. Natürlich sind sie ähnlich, aber ich kann keine Can-Initialisierung, die für den C167er geschrieben ist für den AVR nehmen. So kompatibel sind die leider nicht. Tschüss
.
"Ich beziehe die Kompatibilität, die du hier ansprichst
lediglich auf das Übertragungsprotokoll, aber nicht auf
das Innenleben des Bausteins
- Also die Registeransteuerung."
Dann hast Du das noch nicht richtig verstanden. Die im LPC210x verbaute
UART ist eine 16550, und damit Bit für Bit registerkompatibel zur im
PC verwendeten 16550.
16550 ist kein Übertragungsprotokoll- oder Interface-Standard, sondern
ein real existierender Baustein bzw. IP-Core.
Andere µCs haben das eben nicht so im Datenblatt stehen, wenn deren
UART nicht der 16550 entspricht.
Das Datenblatt des Mega128 erwähnt nirgends, daß die UART in
irgendeiner Weise kompatibel zur 16550 wäre, daher ist Dein
"Vergleich" müßig.
Wird's klarer?
wenn jemand 16C550 in den chip integriert egal welcher hersteller, dann hat die register- und bitanordnung dem 16C550 standard zu folgen, sonst wärs halt kein kompatibler UART sondern höchstens ein funktionskompatibler und man muß seine ganzen libraries umschreiben.
Hei Rufus! Man kann doch alles in Ruhe besprechen. Man muss doch nicht gleich auf Krieg schalten. Tschüss
Hä? "auf Krieg schalten"? Hab' ich irgendwas verpasst?
Er meint wohl Deine überhebliche, besserwisserische Art...
@Mario: er hat es ganz sachlich erklärt und nochmal eine Deutlichkeitsstufe zugelegt. Was soll er noch tun? Hast Du mal in Holland angerufen? Ich habe häufiger mit Technikern in Holland zu tun und noch ehe ich die Frage ausgesprochen habe, ob ich Englisch oder Deutsch sprechen soll, fragen die mich in Deutsch, wie sie mir helfen können. Die Beschwerde, daß die keinen deutschsprachigen Support hätten, ist also schon fast schon unverschämt. (Tut mir leid, aber so empfinde ich das!) µC mit ARM-Core findest Du über Google genug, unter anderem die AT91 von Atmel. Nur ist keiner (den ich kenne) so billig (sic!) und leicht verfügbar wie die von Philips. Wenn ich nur eine Handvoll davon bräuchte, würde ich natürlich eher zehn Euro mehr anlegen, wenn ich dafür weniger Ärger habe. Habe mich aber nie um ein entsprechendes Modell bemüht, weil es sich bei größeren Stückzahlen halt doch lohnt, die Probleme zu umgehen. Aus dem Kopf weiß ich nur, daß es bei Phytec CPU-Module mit AT91xxx gibt, aber ich weiß natürlich nicht, ob das Deinen Zielen entspricht.
@Rufus Ja, Du hast etwas verpasst! Und zwar hast Du anscheinend Deinen eigenen Beitrag nicht gelesen bzw. das Verhalten Deiner Eltern hat Dich so geprägt, daß Du nicht anders kannst. Nennt man auch: Fremdwarnehmung!
@John, @Sufur Wo bitte ist da "Krieg"?? Oder "besserwisserische Art"? Mal abgesehen vom tatsächlichen Besser-Wissen, das hat Rufus ja auch ganz klar, detailliert und ruhig geschrieben. Ich habe jedoch keinerlei Beschimpfung, keine pauschalen Intelligenz-Aussagen und sonstige Entgleisungen bemerkt. Also: klärt mich auf! Danke, Martin
@Philipp OK! Ich gebe zu, dass ich noch nicht angerufen habe. Ich nehme mich jetzt mal an der eigenen Nase. Ich werde mal anrufen und meine Erfahrungen dann hier posten. @Rufus Auf Krieg schalten war natürlich übertrieben. Aber ich finde, dass du deine Beiträge etwas freundlicher gestalten könntest, was aber nicht heißt, dass du extra eine Zierleiste rundherum machen musst. Wie machst du das eigentlich mit dem Unterstreichen? Tschüss Mario
Natürlich ist ein Satz wie: "Wie die zu programmieren ist, sollte bestens bekannt sein, da sie in so gut wie jedem PC in Form der seriellen Schnittstelle eingebaut ist." besserwisserisch. Als ob auch nur ein nennenswerter Promillesatz der hier Postenden so ein Teil jemals programmiert hat. Dazu dann: "sollte eigentlich auch nicht wirklich verwundern ..." sowie die Unterstriche. Ich kann schon verstehen, daß das jemanden stört.
>Natürlich ist ein Satz wie: >"Wie die zu programmieren ist, sollte bestens bekannt sein, da sie in >so gut wie jedem PC in Form der seriellen Schnittstelle eingebaut >ist." >besserwisserisch. Als ob auch nur ein nennenswerter Promillesatz der >hier Postenden so ein Teil jemals programmiert hat. So ein Quatsch! Hat Rufus behauptet, daß es den Forumsteilnehmer hier bekannt ist? Von einem Chip, der schon milliardenfach verbaut wurde, kann man wohl behaupten, daß dessen Programmierung bekannt ist. Und in diesem Zusammenhang ist der Satz im ersten Posting wohl Käse: >Überigens scheint mir das Gehirn der Entwickler bei der Entwicklung >der UART deutchlich nachgelassen zu haben
"Von einem Chip, der schon milliardenfach verbaut wurde, kann man wohl behaupten, daß dessen Programmierung bekannt ist." Und den Videorekorder programmieren kann auch jeder... Und nein, man kann es nicht behaupten...
> Und den Videorekorder programmieren kann auch jeder...
Natürlich nicht. Aber die, die das nicht können, erzählen auch nichts
über ungünstig konstruierte Laufwerke oder ähnliches. Hier hingegen
wird den Entwickelrn gleich Gehirn abgesprochen.
>Und den Videorekorder programmieren kann auch jeder... Wieso jeder? Steht das irgendwo? >Und nein, man kann es nicht behaupten... Aber selbstverständlich. Der 16550 ist der 08/15-UART. Genauso wie der 555 der 08/15-Timerbaustein ist.
.....Genauso wie der 555 der 08/15-Timerbaustein ist..... EEEEEEcht ????????
Das mit dem mangelnden Gehirn habe ich deshalb geschrieben, weil im Errata-Sheet beschrieben ist, dass es zu Problemen kommen kann, wenn ein UART-IRQ auftritt und gleichzeitig das entsprechende Register zum Löschen eines anderen UART-IRQs gelesen wird. Dadurch kann es dazu führen, dass der IRQ nicht gelöscht wird, den man eigentlich löschen wollte, nur weil zu diesem Zeitpunkt die Hardware drauf zugreift, um einen anderen UART-IRQ zu melden. OK! Fehler können passieren, aber so ein Mehrfach-Zugriff von Hardware und Software auf ein Register, sollte schon bei der Chipherstellung durchdacht werden und was noch hinzukommt es ist erstens kein Einzelfall - Auch bei den Timern und der PWM-Einheit gibt es ähnliche Probleme und zweitens gab es dieselben Probleme beim 2106er Prozessor, also dem Vorgänger. Und keiner kann mir erzählen, dass es dieses Problem auch bei dem 16550-Baustein gibt, oder?
Hab die Tage mal das Errata des LPC2129 gesehen. Auch dort eine lange Liste mit fatalen Fehlern, die eigntlich einen professionellen Einsatz ausschließen. Meiner Meinung gehört die ganze Philips-Arm-Reihe dringend einer gründlichen Nachbessereung unterzogen. Die Erratas, die alle keine Peanuts darstellen, dürften vermutlich auch zu wirtschaftlichen Schaden bei denen führen.
Unglaublich! Der LPC2129 hat aber viele Fehler. Da geht es mir ja mit dem 2138 richtig gut. Leider wird wahrscheinlich der Schaden nicht so hoch sein, da sich die Leute meist erst dann mit dem Errata-Sheet beschäftigen, wenn die ersten Schwierigkeiten mit dem Baustein auftreten, so wie es bei mir mit der BOD-Detection war. Der Hersteller verdient einfach das Vertrauen des Kunden nicht. In Zukunft werden von mir immer zuerst die Errata-Sheets heruntergeladen, um Enttäuschungen zu vermeiden. Tschüss
Wir benutzen den AT91rm9200 von Atmel und da sieht das Errata-Sheet nicht wirklich besser aus, auch hier wurden Fehler vom 55800 "mitgeschleppt". Mir scheint, dass es bei den ARM-Controllern doch einige Probleme gibt...
Hi @All, OK! jeder darf Fehler machen! - Es darf auch mal ein Proz verbockt werden! - Alles kein Problem für mich! Wo ich mir aber die Frage stelle ist: >haben noch immer nichts geändert, dass finde ich echt wirklich voll >toll. fehler können ja passierne (vielleicht nicht so viele wie bei >denen ;-) ) aber wenn schon wer auf einen fehler hinweist, dann >sollte man zumindest diesen schnellst möglich korregieren!?! Haben die die Iso9001 geschosssen oder bei Aldi gekauft!? Das kann es ja wohl nicht sein - oder!? Es ist doch heute kein Problem alle betroffen Stellen (Firmenintern) eine Info zu geben und das zu ändern (siehe ISO9001)! Ich finde so eine kleine Sache ist doch in 2AT erledigt!? Ach ja und den Schreiberling würde ich sofort entlassen! Denn es kann sich kein ING.-Büro leisten so zu arbeiten! Liebe Grüße Tassilo
Tassilo, Du scheinst da wieder dem alten Problem mit ISO9000/9001 aufzusitzen. Regelmässiges Versagen ist nach ISO9000/9001 auch Qualität
Hi Patrick, Ja - regelmässiges Versagen bedingt auch einer gewissen Qualität! lol Liebe Grüße Tassilo
Wie behebt man denn korrekt einen Konflikt zwischen z.B. einem Hardwareereignis, das ein Flag setzt und einem Softwarecode, der es gleichzeitig löscht? Tja, kommt darauf an ... Wo fuhrwerkt man denn im normalen Leben in Interruptflags herum? In der Interruptroutine. Und was tut man, wenn man nicht ausschließen kann, daß währenddessen neue Interruptereignisse passieren? Richtig, man macht im kritischen Augenblick ein cli(). Das macht man auch, ohne überhaupt in die errata geschaut zu haben, und -- soweit ich es aus der Beschreibung hier entnehme -- taucht damit das Problem im echten Leben gar nicht auf. Muß man es dann mit großem Aufwand beheben? Oder reicht es nicht, an das Problem zu erinnern? Mir persönlich ist es lieber, um ein Problem zu wissen, aber die Freiheit zu behalten, es auf meine Weise zu umschiffen, als daß etwa beim AVR grundsätzlich während der Interruptroutine keine Interrupts auftreten können, wodurch zwar solche Probleme nicht auftauchen, ich aber andere Freiheiten verliere. Grundsätzlich natürlich: das Prozessorverhalten sollte in jedem Fall nachvollziehbar definiert sein. Aber (nicht nur) ich habe etliche Jahre 6502 programmiert und mit dem (wesentlich heftigeren) Seitenadressierungsfehler leben gelernt und mich heftig gegen korrigierte Versionen gewehrt, mit denen Programme, die den Fehler berücksichtigten, dann nicht mehr liefen ...
"6502 programmiert und mit dem (wesentlich heftigeren) Seitenadressierungsfehler leben gelernt" Was war das für einer? Ich erinnere mich nur an den Fehler vom indirekten Sprung und da der Workaround in der Vermeidung bestand, war eine korrigierte Version kein Problem.
Das ist aber der altbekannte und vom mir beschriebene. Und ich kann mir nicht vorstellen, dass jemand Code hingerotzt hat, der bei einer in dieser Hinsicht korrekt arbeitenden Version nicht funktioniert.
@Philipp "Richtig, man macht im kritischen Augenblick ein cli()." Das geht doch nur, wenn es sich um nicht atomare C-Instruktionen handelt. Hier aber ist die Hardware der Schuldige und da hilft nix ! Wenn irgendwo ein Latch und ein Gate in der Hardware fehlt, um den gleichzeitigen Zugriff von verschiedenen Hardwareeinheiten zu synchronisieren, dann fehlt es. Peter
"Das ist aber der altbekannte und vom mir beschriebene. Und ich kann mir nicht vorstellen, dass jemand Code hingerotzt hat, der bei einer in dieser Hinsicht korrekt arbeitenden Version nicht funktioniert." @A.K.: Das meinte ich doch. Ich verstehe auch nicht, was Philip sich da zurechtgestrickt hat. Einen anderen Fehler habe ich auch nie bemerkt.
Irgendwie verstehe ich die ganze Aufregung nicht. Für (fast) jeden aktuellen µc gibt es mehr und weniger umfangreiche Buglists. Nur gehen die Hersteller damit halt sehr verschieden um. Mal wird alles veröffentlicht (sehr lobenswert), einige nur teilweise während andere diese Fehlerlisten nur ausgewählten Grosskunden zugänglich machen. Den 100% fehlerfreien µc wird`s wohl niemals geben. Wenn ich eine umfangreiche Buglist kriege, aber keiner mich bei der aktuell vorgesehen Anwendung behindert, dann kann ich den Controller ja ohne Probleme einsetzen. Und mir ist eine ehrliche Fehlerliste auf Herstellerseite wesentlich lieber, als wenn diese wie Staatsgeheimnisse gehandelt werden.
6502: Natürlich meine ich den Fehler. Wenn ich kein NOP einfügen will, um den Seitensprung zu umgehen, rechne ich den Seitenfehler halt mit ein. Dann geht das Programm aber nicht mehr, wenn der Fehler korrigiert wurde. @Peter: Keine Ahnung, was Du meinst. Wenn ich in ein Hardwareregister schreibe, muß ich der Hardware mitteilen, daß sie das im Moment nicht darf, weil ich ein eindeutiges Ergebnis brauche. Mit C oder nicht und atomar oder nicht hat das nichts zu tun. @mmerten: Versuche ich ja auch zu sagen, scheint aber nicht anzukommen.
> Wenn ich kein NOP einfügen will, um den Seitensprung zu umgehen, > rechne ich den Seitenfehler halt mit ein Bitte dann aber nicht wundern, wenn der Fehler gefixt wird, und deine Software nicht mehr läuft, da sie diesen Fehler aber voraussetzt. Das könnte man wilden Hack, aber nicht sauberen Programmierstil nennen. > Wenn ich in ein Hardwareregister schreibe, muß ich der Hardware > mitteilen, daß sie das im Moment nicht darf Das geht aber leider nicht (auch nicht mit "cli")! Mit cli/sei-"Klammerung" kannst du verhindern, daß eine Operation unterbrochen wird, die eigentlich nicht unterbrochen werden darf. D.h. aber nur, daß eine zufällig auftretende InterruptROUTINE keine Werte verändern/modifizieren kann, die im normalen Ablauf gerade in Bearbeitung sind. Den zufällig auftretenden Interrupt selbst oder besser gesagt dessen Ankündigung (=Setzen der InterruptFlags) kannst du nicht verhindern - auch wenn du mit cli Interrupts global sperrst! > Irgendwie verstehe ich die ganze Aufregung nicht. Es ginge nicht um die Fehler selbst, sondern daß diese auch im Nachfolgeprodukt noch enthalten sind! Das ist ein Unterschied. ;-) ----, (QuadDash).
Habe letzte Woche mein LPC2292 Testboard aus der Bestückung erhalten (Ich löte doch kein 0,5mm pitch selber). Mein Softwerker ist nun überglücklich: CAN, externer SRAM (128kB), Ethernet (LAN91C96), ADC, DAC (PWM) geht alles. Die Erratasheet kennt er und meint alles in den Griff zu kriegen. Den Dummy-Interrupthandler für die non-vectored IRQs hat er auch schon aufgesetzt und der wird auch manchmal getriggert, obwohl nirgends freigegeben. Allerdings kann man sich das "Billig" abschminken. Der LPC mag zwar billiger sein als mancher 8-Bitter, aber 144-Pin 0,5mm Pitch machen das Layout und die Platine umso teurer. Unter 4-Layer (2*Signal, 2*Powerplane) is da nich und händisch Routen ist angesagt. Peter
Hallihallo..... "...größter Pfusch..." schon mal die Welt um Dich herum betrachtet? Schon mal irgendwas gefunden was keine Kompromisse oder etliche Bugfixes enthält? Schon mal das perfekte Produkt gesehen? Da brauch man gar nicht weiter rumzuphilosophieren...oder? BTW: schau Dir doch mal das errata eines " 32-bit microcontroller for high demanding automotive and industrial applications (e.g. engine management, starter generator, 3-phase motor control or robotics) " an (Infineon Tricore) und stell Dir vor Du bist grade mit 200 auf der Autobahn unterwegs während das Teil Deinen Motor steuert...
>schau Dir doch mal das errata eines " 32-bit microcontroller for >high demanding automotive and industrial applications >(e.g. engine management, starter generator, 3-phase motor control or >robotics) " an (Infineon Tricore http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/prod_ov.jsp?oid=13753 (Errata ist ganz unten.) Ähhh, in Assembler mag man die vielen Fehler ja noch umgehen können, aber wie bringst man derartiges einem C-Compiler bei???
@Malte Meine Fresse , da sind ja gravierende Fehler drinn ... ( SAK-TC1775-L40E ) Wer kauft den sowas ? Wird hoffentlich nicht in ein KFZ eingebaut .
Andersrum. Ein Compiler kann mit Problemen bei bestimmten Befehlen oder Sequenzen ganz gut umgehen. Muss man halt entsprechende Hacks einbauen, um die zu vermeiden. Spätestens der Peephole-Optimizer sollte das hinbekommen. Das macht der Autor des Compilers also einmal und dann ist Ruh. Und bestehende Programme werden halt neu compiliert. Aber ob jeder Assembler-Programmier jedes einzelne Mal dran denkt? Und bei neu gefundenen Bugs jedes bestehende Programm systematisch danach durchsucht? Besser wird das erst, wenn der Assembler schlau genug ist, und vor problematischen Sequenzen warnt. Aber das Teil ist schon eine rechte starke Nummer. Wenn's nicht schon ein paar Jahre alt wäre, man sollte meinen das sei die "first silicon" Version (nu, vielleicht ist sie es ;-).
Bei Infineon werden die einzelnen "Steps" = Prozessorversionen durch 2 Buchstaben gekennzeichnet. AA= Allererste Version (meist nie ausgeliefert) BA= zweite Version CA= dritte Version (eventuell noch Hotfixe CB,CC...) in deinem Errata steht also drin das es die Fehlerliste für die zweite Version ist. Beim C16x sind die mittlerweile beim HA-Step angekommen während sehr lange der CA-Step ausgeliefert (und verbaut wurde) Wir verwenden den Keil uVision (1+2) Compiler der hat mit den meisten Erratas garkeine Probleme und wo Probleme auftauchen gibts entsprechende Programme oder Hinweise (von Infineon!) Gruss
..genau das wollte ich damit auch sagen....Bugs in Hard und Software wird es immer geben, trotzdem schaltet die Controller gesteuerte Automatik eben nicht bei 180 plötzlich in den Rückwärtsgang und beim zuknallen der Motorhaube geht höchst selten der Airbag los. Je höher die Komplexität um so höher der erforderliche Aufmerksamkeitsfaktor, als Programmierer hat man nunmal die Pflicht paranoid zu sein. (ganz besonders wenn an der SPS auch die Sprinkleranlage hängt) Fröhliches bitschieben!
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.