Hallo,
in der anscheinend noch aktuellen IAR Workbench für den 8051 gibt es
noch einen, meiner Ansicht nach, großen Bug. Ich habe an der Stelle
darüber gebloggt und ein paar Details:
https://sebastianfoerster86.wordpress.com/2016/02/13/3-2-computer-says-yes/
Weiterer großer Nachteil war, ich konnte nicht auf die alte IAR zurück,
da hätte ich alle Projektfiles neu aufsetzen müssen -> keine
Abwärtskompatibilität.
Aktueller Workaround: Optimierungsstufe Low setzen. Das ist sicherlich
verschmerzbar, aber dazu muss man wissen, dass es ein Problem geben
könnte.
Da IAR es nicht tut (klar), möchte ich hier also eine kleine Warnung
aussprechen, dass Ihr nicht über die Selbe Sache stolpert.
VG
Basti
Basti schrieb:> ich konnte nicht auf die alte IAR zurück,> da hätte ich alle Projektfiles neu aufsetzen müssen
Ich baue alles mit Makefiles. Genau sowas ist der Grund dafür.
@Rufus Τ. Firefly jup... ist wohl alles in Arbeit... nur malen die
Mühlen dort wohl sehr langsam?!
Finde aber auch die Seite sehr unübersichtlich...
Die Compilerversion auf der Seite ist anscheinend noch dieselbe wie Ende
November, man könnte diesen Bug also noch nachstellen.
Tja. Kannst Du denn das Problem aus Deiner speziellen Software-Umgebung
herauslösen und ein übersetzbares Minimal-Beispiel konstruieren, das
diesen Fehler ebenfalls provoziert?
Basti schrieb:> ich konnte nicht auf die alte IAR zurück,> da hätte ich alle Projektfiles neu aufsetzen müssen
Du kannst doch auch einfach die passende alte Version des betreffenden
Projektfiles von damals gezielt einzeln auschecken und wieder committen.
Da brauchst Du doch nichts neu aufzusetzen, Du gehst einfach mit den
betreffenden Dateien so weit wie nötig in der Zeit zurück.
@Rufus Τ. Firefly ohne dieses Minimalbeispiel hätte mir der Support
wahrscheinlich nicht geglaubt.
@Bernd K. wenn man die hat, ja natürlich :)
Also für mich ist das Thema schon länger erledigt, aber trotzdem Danke
für die Hinweise.
Vielleicht hat jemand anders die selbe Version und möchte einer
Serienfirmware schnüren. Daher der Hinweis von mir.
VG
Basti
Basti schrieb:> https://sebastianfoerster86.wordpress.com/2016/02/13/3-2-computer-says-yes/
Ein Screenshot ist die blödsinnigste Art, eine Fehler zu demonstrieren.
Man kann nichts zitieren, compilieren und sieht nicht, was davor
passiert.
Das else kommt nach einem Vergleich auf ==1, d.h. da wird das Carry
gelöscht. Danach wird in Assembler mit 3 verglichen, was Du im Quelltext
unkenntlich gemacht hast.
Dein Post zeigt also alles mögliche, nur nicht den Fehler.
Note 6, setzen.
Wenn Du dem Support sowas hinwirfst, wundert mich nicht, daß die nicht
reagieren.
Hallo Peter,
wenn es deinen Ansprüchen nicht genügt, ist das auch okay.
Vielleicht solltest du dir aber noch mal etwas mehr Zeit mit dem
Screenshot nehmen, dann verstehst du es vielleicht doch noch. Ich habe
keinen Quellcode verschwinden lassen, nur die Variablennamen eingekürzt.
Das es diesen Bug gibt ist zweifelsfrei geklärt, darauf braucht man
nicht mehr rumreiten.
VG Basti
Bernd K. schrieb:> Du kannst doch auch einfach die passende alte Version des betreffenden> Projektfiles von damals gezielt einzeln auschecken und wieder committen.
Aua, der war aber echt unter die Gürtellinie :-)
Basti schrieb:> wenn es deinen Ansprüchen nicht genügt, ist das auch okay.
Es sind nicht meine Ansprüche, sondern die absolut minimalen Ansprüche
eines jeden, der das Problem nachvollziehen soll.
Basti schrieb:> Vielleicht solltest du dir aber noch mal etwas mehr Zeit mit dem> Screenshot nehmen, dann verstehst du es vielleicht doch noch.
Wie schon gesagt, das halb gelöschte Define im Quelltext ist nicht
einsehbar. Und der Assemblertext davor auch nicht. Sogar alle
Variablendeklarationen fehlen komplett.
Man ist nur auf Deine Behauptungen angewiesen. Der Screenshot ist völlig
überflüssig, er zeigt den Fehler nicht!
Für eine minimal ausreichende Fehlerbeschreibung macht man eine
komplette Funktion daraus, ersetzt alle Defines durch Zahlen und zeigt
das komplette Assemblerlisting dieser Funktion. Alles andere ist nur
unbrauchbares Geschwurbel.
Hallo Peter,
ist es nicht öfter mal so, dass man jemanden mal was glauben muss? Für
IAR habe ich das ganze natürlich besser aufbereitet.
Der Screenshot zeigt den Fehler, aber nicht den Ursprung (nichts davor
und nichts dahinter).
Der Inhalt von tx_value war 3 und steht im accu (A). (Ist zu erkennen)
Das Carry Flag ist gesetzt. (ist zu erkennen)
Die nächste Operation die ausgeführt wird ist SUBB. (ist zu erkennen
(grün))
Die Define-Konstante wurde vom Preproc/Compiler von 0x02 zu 0x03
heraufgesetzt. (kein Fehler, vielleicht etwas schwer zu erblicken)
A C #
A = 0x03 - 0 - 0x03
sollte eigentlich ausgeführt werden, um im richtigen Zweig zu landen.
Durch das Carry Flag wird es aber:
A = 0x03 - 1 - 0x03
Gern kann ich, bei sinnvoller Kritik, den Blogpost mit weiteren
Informationen füllen. Quellcode kann ich jedoch nicht bereit stellen.
VG
Basti
Peter D. schrieb:> Für eine minimal ausreichende Fehlerbeschreibung
Im Gegensatz zu den allermeisten hiesigen Nachrichten, bei denen
natürlich grottenschlechte Fehlerbeschreibungen geliefert werden, sucht
Basti hier aber nicht nach Hilfe bei der Lösung seines Problems, sondern
stellt dieses einschließlich einer korrekten Fehleranalyse vor. Sein
derzeitiges Problem besteht auch nicht darin, IAR vom Vorhandensein des
Fehlers zu überzeugen, sondern nur zügig einen fehlerfreien Compiler zu
erhalten.
Ich vermute, dass der derzeitige Versionsstand des Compilers nach allen
möglichen Vorgaben "zertifiziert" ist. Wenn solch eine Zertifizierung
erfolgreich durchlaufen wurde, spielt die tatsächliche Produktqualität
überhaupt keine Rolle mehr und kann unterirdisch schlecht sein. Ich habe
dies auch schon bei einem Mikrprozessor erlebt, dem AT91RM9200. Mein
damaliger Kunde (Atmel-Großkunde!) hatte damals auch ziemlichen Druck
gemacht und immer wieder erfahren, dass eine Korrektur der zahlreichen
Fehler dazu führen würde, dass der Baustein seine Zertifizierungen
verliere. Deswegen solle man auf die damals angekündigten AT91SAM9
warten.
Bezüglich des IAR-Compilers ist es vermutlich so, dass die eigentliche
Behebung nur zehn Minuten dauert, aber vorher und nachher Unmengen an
Dokumenten erstellt, verteilt, gelesen, bewertet, diskutiert,
überarbeitet, usw. werden müssen. Und dabei müssen alle Formalien
eingehalten werden, damit auch die neue Compilerversion zertifizierbar
bleibt. Solange die Formalitäten eingehalten werden, kann dann auch
niemand IAR juristisch ans Bein pinkeln.
Andreas S. schrieb:> sondern> stellt dieses einschließlich einer korrekten Fehleranalyse vor.
Das macht er eben nicht!
Er zeigt nur einen ganz ganz kleines Codehäppchen, wo nichtmal die
Variablendeklarationen und die Defines ersichtlich sind.
Wichtig wäre aber der Assembler davor, denn der soll ja angeblich den
Fehler enthalten. Insbesondere fehlt, warum der Vergleich 1==1 vor dem
else das Carry setzen soll.
Das gezeigte kleine bischen Assembler ist komplett fehlerfrei. Eine
Fehleranalyse wird nicht gezeigt und ist aus dem Screenshot auch nicht
möglich.
Man liest hier ständig Threads, wo Programme abhängig vom
Optimierungslevel unterschiedlich funktionieren. Die Gründe reichen von
anderem Speicherlayout, anderer Ausführungszeit, fehlendem volatile usw.
und sind wirklich sehr sehr selten ein Compilerfehler.
Daher wäre eine ernstgemeinte Fehleranalyse durchaus sinnvoll.
Hallo Peter,
ich hab es wirklich mit dir versucht, aber ich verstehe dein Problem
nicht so recht.
Wieso forderst du mit dem arroganten Ton Mehrarbeit von mir?
Ich steh doch auch nicht am Altkleiderkontainer und sage: "Was nur ein
Pullover? Ohne Hose und Schuh darfst du hier keinen Pullover einwerfen!"
Wenn ich tx_value zu 3 definiere (wie es auch war und im Screenshot
ersichtlich ist) und das define 0x02 ist (siehe IAR Quellcode-Suchlauf
unten im Bild), dann muss der Vergleich falsch sein (Wirkung). Warum das
Carry Flag noch gesetzt ist, interessiert mich wenig (Ursache).
Wenn es dich interessiert, dann darfst du gern deine Energie
hineinstecken und es aufarbeiten.
VG Basti
Basti schrieb:> Wieso forderst du mit dem arroganten Ton Mehrarbeit von mir?
Ich fordere keine Mehrarbeit, ich hatte mich einfach nur für Dein
Problem interessiert und wollte es verstehen, mehr nicht.
Wenn Du aber keine Lust dazu hast, Dein Problem für andere
nachvollziehbar darzustellen, dann verstehe ich nicht, warum Du
überhaupt erst den Beitrag geschrieben hast. Etwa nur, um über IAR zu
lästern?
Man schreibt doch, damit andere was damit anfangen können.
Aber mit dem Screenshot kann keiner was anfangen, da er nur
einwandfreien Code zeigt. Ob ein "CLR C" fehlt, könnte man nur mit dem
vorausgehenden Code feststellen, der Carry modifiziert.
Und es kann auch keiner selber das Problem compilieren und debuggen, da
Du kein Codebeispiel zeigst.
Ich hatte einfach nur gedacht, Du willst anderen damit helfen, aber da
habe ich mich eben getäuscht. Ist aber kein Beinbruch, ich benutze eh
den Keil.
Peter D. schrieb:> Ich fordere keine Mehrarbeit, ich hatte mich einfach nur für Dein> Problem interessiert und wollte es verstehen, mehr nicht.
Dann solltest du damit beginnen Fragesätze zu formulieren. Ich sehe über
deine Beiträge nur einen: "Etwa nur, um über IAR zu lästern?"
Peter D. schrieb:> Ist aber kein Beinbruch, ich benutze eh den Keil.
Der geliehene IAR Dongle, den ich verwendete habe, ist auch schon lange
wieder beim AG.
Überlassen wir es am besten den Leuten die auf der 9.30.1 arbeiten
(müssen), mit den gegebenen Informationen etwas anzufangen oder auch
nicht.
VG
Basti
Rufus Τ. F. schrieb:> Basti lädt das angesprochene Minimalbeispiel hoch, mit dem das Phänomen> nachvollziehbar ist.
Wenn er die Lizenz dafür nicht mehr hat, kann er aber nur den
Sourcecode hochladen, nicht das Compilat.
Könnte dann höchstens jemand versuchen, mit einer Kickstart-Version
mal zu compilieren. Wenn es ein Minimalbeispiel ist, wird es ja wohl
unter deren Codesize-Limit bleiben. ;)
Würd' ja reichen, für diejenigen, die den Compiler selbst verwendn, und
wäre einem Screenshot gegenüber überlegen.
Obendrein kann man den Compiler auch als Demoversion nutzen.
Rufus Τ. F. schrieb:> Obendrein kann man den Compiler auch als Demoversion nutzen.
Entweder halt in der genannten Kickstart-Version, oder nur nach
entsprechender Registrierung mit anschließendem „Warum wollen Sie uns
nicht kaufen?“-Generve.
Das versendete Minimalbeispiel besteht aus einer Funktion (komplett wie
im Originalprojekt) und der main.
Leider (wie im Screenshot) mit vielen Produktnamen und anderem Gerödel,
welches ich nicht veröffentlichen kann.
Anbieten kann ich nur eine (gerade erstellte) abgespeckte Variante.
Da ich keine IAR Workbench mehr installiert habe, kann ich nur
ungetesteten/uncompilierten Quellcode anfügen, der wahrscheinlich immer
noch viel Überflüssiges enthält. Ob das die Qualität erhöht ist äußerst
fraglich...
Ja, mit der Kickstarter-Version wird es wohl gelingen es nachzustellen.
VG
Basti
att und value sind volatile. Mit den (ansonsten völlig überflüssigen)
Typecasts beim Aufruf von WriteAttrCB wirfst Du diese Eigenschaft weg,
d.h. der Compiler weiß in der Funktion nicht mehr, daß die übergebenen
Parameter Pointer auf volatile sind.
Ob das wirklich Deine Absicht ist?
@Rufus Τ. Firefly im eigentlichen Quellcode ist "WriteAttrCB" eine
Callback die durch den TI-Stack aufgerufen wird.
Die main() hat natürlich wenig mit dem Originalprogramm zu tun.
- Casts unnötig
- Volatile unnötig
Vorweg: Auch der Cast in der Funktion:
1
uint8tx_value=*(uint8*)pValue;
ist unnötig, da pValue schon uint8 ist. Aber in anderen cases ist es ein
uint32 oder uint16 eingepackt und so bleibt halt das Cast, um den
Quellcode einheitlich zu strukturieren.
Aber das hat IMO rein gar nichts mit dem Problem zu tun.
Dann bleibt wohl nur noch, daß jemand mit der entsprechenden
Compilerversion compiliert und das Assemblerlisting anhängt.
Etwas noch zu dem Code:
Ich bevorzuge generell, daß die gewünschte Aktion zuerst steht, also:
@Peter
Ich würde für die äußeres if Abfrage einen else Zweig einführen, anstatt
das verschachtelte break zu benutzen. Warum? Wenn du an anderer Stelle
innenrhalb von switch/case eine for Schleife nutzt passt das nicht.
Teamcoder schrieb:> Wenn du an anderer Stelle> innenrhalb von switch/case eine for Schleife nutzt passt das nicht.
Das hat aber nichts mit dem if oder if/else zu tun.
In einer Schleife kannst Du generell kein übergeordnetes Case beenden.
Bestenfalls mit return oder goto rausspringen.
Mich hat die Doppelbelegung des break auch schon sehr oft gestört.
8051 hat weder CMP noch SUB Befehle und ist daher auf den SUBB Befehl
angewiesen. Daraus ergibt sich eine Optimierungsmöglichkeit, indem der
CLR C Befehl eingespart werden kann, wenn sich aus dem Kontext heraus
C=0 ergibt.
Wenn im nicht optimierten Code das CLR C drin steht, im optimierten aber
nicht, dann liegt nahe, dass der Optimizer im Ablauf des Codes an dieser
Stelle C=0 annimmt und deshalb den Befehl rauswirft. Die hier gezeigte
Stelle, an der der Bug sichtbar wird, wäre nur das Symptom des Bugs,
nicht eigentliche Ursache.
Ohne Kenntnis des Kontextes sitzt IAR also am falschen Ende vom Code,
weil sich aus dem Screenshot der Ablauf bis zu dieser Stelle nicht
sauber ablesen lässt. Um nicht nach einer Stecknadel im Heuhaufen zu
suchen, bräuchte man hier vorzugsweise einen den Fehler reproduzierenden
Quellcode. Möglicherweise würde auch ein Codeausschnitt in Quell- und
Assemblercode ausreichen, der zurück bis zu der Stelle geht, an der sich
im unoptimierten Code das entscheidende C=0 ergibt.
Nach einem "durch IAR in 10 min analysiert und behoben" Problem sieht es
mir auf Basis der vorliegenden Information also nicht aus. Wenn dieser
Fix nicht darin bestehen soll, diese Optimierung des C-Flags
provisorisch ganz abzuschalten.
Hallo Peter,
jor, finde ich persönlich auch besser.
Entwerder stammt die "Vorlage" aus dem Ti Beispiel oder vom
vorhergehendem Entwickler.
Will keiner mit IAR mal auf Mid/High compilieren?
Peter D. schrieb:> Teamcoder schrieb:> Wenn du an anderer Stelle> innenrhalb von switch/case eine for Schleife nutzt passt das nicht.>> Das hat aber nichts mit dem if oder if/else zu tun.> In einer Schleife kannst Du generell kein übergeordnetes Case beenden.> Bestenfalls mit return oder goto rausspringen.>> Mich hat die Doppelbelegung des break auch schon sehr oft gestört.
Das else ist hier die bessere Lösung! Verstehe es als Hinweis!
Da du es selbst ja auch so empfindest, solltest du es hier auch so
posten.
A. K. schrieb:> 8051 hat weder CMP noch SUB Befehle und ist daher auf den SUBB Befehl> angewiesen.
Zu Assembler-Zeiten hatte ich deshalb oft den CJNE-Befehl benutzt.
Er testet ja nicht nur auf Gleichheit, sondern setzt auch das Carry.
Ich hab den 8051 sehr bewundert wegen seinem sehr gut durchdachten
Befehlssatz. So knackig kompakte Programme habe ich bei keinem anderen
MC erlebt.
Heutzutage kann man ja mit Flash nur so um sich schmeißen, Kompaktheit
ist kein Thema mehr.
Als der AT90S2313 rauskam, hatte im mal versucht, AT89C2051 Programme zu
portieren. Absolut keine Chance, die haben alle den Flash gesprengt.
Der AT89C2051 werkelt immer noch in einigen Geräten und er scheint auch
nicht abgekündigt zu werden.
Teamcoder schrieb:> Da du es selbst ja auch so empfindest
Nö, wenn das if verlassen wird (break, return), spare ich mir das else.
Finde ich besser lesbar, man muß dann nicht mehr schauen, wie es nach
dem else weiter geht.
Peter D. schrieb:> Als der AT90S2313 rauskam, hatte im mal versucht, AT89C2051 Programme zu> portieren. Absolut keine Chance, die haben alle den Flash gesprengt.
Da hättest Du ein bißchen hartnäckiger sein sollen. Der Keil-Compiler
hat zwar schon immer guten Code erzeugt, aber am Ende klappte es mit IAR
und AVR ähnlich kompakt.
Letztlich war es die Pinkompabilität von ..2051 und ..2313, die einen
einfachen Umstieg ermöglicht hat. Einen ..2051 (bzw. 8031) habe ich
danach nie wieder benutzt ;-)
m.n. schrieb:> Letztlich war es die Pinkompabilität von ..2051 und ..2313, die einen> einfachen Umstieg ermöglicht hat.
Eben nicht, genau das war ja mein Irrtum.
Erst auf den ATtiny4313 konnte man AT89C2051 Code portieren, wenn er
schon >80% der 2kB belegte.
m.n. schrieb:> Da hättest Du ein bißchen hartnäckiger sein sollen.
Peter hat schon recht - mindestens im Rahmen seines auf 128/256 Bytes
begrenzten primären Datenadressraums ist 8051 hocheffizient beim
Platzbedarf. Das entspringt dem Zeitpunkt der Entwicklung. Damals war
das reichlich und Intel hatte erkennbar keine Architektur für Jahrzehnte
geplant (bei 8086 auch nicht ;-). Den vorgesehenen Nachfolger 8096 kennt
hingegen kein Schwein.
AVR ist schon aufgrund der aus 16-Bit Worten bestehenden Codierung bei
solchen Programmen weniger kompakt. Die Kehrseiten liegen in der bei AVR
einfacheren Umsetzbarkeit von C Code (lies: der Aufwand im Compiler ist
geringer) und dem einfacheren Ablauf der Befehlsverarbeitung. AVR war
als Ziel für Compiler konzipiert worden. Platz im ROM war dabei nicht
das vordringlichste Kriterium.
Es gibt natürlich Aufgaben, die AVR effizienter angehen kann.
Beispielsweise bei der Adressierung von RAM jenseits 256 Bytes und bei
Arithmetik ab 16 Bits. Aber bei RAM/ROM bis 256/4KB ist solcher Code
nicht allzu häufig. Wenn man mit Pointern nur 256 Bytes adressieren
muss, es sei denn es sind Tabellen im ROM, dann passt das zum 8051 sehr
gut. Jenseits davon wird es schon deutlich umständlicher.
A. K. schrieb:> Peter hat schon recht - mindestens im Rahmen seines auf 128/256 Bytes> begrenzten primären Datenadressraums ist 8051 hocheffizient beim> Platzbedarf.
Im Prinzip ja, wenn man vornehmlich mit Bitgeschichten programmiert hat.
Aber wie war es denn, wenn man noch ein EEPROM brauchte? Da brauchte man
noch Code für SPI oder IIC. Der ..2313 hatte schon ein EEPROM mit auf
dem Chip.
Und dann diese blöden Ausgänge, die im Grunde keine waren und bei RESET
immer schön '1'-Pegel geliefert haben ...
Egal ;-)
Was Atmel bei den AVRs blöderweise nicht eingebaut hat, sind die
Prioritäten für die Interrupts. Das nervt auch heute noch.
A. K. schrieb:> Den vorgesehenen Nachfolger 8096 kennt> hingegen kein Schwein.
Eine Zeit lang hatte ich den 80C166 als Nachfolger in Erwägung gezogen;
das wäre aber auch eine Sackgasse geworden.
m.n. schrieb:> Aber wie war es denn, wenn man noch ein EEPROM brauchte? Da brauchte man> noch Code für SPI oder IIC. Der ..2313 hatte schon ein EEPROM mit auf> dem Chip.
20 Jahre später ist man klüger. Zudem bezog ich mich auf die
Befehlssatz-Architektur, nicht auf das, was auf realen Chips an
Zusatzkomponenten drauf ist.
Klar. Wenn du Glück hast, dann hat der Ersatz-AVR alles drauf, was dem
51er fehlte, und was der umständlich in Software giessen musste. Oft
wirds aber anders ausfallen und es wurde ein 51er eingesetzt, der dem
Problem angemessen war und dem eben nicht die Hälfte fehlte. Dann bringt
es nichts, auf dem neueren AVR Zeug drauf zu haben, was man dafür nicht
braucht.
> Was Atmel bei den AVRs blöderweise nicht eingebaut hat, sind die> Prioritäten für die Interrupts. Das nervt auch heute noch.
Yep. 2 hätten völlig gereicht.
Peter D. schrieb:> Teamcoder schrieb:> Da du es selbst ja auch so empfindest>> Nö, wenn das if verlassen wird (break, return), spare ich mir das else.> Finde ich besser lesbar, man muß dann nicht mehr schauen, wie es nach> dem else weiter geht.
Und genau das ist der Irrtum. Wie beim sauberen Einrücken auch kann man
durch guten syle guide Fehler vermeiden. Um einem Dritten den Ablauf
schnell lesbar zu gestalten sollten mehrfache Ausgänge möglichst
vermieden werden. Bei einem geschachtelten break muss man ganz genau
hinschauen, ob es gewollt oder ein Fehler ist.
Die Zeit, den Code möglichst unleserlich zu gestalten, sind hält vorbei.
Du bist wahrscheinlich ein Einzelkämpfer an der Code Front, oder?
A. K. schrieb:> Oft wirds aber anders ausfallen und es wurde ein 51er eingesetzt, der dem> Problem angemessen war und dem eben nicht die Hälfte fehlte. Dann bringt> es nichts, auf dem neueren AVR Zeug drauf zu haben, was man dafür nicht> braucht.
Mir ist ein Projekt bekannt, bei dem ein Hersteller von
glasfaserbasierten Endoskopiesystemen jahrzehntelang einen 8051
einsetzte, um die Beleuchtung einzustellen, den Lüfter zu steuern und
die wenigen zugehörigen Bedienknöpfe abzufragen. Das funktionierte auch
wunderbar.
Und als dann ein neues System mit frontseitiger Kamera und Mikrofon
entwickelt wurde, sollte der alte 8051 plötzlich auch noch die Audio-
und Videoverarbeitung durchführen. Der Einsatz eines größeres Prozessor
war aber auch keinen Fall gestattet, denn er 8051 hätte sich ja schon
seit 20 Jahren bewährt. Die Entwickler bauten daher ein riesiges Grab an
Analogelektronik zusammen, mit denen ein paar Audio-Filterfunktionen
realisiert werden konnten, aber beim Kamerasignal war dann Schluss.
Andreas S. schrieb:> Und als dann ein neues System mit frontseitiger Kamera und Mikrofon> entwickelt wurde, sollte der alte 8051 plötzlich auch noch die Audio-> und Videoverarbeitung durchführen. Der Einsatz eines größeres Prozessor> war aber auch keinen Fall gestattet, denn er 8051 hätte sich ja schon> seit 20 Jahren bewährt.
Da mußt Du aber auch schreiben, wann das gewesen sein soll.
Vor fünf Jahren oder sogar vor 25 Jahren?
Was heutzutage von jedem Deppen zusammenklickbar zu sein scheint (;-),
war seinerzeit eine sehr anspruchsvolle Aufgabe, bei der auch andere
MCUs die Segel gestrichen hätten.
m.n. schrieb:> Da mußt Du aber auch schreiben, wann das gewesen sein soll.> Vor fünf Jahren oder sogar vor 25 Jahren?
Das war vor ca. acht Jahren. Ich hatte den Entwicklern damals den
Einsatz eines geeigneten DSPs empfohlen.
> Was heutzutage von jedem Deppen zusammenklickbar zu sein scheint (;-),> war seinerzeit eine sehr anspruchsvolle Aufgabe, bei der auch andere> MCUs die Segel gestrichen hätten.
Es gab damals schon wesentlich leistungfähigere CPUs. Ein Riesenproblem,
das die damaligen Entwickler aber auch nicht sehen wollten, bestand
darin, dass man mit fest eingestellten Filtern bei dieser Anwendung
natürlich keinen Blumentopf gewinnen konnte.
der Compiler schein das CJNE nicht sehr zu mögen. JZ dagegen schon.
Obwohl ich das einer der schönsten bedingten Sprungbefehle mit 3
möglichen Zielen ist. Sehr effektiv zu benutzen.
Na da ist doch ein Clear Carry in einer älteren Version!
So lange kann der Fehler also noch nicht bestehen...
Immer noch keine neue IAR Version...
Wäre schon mal interessant was so ein neuer Bug hinter den Kulissen
alles lostritt?! Wahrscheinlich aber auch eher unspektakulär.
VG Basti
Basti schrieb:> Na da ist doch ein Clear Carry in einer älteren Version!
Da hast Du recht.
Ein Listing, was wirklich den Fehler zeigt, haben wir immer noch nicht.
Moin,
ich hab wieder eine IAR Lizenz!
Der Beispielquellcode von oben, hat natürlich keinen Bug... War ja klar,
dass es schief geht, wenn man dazu genötigt wird es ohne Compiler
einzukürzen :-/
Unten im Blogpost ist die *.zip hinzugekommen:
https://sebastianfoerster86.wordpress.com/2016/02/13/3-2-computer-says-yes/
Gern dürfen Interessierte das ganze verifizieren.
VG
Basti
1. Der Test auf != 1 löscht nicht das Carry
2. Der Test auf <= 2 vertraut auf das Carry
3. Der Einsprung erfolgt aus der Funktion ?US_SWITCH_SPARSE, welche wohl
das Carry auch nicht löscht.
Erst die Summe dieser 3 Sachen bewirkt, daß auch ein Fehlerbild
auftritt.
Die ersten beiden könnte man leicht korrigieren:
Moin,
ich bin mal wieder auf die Idee gekommen nach dem Compiler-Release zu
schauen. Auf der IAR Seite gelangt man aber bei den Release Notes immer
nur auf die vom 9.30.1.
Der Link für "Latest release 8051" und dann "full release notes" ist
also seit nem Jahr falsch?!
Es gibt aber schon lange eine 9.30.2. Die Release Notes konnte ich mit
meiner Bugnummer ergoogeln:
http://supp.iar.com/FilesPublic/UPDINFO/010824/ew/doc/infocenter/icc8051.ENU.html
Der hier genannte Bug ist nun unter "Program Corrections" zu finden.
Wahrscheinlich hat IAR also doch "schnell" reagiert, nur die
Internetseite ist noch nicht auf dem neusten Stand?!
VG
Basti
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
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten