RS 232 Code für Mic rocontroller (GCC C ompiler)

Henry Kiefer schrieb:

Ich meine mal gelesen zu haben das die µC der Reihe AT90xxx recht empfindlich auf Störungen reagiert haben sollen. Mit den AtMega war das dann behoben.

Grüße Björn

absehbaren

wie ich oben schon schrieb=20

Haben sogar schon die PIC24

Setzt das voraus, dass alle Timer die gleichen Eigenschaften haben und zudem jeder alle Eigenschaften aufweist, die ein Timer nur haben kann, z.B. PWM, Input Catching, Komparator etc. ?=20

Ich fange gerade mit den PIC32 an, um das "sollte" in obiger =46ormulierung entfallen zu lassen. Gleiches gilt f=FCr das RTOS, das ich bisher nur in der Theorie kenne. Laut Microchip sind die Libraries von PIC24 und PIC32 kompatibel.

Die extensive Nutzung von define Schaltern ist in Microchips Libraries schon seit Urzeiten augenf=E4llig und ist mir dort zum ersten Mal begegnet. Am Anfang hat mich dieses Prinzip sehr verwirrt. aber inzwischen ist mir klar geworden, dass dies verm=F6ge ifdef ein probates Mittel ist, den Code f=FCr alle m=F6glichen Spezialf=E4lle zu flexibilisieren, und ihn dennoch effizient zu halten.=20

Zudem sind bei den neueren PICs die Peripheriebausteine auf die Pins routbar. Da Microchip nun auch mit der massiven Bewerbung der Nutzung von RTOSen begonnen hat, werte ich das Alles mal als Anzeichen daf=FCr, dass zumindest die PIC32 Libraries reentrant sind. Und wie ich Microchip kenne, werden sie uns das dann auch noch f=FCr die PIC24 unterschieben, nat=FCrlich mit einem define Schalter zu aktivieren, damit der alte Code auch weiter problemlos lauff=E4hig bleibt.=20

Was aber Maschinensteuerungen angeht, so ist mir das RTOS noch etwas suspekt. Ich hatte hier mal die Einrichtung eines Fremdmaschine, die uns auch mit einem Multitasking angek=FCndigt wurde. Trocken lief das Teil hervorragend. Aber unter mechanischer Belastung hatte der Techniker Tage mit wild umherschlingernden Schrittmotoren zu k=E4mpfen, die er erst einmal "in die richtige Priorit=E4t zueinander setzen" musste. Das hat ihm richtig teure Hardware kaputt gemacht. Man merkte, dass er nervlich total am Ende war und sogar Tr=E4nen in den Augen hatte. Um das Ganze nicht eskalieren zu lassen, musste ich ihm in dieser Situation unsere Schlipsfraktion von der Pelle zerren, damit er =FCberhaupt wieder Luft sch=F6pfen konnte.=20

Irgendwie hat sich mir dabei das Gef=FChl vermittelt, dass man mit einem RTOS nicht mehr nahe genug an die Hardware drankommt. Heute ist es schon zur Routine geworden, dass die Maschine alle paar Monate mal wieder einen nicht auffindbaren Aussetzer hat, was dann f=FCr den Maschinenf=FChrer eine komplette Neur=FCstung erforderlich macht.

Wenn mir also heute ein Prozessor leistungsm=E4=DFig =FCberfordert zu = sein scheint, setze ich lieber einen zweiten dazu. Da es hier nur Einzelst=FCcke oder Miniserien gibt, ist das kostenm=E4ssig vollkommen problemlos. Bei Massenfertigung ist das RTOS sicher ein geigneteres MIttel, weil es mehr Leistungsreserven aktivieren kann.=20

Joerg schrieb: [snip]

Ja, FreeDOS, kein MS-DOS. Das ist aber auch eher da drauf, weil in/aus einigen Ländern PCs ohne Betriebssystem nicht in-/exportiert werden dürfen.

Freedos rennt aber auch auf neuer Hardware, kann Netzwerk usw fast alle MS-DOS Programme rennen auch drauf.

Gruß Jan

Henry Kiefer schrieb:

=20

frag mal nach der Powershell ;)

Guido

Dell hat bei ein paar Precision Modellen ein gratis Downgrade auf XP dabei. Hier steht ein M4300 herum, der fühlt sich mit XP pudelwohl, und selbst für die ganz neuen M4400 gibts bei Dell XP-Treiber.

