mikrocontroller.net

Forum: Compiler & IDEs IAR (8051) immer noch mit Bug


Autor: Basti (Gast)
Datum:

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

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

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Und hast Du IAR deswegen kontaktiert?

Autor: Bernd K. (prof7bit)
Datum:

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

Autor: Basti (Gast)
Datum:

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

Autor: Basti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mahlen die Mühlen natürlich :D

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja. Kannst Du denn das Problem aus Deiner speziellen Software-Umgebung 
herauslösen und ein übersetzbares Minimal-Beispiel konstruieren, das 
diesen Fehler ebenfalls provoziert?

Autor: Bernd K. (prof7bit)
Datum:

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

Autor: Basti (Gast)
Datum:

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

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Basti schrieb:
> https://sebastianfoerster86.wordpress.com/2016/02/...

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.

Autor: Basti (Gast)
Datum:

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

Autor: gnuopfer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 :-)

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Basti (Gast)
Datum:

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

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

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

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Basti (Gast)
Datum:

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

Autor: Peter D. (peda)
Datum:

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

Autor: Basti (Gast)
Datum:

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

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Vorschlag für den allgemeinen Frieden:

Basti lädt das angesprochene Minimalbeispiel hoch, mit dem das 
Phänomen nachvollziehbar ist.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Nun, um das Problem nachzustellen, sollte ja auch die 
Kickstarter-Version ausreichen. Oder?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Denk' schon, schrieb ich ja schon oben.

Autor: Basti (Gast)
Datum:
Angehängte Dateien:

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

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hmm.

Das hier kommt mir etwas merkwürdig vor, auch wenn es mit dem 
eigentlichen Problem wahrscheinlich nichts zu tun hat:

int main(void)
{
  volatile gattAttribute_t att;
  volatile uint8 value = 2;

  // ...

  WriteAttrCB( 0, (gattAttribute_t*)&att, (uint8*)&value, len, offset, method );
}

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?

Autor: Basti (Gast)
Datum:

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

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
      case 0xFFF4:
         if ( len == 1 )
         {
           uint8 tx_value = *(uint8*)pValue;
           if( tx_value <= 0x02 ) {
             notifyApp = 3;
           }
           else 
           {
             status = 0x80;
           }
           break;
         }
         status = 0x0d;
         break;

Autor: Teamcoder (Gast)
Datum:

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

Autor: Peter D. (peda)
Datum:

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Basti (Gast)
Datum:

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

Autor: Teamcoder (Gast)
Datum:

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

Autor: Peter D. (peda)
Datum:

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

Autor: Peter D. (peda)
Datum:

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

Autor: m.n. (Gast)
Datum:

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

Autor: Peter D. (peda)
Datum:

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: m.n. (Gast)
Datum:

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

Autor: A. K. (prx)
Datum:

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

Autor: Teamcoder (Gast)
Datum:

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

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

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

Autor: m.n. (Gast)
Datum:

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

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

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

Autor: Steffen H. (Firma: www.shotech.de) (mc_sho) Benutzerseite
Datum:
Angehängte Dateien:

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

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steffen H. schrieb:
> hier mal das listing mit dem IAR
     64                   if ( len != 1 )
   \   00004E   7401         MOV     A,#0x1
   \   000050   6D           XRL     A,R5
   \   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:
MOV     A, R5
ADD     A, #-1
JZ      ??WriteAttrCB_6

Ich hätte als Optimizer allerdings if/else vertauscht und einfach
CJNE    R5, #1, ??WriteAttrCB_6
genommen.

Autor: Stephan H. (stephan-)
Datum:

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

Autor: Basti (Gast)
Datum:

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

Autor: Peter D. (peda)
Datum:

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

Autor: Basti (Gast)
Datum:

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

Autor: Basti (Gast)
Datum:

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

Gern dürfen Interessierte das ganze verifizieren.

VG

Basti

Autor: Peter D. (peda)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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:
    119                   if ( len != 1 )
   \                     ??Profile_WriteAttrCB_8:
   \   000095   7401         MOV     A,#0x1                   ; besser: CJNE R5, #1, ??Profile_WriteAttrCB_16
   \   000097   6D           XRL     A,R5                     ;
   \   000098   7050         JNZ     ??Profile_WriteAttrCB_16 ;
    120                   {
    121                     status = 0x0d;
    122                   }
    123                   else
    124                   {
    125                     uint8 tx_value = *(uint8*)pValue;
    126                     if( tx_value <= 0x02 ) {
   \   00009A   EC           MOV     A,R4
   \   00009B   F8           MOV     R0,A
   \   00009C   E6           MOV     A,@R0
   \   00009D   9403         SUBB    A,#0x3                   ; besser: ADD A, #-3
   \   00009F   5016         JNC     ??Profile_WriteAttrCB_18 ;         JC ??Profile_WriteAttrCB_18

Eine Subtraktion entspricht der Addition des Komplements mit 
Invertierung des Carry-Flags.

Autor: Basti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So einfach scheint es nicht zu sein. Ich sehe noch immer kein Fix auf 
der IAR Seite... vielleicht bin ich auch nur zu Blind...

Autor: Basti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Steffen H.

Könntest du es noch mal mit deiner älteren Version gegenprüfen?

Autor: Basti (Gast)
Datum:

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

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

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.