mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LPC2138, der grösste Pfusch seit es uP gibt


Autor: mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chriss chd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-))

Autor: chriss chd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab gerade nachgesehen:
http://www.semiconductors.philips.com/acrobat_down...
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!

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.
   "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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(letzte Zeile in vorangehendem Posting bitte ignorieren)

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Herr Lehrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Armutszeugnis stelle ich Dir für Deine Deutschkenntnisse aus.

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, da du Lehrer bist, kannst du es mir ja beibringen. Gerne auch
unter off-topic oder per Mail.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.
   "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?

Autor: mmerten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hei Rufus!

Man kann doch alles in Ruhe besprechen. Man muss doch nicht gleich auf
Krieg schalten.

Tschüss

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hä? "auf Krieg schalten"?
Hab' ich irgendwas verpasst?

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Er meint wohl Deine überhebliche, besserwisserische Art...

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Sufur III (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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!

Autor: Martin Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jochen Pernsteiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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...

Autor: René König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Jochen Pernsteiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: kryon2000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.....Genauso wie der 555 der 08/15-Timerbaustein ist.....

EEEEEEcht ????????

Autor: mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Birger* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mathias Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Tassilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tassilo,
Du scheinst da wieder dem alten Problem mit ISO9000/9001 aufzusitzen.
Regelmässiges Versagen ist nach ISO9000/9001 auch Qualität

Autor: Tassilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Patrick,

Ja - regelmässiges Versagen bedingt auch einer gewissen Qualität!
lol


Liebe Grüße
Tassilo

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: mmerten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ---- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Gerstner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Malte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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/...
(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???

Autor: buz11 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Malte

Meine Fresse , da sind ja gravierende Fehler drinn ...
( SAK-TC1775-L40E )


Wer kauft den sowas ?
Wird hoffentlich nicht in ein KFZ eingebaut .

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-).

Autor: T.Stütz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Gerstner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..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!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.