Wie es bei anderen Modellreihen aussieht weiß ich nicht, ich interessiere mich nur für schwarze Ziegelsteine ;-)

Schöne Grüße,

Robert

Ich habe mir dieser Tage ein ThinkPad gekauft, und dachte mir so, "naja, einmal mit Vista kann man es ja starten". Nach einer gefühlten Viertelstunde Rödelns ohne wirklichen Fortschritt habe ich es hart abgeschaltet, und dann XP installiert :-)

-ras

Paul Rosenschrieb: "

Liest sich, als seid ihr die ersten gewesen, die diese Fremdmaschine eingesetzt haben. Eine Maschine damit zu bewerben, dass da ein RTOS eingesetzt wird, halte ich übrigens für sinnfrei.

Dafür gibt es noch einige andere Gründe. In der Praxis werden ohne Einsatz eines RTOS häufig dessen Funktionen unbewußt nachgebildet und da habe ich schon viel schlecht gemachtes und fehlerhaftes sehen müssen. Da ist z.B. das Problem der Synchronisierung von asynchronen Ereignissen (Interrupts) auf die Hauptloop. Es müssen Verriegelungen eingebaut werden, wenn dort Daten ausgetauscht werden. Oder man baut einen FIFO auf, um Daten temporär zwischen zu speichern. Dann muss der Hauptloop noch irgendwie mitgeteilt werden, dass neue Daten angekommen sind. Damit hat man schon mal drei wesendliche Elemente (Semaphore,Queue,Event) die ein RTOS zur Verfügung stellt. Ein weiteres großes Thema ist die gesamte Zeitsteuerung. Das geht dann von simplen Polling (wir springen mal in jede Aufgabe und schauen, ob gerade was zu tun ist) bis zum aufwendig ausbalancierten Zeitscheiben-Modell. Letzteres skaliert ganz schlecht und läßt viel Prozessorleistung als ungenutzte Reserve liegen, weil man nicht wirklich immer genau feststellen kann, wie lange die Bearbeitung dauern wird, bzw immer die längstmögliche Abarbeitungsdauer betrachten muss. Richtig interessant wird es dann, wenn eine Aufgabe in der 1min Zeitscheibe gelegendlich länger in der Abarbeitung dauert, als die kleinste Zeitscheibe von z.B. 1ms. Da gibt es dann immer lustige Verrenkungen, oder es treten sporadische Fehler auf wie: "Warum geht die Uhranzeige nach 2 Tagen denn plötzlich ein paar Sekunden nach?" usw. Hinzu kommt, dass viele Aufgaben in der Abarbeitung warten müssen, bis Zeiten abgelaufen (delays), oder Ereignisse eingetreten sind. Ohne RTOS müssen dazu meist umfangreiche state-machines aufgebaut werden, was die Programmierung nicht gerade übersichtlicher macht. Bei einem RTOS kann man das in der Regel vermeiden, weil man vereinfacht schreiben kann:

{ :

mache_1(); // warten bis Lichtschranke triggert WaitOnEvent(LICHTSCHRANKE_A);

mache_2(); // 100ms warten Delay(100);

mache_3(); // warten auf TAstendruck oder Schlüssel gedreht WaitOnEvent(KEYPAD | SCHLUESSELSCHALTER);

: }

Dirk

Jein.

Probleme gibt es da gerne bei Microcontrollern mit Harvard-Architektur. Um Strings im Flash zu halten braucht man z.B. beim AVR-GCC das Makro 'PROGMEM' und wegen dem separaten Adressraum eigene libc-Routinen fuer Variablen im Flash:

------------------------------------------------- const char PROGMEM string[] = "BlaBlubb"; strncpy_P(message, string, n);

------------------------------------------------- Gut, 'PROGMEM' definiert man halt auf anderen Architekturen einfach anders, fuer die libc-Routine kann man einen Wrapper verwenden. Mit "Standard-C loest alle Probleme" im Sinn macht man aber vielleicht sowas:

------------------------------------------------- strncpy(message, "BlaBlubb", n);

------------------------------------------------- Das fuehrt dann in kuerzester Zeit zum RAM-Overflow (und kommt ggf. recht haeufig im Code vor, ist also muehsam hinterher zu aendern).

Micha

"Michael Baeuerle" schrieb im Newsbeitrag news: snipped-for-privacy@micha.freeshell.org...

