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

Man bräuchte nur einen Interrupt, der Rest geht dann mit ein wenig bitschieben und rechnen. Wenn man einen schön fetten ARM Controller nimmt, z.B. aus der STM32-Serie mit 72 MHz (was bei ARM fast 72 MIPS heisst) für relativ wenig Geld, dann kann man auch Mehrfach-Oversampling einbauen, um Glitches zu unterdrücken usw. und das ganze problemlos ohne Assembler in C implementieren, und der Chip kocht dir noch nebenbei Kaffee :-)

Kommt auf die Anwendung drauf an. Wenn die Messgeräte immer nur auf Anfrage eine maximale Anzahl Bytes senden, kann es zu keinen Problemen kommen. Dann im Interrupt den FIFO vollschreiben und im Hauptprogramm oder langsameren Interrupts in Ruhe auswerten. Die nächste Messanforderung erst nach Auswertung der letzten Antwort senden.

Und das FIFO nicht so benutzen wie Politiker ein Budget: Wir schreiben jetzt erstmal einfach alles rein und spaeter sehen wir dann, wie wir da wieder rauskommen. Jedesmal wenn niemand guckt machen wir das FIFO ein wenig groesser. Und wenn's nicht klappt, mit viel Glueck ist die Amtsperiode vor dem grossen Knall ja schon um ... :-)

Ich meinte eher die HW-FIFOs in UARTs. Ein selbst implementiertes ist natürlich etwas anderes. Da kann man ohne weiteres 67 Bytes vorsehen, die alle Möglichkeiten abdecken.

Guter Plan ;-)

Falk

Ist klar. Bei quasi Einzelstückzahlen und einer Entwicklerstunde von 60-80¤ (=12-16 von diesen Teilen) muß man halt rechnen, was günstiger kommt. Bei den maximal 5 Geräten und mindestens zwei gesparten Entwicklerstunden lohnt sichs.

Ich hätte dafür vielleicht gleich einen Atmega 640 mit vier HW-Uarts genommen und den 5. per Software dazugebastelt. Da der OP aber eher Microchip-affin ist, habe ich mir das jetzt verkniffen.

Mit freundlichen Grüßen

Frank-Christian Krügel

Frank-Christian Kruegel schrieb: ...

Kann es sein, daß zwischen PIC- und AVR-Fans ein Glaubenskrieg herrscht, wie zwischen Windows/Linux, Atari/Amiga, ESL/Glühlampe oder Kienspan/Öllampe?

Falk

Moin, sollte gehen, da gibt es ja von Microchip ne Uralte Application-Note (ich glaube AN555) die eine Softwareimplementierung einer Seriellen Schnittstelle beschreibt. musste halt auf C portieren, sollte allerdinx kein Problem sien...

Für den Baudrategenerator kannste einfach einen der Timer Opfern. Ist meiner EInschätzung nach eher Fleissarbeit.

Gruss Jochen

Paul Rosen schrieb:

Wird der so heiss dabei?SCNR, Holger

Fast, es geht eher um PIC gegen den Rest der Welt. :-)

Obwohl mich das eigentlich wundert. Da ja heutzutage sowieso jeder in C programmiert ist es ja eigentlich egal wie schlimm der Unterbau ist.

Olaf

Bei 72 MHz braucht der maximal 70 mA bei 3,3 V, wenn alle Hardware in Betrieb ist, oder 37 mA, wenn alles deaktiviert ist (UART usw.). Für ein Puppenhaustässchen reicht das vielleicht zum Warmhalten :-)

Aber bei einem Kunden hatte ich mal erzählt, was man mit einer Platform von denen alles per Software noch machen könnte, bis dann einer fragte, ob die auch Kaffee kochen könne. Ich meinte dann, wenn noch mehr Hardware-Features in die Kiste gequetscht werden, dann wäre das durchaus möglich. Musste schließlich ein Lüfter eingebaut werden, der aber zumindest per Software temperaturgeregelt läuft.

Fast. Die Entwicklungsumgebung ist meist anders, der C-Code inkompatibel. Der Controller besitzt völlig unterschiedliche Peripherie.

Eigentlich kann man jedesmal von Vorne anfangen.

- Henry

In article , Falk Willberg writes: |> |> Kann es sein, daß zwischen PIC- und AVR-Fans ein Glaubenskrieg herrscht, |> wie zwischen Windows/Linux, Atari/Amiga, ESL/Glühlampe oder |> Kienspan/Öllampe?

Du hast C64/Spectrum vergessen.

Wobei die ursprüngliche PIC-Architektur auch etwas ist, was eigentlich längst hätte aussterben sollen. Aus reinen Kostengründen hält sich die aber ebenso hartnäckig wie 8051.

