Harry,
Papier ist geduldig und schreiben kann der viel.
Ausserdem hat er den Compiler bestimmt nicht aus eigener Kasse finanziert.
Erinnere dich mal zurück:
wieviel Zeit haben denn wir mit der Demo/Mega8 Version getestet, bis wir
die Vorteile vom AVRco und den wahren Wert erkannt haben? Und wir kamen
fast alle von Turbo Pascal.
An alle die es interessiert hier die original Mail vom 3.11.2017
Hallo Herr Hofmann,
das mitgelieferte USB Kabel ist ein zweipoliges Ladekabel, ich habe ein vollwertiges in die Rücksendung beigelegt.
Auch unter <AVRco samples> erfährt man keine Details, ist wohl Geschmackssache.
Ich habe gestern in einer sehr langen Schicht den kompletten Pascal Source Code in C umgeschrieben. Der Patient
läuft jetzt stabil.
Hier mal ein Vergleich von Avrco 5.09 Pascal zu C:
Quellcode Pascal: ca. 525 Zeilen Quellcode C incl. neu geschriebener Funktionen: 465 Zeilen
Headerdatei: 101 Zeilen
Resourcenverbrauch Program Memory: 11 KB mit Optimierung : 4876 Bytes
RAM: 1004 Bytes : 273 Bytes
Da die mit Avrco Version 5.09 compilierte Version nicht stabil läuft habe ich für den Geschwindigkeitsvergleich das alte
mit Ver. 2.80 erstellte HEX File benutzt.
Laufzeit im Durchschnitt: 49 msec C-Version: 18 msec
Der Prozessor läuft jetzt überwiegend im SLEEP Mode.
Danke dass sie die E-mail gleich in Ihr Forum gestellt haben und damit den Blutdruck ihrer Gemeinde gesteigert haben.
Wenn Sie schon so offen sind sollten sie diese mail auch gleich veröffentlichen, natürlich ohne Namen !!!
Grüße und ein schönes Wochenende...
Harry
Moderator
Gender: Location: zwischen Augsburg und Ulm Age: 59 Posts: 2132 Registered: 03 / 2003
da keiner von uns das Programm kennt, kann auch keiner sagen, was da passiert ist. Ich glaube aber, daß keiner von uns instabile Programme kennt, die mit AVRCo geschrieben wurden ...... außer man hat irgendwie Mist gebaut .
...
da keiner von uns das Programm kennt, kann auch keiner sagen, was da passiert ist. Ich glaube aber, daß keiner von uns instabile Programme kennt, die mit AVRCo geschrieben wurden ...... außer man hat irgendwie Mist gebaut .
...
Ich kann mir schon vorstellen was mit einem Anfänger passiert ist, der sich nicht ein bisschen in die Dokus und Samples eingearbeitet hat. Ich denke der Stack dürfte das Hauptproblem für ein instabiles System gewesen sein Aber ohne Einarbeitung ein Task-System aufzusetzen und behaupten dies in C (LACH) erstellt zu haben. Sagt alles aus. Wahrscheinlich (Typisch C) viel zu wenig Fehlerabfragen, dann kann man auch Geschwindigkeit und Speicher sparen. Aber auf keinen Fall bekommt das Tasksystem Jemand in so kurzer Zeit hin. Dann kann er auch gleich seinen eigenen Compiler schreiben :3some:
Und wie Harry schon geschrieben hat, man kann viel behaupten. Ich bin mir aber zu 100% sicher, jeder der schon ein paar Jahre mit den AVRCO-Tools arbeitet, hätte damit wenig oder gar keine Probleme gehabt. Man kann nicht erwarten gleich das perfekte Programm mit irgendeiner Programmierumgebung beim 1. Projekt hinzubekommen. Das geht mit keiner Programmiersprache, bei allen muß man sich einarbeiten. Wer dazu nicht bereit ist, hat KEINE AHNUNG und davon eine ganze Menge.
Viele von unseren Steuerungen laufen jetzt seit über 5 Jahren mit dem AVRco, tauschen Daten über MODBUS in Sekunden aus. Laufen 365 Tage / 24h im Jahr, im Außenbereich bei Temperaturen von -25 bis +65 C ohne auch nur ein einziges mal einen Neustart wegen Hängern zu haben. Da wir in allen unseren Steuerungen die Neustarts / Watchdogauslösungen protokollieren. Und wir haben einige Systeme die einen sehr hohen Anspruch im Bezug auf Sicherheit haben.
Ich selbst schreibe in beiden Sprachen dh. im AVRco und im AVRStudio und kann mit Erfahrung behaupten, das dieses Aussagen eines C-Blinden sind.
Bis ein Prog in C erst einmal läuft ist ein langer Weg. Das geht im AVRco wesentlich schneller.
Daß das Studio einen effizienteren Code erzeugt ist keine Frage. Aber kommt es auf die letzten paar Bytes an ? Der AVRco ist auf Sicherheit und Benutzerfreundlichkeit gebaut und da ist das Studio Meilen von entfernt.
Note due to EU Cookie Law This page uses cookies to handle logins and unread markers. If you use this forum you allow that this page is storing cookies on your computer. To remove Cookies from this site just click on "Delete cookies of this forum" on the bottom of the page. You can find more infos in our Cookie Policy.