Sorry, PROGMEM ist nur ein Artefakt, weil der Compiler-Schreiber nicht schlau genug war, einen ausreichend ausgefeilten Compiler zu erstellen, der detektiert, dass "BlaBlubb" nie modifiziert wird.

Wieder jein. Das eigentliche Problem ist, dass C selbst dafuer nicht ausgelegt ist. Sicher koennte ein Compiler pruefen ob der String modifiziert wird, aber was soll er dann tun? Die Variable einfach ins Flash verfrachten reicht ja nicht, da der Pointer damit in einen anderen Adressraum wandert. Das 'strncpy()' aus der libc wuerde dann nicht mehr tun was es soll, da es nur mit RAM-Pointern umgehen kann. Automatische Pruefungen in allen Bibliotheken wuerden aber die Performance kaputtmachen. Den Compiler jetzt auch noch die libc-Aufrufe - und damit den Sourcecode - modifizieren zu lassen waere "boese". Dabei koennen Sachen entstehen die der Programmierer nicht gewollt hat (man will ja nicht immer auf RAM-Verbrauch optimieren, andersrum ist es naemlich signifikant schneller).

IMHO ist es so wie es momentan gemacht wird schon das kleinste Uebel. Im uebrigen macht es nicht nur der GCC so, sondern auch der EWAVR von IAR (siehe Handbuch S. 207: Extended keyword "__flash") der vierstellige EUR kostet ...

Micha

Stimmt, mein Vorschlag mit der 8-fachen Abtastgeschwindigkeit war da etwas übertrieben. Der einzige Nachteil ist, dass der zulässige Geschwindigkeitsfehler des Senders reduziert ist, 2% statt 5%, aber das sollte in der Regel kein Problem sein.

Damit hätte man dann ca. 34us zur Verfügung. Bei 125 ns Befehlsausführungszeit wäre dann Zeit für 272 einfache CPU Komandos, je Kanal also ca. 50. Das müsste zum Einlesen eines Bits und in ein Register schieben dicke ausreichen.

Gruß

Stefan DF9BI

Gerade das w=E4re nat=FCrlich eine gro=DFe Erleichterung. Bei der Standardmethode muss man jeden Delay identifizieren k=F6nnen, weil ja mehrere davon parallel auftreten k=F6nnen. Man kann also keine Funktion Delay(100) nehmen und diese mehrfach aufrufen. Es muss jedesmal eine echte Kopie hergestellt werden. Um nun jede der Kopien eindeutig zu identifizieren, kann man die delays entweder numerieren (array) oder man nimmt eine verkettete Liste von delays. Letztere ist zwar vom Handling her angenehm. Nachteil ist, dass die Verwaltung zur Laufzeit stattfindet, was f=FCr Microcontroller nicht zu empfehlen ist.=20

Packt man die delays in ein Array, so muss man jedes numerieren, also Delay1, Delay2 ... Vorteil der Methode ist, dass jetzt die Verwaltung der Delays nicht mehr zur Laufzeit, sondern zur Compilerzeit geschieht. Denn sp=E4testens dann steht ja fest, wieviele delay man ben=F6tigt. Die Anzahl der ben=F6tigten delays schwankt aber von Programm zu Programm. Auch in der Coding-Phase schwankt deren Anzahl. Es fallen einige Delays raus und andere kommen hinzu. Man muss also f=FCr jeden neuen Delay schauen, ob noch eine Nummer frei ist. Am Ende hat man dann L=F6cher in der Numerierung. Krasses Beispiel: Es existiert Delay0 und Delay50 und alle dazwischen sind tote Speicherplatzfresser.

Man muss also nach jeder L=F6schung eines Delays das komplette Programm von Hand durchk=E4mmen und die Delays neu numerieren. Und ich habe noch keine M=F6glichkeit gefunden, mit dem Preprozessor diese Delays zu "z=E4hlen" und neu "durchzunumerieren". so dass jedes Element des Arrays auch einen tats=E4chlichen vorhandenen Delay tr=E4gt und kein Numerierungsloch ist. Die einzige m=F6gliche Methode w=E4re die oben genannte der verkettetenden Liste mit dem Riesennachteil, dass jetzt die Verwaltung zur Laufzeit des Programms bew=E4ltigt werden muss.