Rainer

Der C-Code ist kompatibel, wenn man bei Standard C bleibt. Hardwarespezifisches fasst man ja sowieso immer schön sauber getrennt vom Rest in eigenen Dateien zusammen, mit klar definiertem Interface, sodaß man leicht wechseln kann. Ich habe z.B. für eine Entwicklung mit einem HCS08 die gesamte Logik per Visual C übersetzen und in einem Windows-Programm laufen lassen können und dort die Hardwareaufrufe simuliert. Derselbe Quelltext konnte problemlos auch für den Microcontroller übersetzt werden.

herrscht,

Der war gut :o) im Ernst: Es ist nun mal so, dass hier jetzt die Entwicklungsumgebung f=FCr die Teile vorhanden ist. F=FCr alle absehbaren Probleme gibt es fertige Libraries von Microchip bzw habe ich mir die selbst zusammengebaut. Diese sollten auch weitestgehend auf dem 32 Bit PIC32 laufen. Alle diese kann ich auf dem Prozessor zusammenlinken, was h=E4ufig nicht der Fall ist, wenn diese von verschiedenen Herstellern kommen, weil sie beispielweise alle denselben Timer f=FCr sich beanspruchen. Zudem gibt es inzwischen einen flexiblen Hardware Baukasten, der auch f=FCr die PIC32 funktionieren sollte.=20

Hier gibt es aus Fremdger=E4ten schon jetzt zig SPS und Controller, teilweise aus fr=FChen DOSzeiten, mit denen ich mich rumschlagen muss. Und wenn dann alle paar Jahre mal eine St=F6rung oder =C4nderung kommt, muss man sich erstmal wieder (oft genug in der Freizeit) da erst mal wieder reinknien. Ich brauche Euch sicher nicht zu erz=E4hlen, wieviel Arbeit das ist f=FCr so wenig Effekt.=20

Es war also wichtig, sich zumindest f=FCr die n=E4chste Zeit und f=FCr = die neue Prozessorgeneration auf ein System festzulegen. Es sollen ja zumindest f=FCr die Wartung, auch andere eingearbeitet werden, die nicht bereit sind, sich zuhause immer wieder neue alte Systeme reinzupfeifen. Und da war eben die St=F6rsicherheit auch in rauher Umgebung, als auch die L=F6sung aus einer Hand f=FCr mich = ausschlaggebend. Die Dinger f=FCnktionieren noch in gemeiner Prozessumgebung, wenn andere (auch eine namhafte SPS) die L=F6ffel abgeben. Das ist zumindest der Vorteil gewesen, den ich aus der Konfrontation mit vielen Systemen ziehen konnte. Wenn es jetzt AVR uder sonstwer gewesen w=E4re, der beim Auswahlprozess das Rennen gemacht h=E4tte, w=E4re ich jetzt eben ein J=FCnger dessen.=20

Wenn man ein ordentlicher, sauber denkender Mensch ist, ja.

- Henry

Peripherie.

getrennt vom

soda=DF man

HCS08

Windows-Programm

Derselbe

werden.

Das Hauptproblem ist IMHO bei den Microcontrollern die Verschiedenheit der Peripherie und insbesondere der Kampfer um die Timer. Hast Du zwei Bibliotheken, die beide denselben Timer beanspruchen, gibt es Probleme. Es ist hier also wichtig, eine zentrale Delaybibliothek mit m=F6glichst kleiner Zeiteinheit zu haben, die mehrere Delays parallel erzeugen kann und die dann konsequent von allen anderen Bibliotheken genutzt wird. Es darf nicht jede Ihr eigenes S=FCppchen kochen.

Das klingt vernuenftig. Wobei man selbst bei Entwicklern von SPS nicht immer, ahem, wie soll ich's hoeflich sagen, Erfahrung in Sachen Stoersicherheit erwarten sollte. Ich hatte mal eine Steuerungsgeschichte mit MSP hier, da ist mir echt uebel geworden. Nach einigen Aenderungen verhaelt sich das Dingen bis jetzt robust.

eigentlich l=E4ngst

aber ebenso

Die 8-bitter PIC haben eben unter den Bastlern einen gewissen Ruhm erlangt oder eben auch Spukreflexe erzeugt. Diese alte Rivalit=E4t h=E4lt sich bis heute. Und auch die bekannten deutschen Vollsortimenter haben auch fast nur diesen alten Ramsch vorr=E4tig. Reichelt hat sogar noch die alten ohne Flash massenhaft im Angebot, w=E4hrend bei den Massenproduzenten derzeit schon der Umstieg von 16 auf 32 Bit im Gange ist. Irgendwie haben sie dort die Entwicklung verschlafen.