Announcement: there is an English version of this forum on 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
Vorschlag für den allgemeinen Frieden: Basti lädt das angesprochene Minimalbeispiel hoch, mit dem das Phänomen nachvollziehbar ist.
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.
Nun, um das Problem nachzustellen, sollte ja auch die Kickstarter-Version ausreichen. Oder?
Denk' schon, schrieb ich ja schon oben.
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
Hmm. Das hier kommt mir etwas merkwürdig vor, auch wenn es mit dem eigentlichen Problem wahrscheinlich nichts zu tun hat:
1 | int main(void) |
2 | {
|
3 | volatile gattAttribute_t att; |
4 | volatile uint8 value = 2; |
5 | |
6 | // ...
|
7 | |
8 | WriteAttrCB( 0, (gattAttribute_t*)&att, (uint8*)&value, len, offset, method ); |
9 | }
|
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 | uint8 tx_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:
1 | case 0xFFF4: |
2 | if ( len == 1 ) |
3 | {
|
4 | uint8 tx_value = *(uint8*)pValue; |
5 | if( tx_value <= 0x02 ) { |
6 | notifyApp = 3; |
7 | }
|
8 | else
|
9 | {
|
10 | status = 0x80; |
11 | }
|
12 | break; |
13 | }
|
14 | status = 0x0d; |
15 | break; |
@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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
hier mal das listing mit dem IAR-8051 8.10.3 für medium Optimierung. High macht keinen Sinn, da bleibt bei dem Code nichts über.
Steffen H. schrieb: > hier mal das listing mit dem IAR
1 | 64 if ( len != 1 ) |
2 | \ 00004E 7401 MOV A,#0x1 |
3 | \ 000050 6D XRL A,R5 |
4 | \ 000051 6004 JZ ??WriteAttrCB_6 |
Na prima, das Carry wird also von viel weiter vorne übernommen. Wenn man sich das CLR C sparen will, warum dann nicht:
1 | MOV A, R5 |
2 | ADD A, #-1 |
3 | JZ ??WriteAttrCB_6 |
Ich hätte als Optimizer allerdings if/else vertauscht und einfach
1 | CJNE R5, #1, ??WriteAttrCB_6 |
genommen.
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.
@Peter Dannegger nur zu, noch scheint es nur den 9.30.1 auf der IAR Seite zu geben. ;) Obwohl mir bis Ende Februar eine 9.30.2 "versprochen" wurde.
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:
1 | 119 if ( len != 1 ) |
2 | \ ??Profile_WriteAttrCB_8: |
3 | \ 000095 7401 MOV A,#0x1 ; besser: CJNE R5, #1, ??Profile_WriteAttrCB_16 |
4 | \ 000097 6D XRL A,R5 ; |
5 | \ 000098 7050 JNZ ??Profile_WriteAttrCB_16 ; |
6 | 120 { |
7 | 121 status = 0x0d; |
8 | 122 } |
9 | 123 else |
10 | 124 { |
11 | 125 uint8 tx_value = *(uint8*)pValue; |
12 | 126 if( tx_value <= 0x02 ) { |
13 | \ 00009A EC MOV A,R4 |
14 | \ 00009B F8 MOV R0,A |
15 | \ 00009C E6 MOV A,@R0 |
16 | \ 00009D 9403 SUBB A,#0x3 ; besser: ADD A, #-3 |
17 | \ 00009F 5016 JNC ??Profile_WriteAttrCB_18 ; JC ??Profile_WriteAttrCB_18 |
Eine Subtraktion entspricht der Addition des Komplements mit Invertierung des Carry-Flags.
So einfach scheint es nicht zu sein. Ich sehe noch immer kein Fix auf der IAR Seite... vielleicht bin ich auch nur zu Blind...
@Steffen H. Könntest du es noch mal mit deiner älteren Version gegenprüfen?
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
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.