Wenn mit RTOS jeder delay in den Prozess eingetragen werden kann, w=E4re er hiermit diesem schon eindeutig zugeordnet und das Problem der Identifizierung w=E4re gel=F6st.

Ohne den ganzen Thread zu lesen und evtl. OT:

Bei RS232 ist ein Baudratenfehler von 3 1/8 % zugelassen, da hängste mit

Saludos Wolfgang

So in der Art. Man floesse sich vorher kurz den Abschnitt "Oscillator & Magic Quartz Crystal Values: ein :-)

Das sehe ich genauso. Sobald man ein bisschen mehr braucht ist man bei den 51er genauso Singlesource. Und einen Standard 51er moechte ich wirklich nicht mehr benutzen. Sonst kommt das noch soweit das ich einen zweite RS232 selber programmieren muss. :-)

Olaf

"Michael Baeuerle" schrieb im Newsbeitrag news: snipped-for-privacy@micha.freeshell.org...

Das ist aber auch der einzige Grund. Technisch ist es kein Problem, dass der Maschinencode zur Laufzeit alle Pointer prueft, ob sie in Programm oder Datenspeicher zeigen, wenn man einen Teil des Programmspeichers fuer konstante Daten verwendet. Also voellig transparent unterhalb der C-Sprachebene, ein

Damit die Performance dann nicht schlimm wird, stehen beliebige Optimierungsmoeglichkeiten zur Verfuegung, die man nur nutzen muss, vorderhand durch Datenflussanlayse entscheiden wo dieser Code nicht notwendig ist.

Es ist die Frage, welcher Philosophe der Compilerschreiber anhaengt: Korrekte Implementation der Sprache, oder plattformspezifische Erweiterungen an moeglichst notwendiger Stelle unterschieben damit der Kunde nicht wechseln kann.

Die braucht man bei vielen Apps nicht. Unser Pellet-Ofen kommt z.B. ganz gut ohne aus :-)

Dafuer hat sich das Dingen letztens bei 40C mal wieder von selber eingeschaltet. War ihm wohl zu kuehl. Sieht nach einem klaren Fall fuer den Burggraben aus. Wundert mich aber nicht, denn ich hatte denen schon eine kleine Nachhilfe in Waermelehre (!) geben muessen. Fuehler sass an voellig verkehrter Stelle.

Dann müsste der C-Compiler obiges erstmal zu zwei Fallunterscheidungen übersetzen, was man aus gutem Grund nicht will.

Das wäre fast schon so, als würde man statt Code für den entsprechenden Harvard-Prozessor Code für einen darauf emulierten von-Neumann-Prozessor bauen. Und wie wir alle wissen, heißt "emulieren" = "langsam", und Rechenleistung hat man gerade auf den kleinen Controllern, die ROM und RAM unterscheiden, eher selten übrig.

In der überwiegenden Zahl der Fälle ist das vor allem nicht entscheidbar. Eine Routine wie 'strcmp' muss mit allen vier Kombinationen aus RAM/ROM-Zeigern klarkommen. Die wenigsten Compiler werden in der Lage sein, aus dem in C aufgeschriebenen 'strcmp' alle vier Versionen zu generieren und vorzuhalten. Das kostet nämlich ROM.

Ein "für C optimierter" Prozessor macht die nötige Fallunterscheidung im Mikrocode. Das kostet natürlich wieder eine Handvoll Transistoren und bedingt größere Adressregisterbreiten. Und wenn man die Vorteile der Harvard-Architektur ausnutzen will, also z.B. einen Zugriff auf dein ROM, einen auf den X-RAM und einen auf den Y-RAM gleichzeitig, braucht man gleich noch Logik, die solche Parallelbefehle gegebenenfalls auftrennt, weil man den Befehlen nicht mehr ansieht, welcher Teil auf welchen Speicherbereich zugreift.

Stefan

#define DELAY_TASTATURABFRAGE delay01 #define DELAY_SERPORTBANGING delay02 #define DELAY_USENETLESEN delay03 #define DELAY_WICHTIGPIEPSEN delay04 #define DELAY_ANZAHL 4

Wenn DU nun DELAY_SERPORTBANGING nicht mehr nutzt, ersetzt Du ihn durch DELAY_WICHTIGPIEPSEN, verminderst DELAY_ANZAHL und läßt delay04 weg.

Gleichzeitig mußt Du Dir die Zuordnung der Nummer zur Bedeutung nicht mehr merken.