Sprachen für Microcontroller

Hans-Peter Diettrich :

C, C und nochmals C, bzw. auch aufgebohrt als C++

finden. In kleinen uC's brauchst Du nur selten ein spezielles Multitaskingechtzeitbetriebssystem; da kann mal viel von den Echtzeitanforderungen einfach mit der Peripherie (und Interrupts) abwickeln.

M.

Am 17.03.2015 um 05:16 schrieb Hans-Peter Diettrich:

Eigentlich nur C...

Am 17.03.2015 um 09:18 schrieb Matthias Weingart:

Oh, da war jemand schneller ;-)

Am 17.03.2015 um 05:16 schrieb Hans-Peter Diettrich:

Die Kollegen Matthias und Eric haben schon geschrieben, C. Assembler

wenn es optimiert werden MUSS.

Java gepaart mit C# auf dem Host kreiert ein Echt Zeit System. Die Leute wundern sich dann, warum ein Raspy so lahm ist.

Waldemar

news: snipped-for-privacy@mid.individual.net...

bestimme ich und nicht der Markt, so wie alle anderen Sachen auch!

Gruss Chregu

Am 17.03.2015 um 11:16 schrieb snipped-for-privacy@vtxmail.ch:

ja - und nun?

Und das hat jetzt mit der Frage des OP was zu tun?

Wenn du Java als Kandidat ansiehst, kannst du auch C#, Pascal, Python und Javascript als Kandidaten ansehen. Kandidaten sind ja bekanntlich

Kommt drauf an, wo du die Grenzen ziehst. TI liefert zu ihrem Code Composer ein System namens SYSBIOS dazu, was ich durchaus als RTOS

Threads, Timer, ein wenig Kommunikation, etc.

Stefan

Waldemar schrieb:

(Kollissions-Vermeidung...). Wenn ich mir dagegen heute das Herumgehample mit dem globalen Ein- und Ausschalten aller Interrupts anschaue, weil's halt viel einfacher aussieht, und "volatile" Variablen

nach etwas Soliderem. Ist solche Frickelei wirklich die Welt, in der die

LOL, *der* war gut :-)

Der Trend scheint bei umfangreicheren Systemen also zu mehr "distributed

immer so gemacht hat :-(

DoDi

Fuer Microcontroller ist nur C von Bedeutung und dann kommt ganz lange garnichts.

Das finde ich einerseits Schade weil ich denke es waere langsam mal an der Zeit da was zu modernisieren, hat aber natuerlich andererseits die Vorteile das man relativ problemlos Herstelleruebergreifend arbeiten kann und man vieles alte weiterverwenden kann.

Bei groesseren Projekten ist soetwas ueblich.

Olaf

Yep. Das sehe ich genauso.

Es gibt teileweise Metacompiler die dann wiederum C als Ausgangscode erzeugen. (Nim)

Das war bisher so. Aber die kleinen Microcontroller von heute werden immer fetter und leistungsfaehiger. Ich glaube z.B nicht das in meiner Firma noch etwas neu entwickelt wird ohne das da ein Betriebssystem drauf laeuft.

Olaf

Am 17.03.2015 um 14:25 schrieb Jack Ryan:

Ich auch: C

Am Ende ist es sowieso immer "Weise Wert zu, addiere/subtrahiere, wenn Bedingung, dann springe" ;-)

Falk

Am 17.03.2015 um 15:04 schrieb Hans-Peter Diettrich:

wir haben neuerdings einen Raspberry mit einer Zusatzkarte mit 32x RS232 huckepack nur deswegen, weil wir die Sensoren (RFID Reader) fertig mir RS232 bekommen. Nix zu machen. Habe ich schon mal versucht mit den Jungs zu reden, aber die schaffen es nicht mal ein korrektes RS232 zu generieren. Die letzte Fuhre war z.B. bei V24-Pegel Mark +9V, Space -9V, bei TTL Pegel Mark 0V, Space 5V. Wohl Australier, weil beides andersherum. Steuerleitungen sind auch active low. Da wir die Dinge

Pipeline :-(

Raspy anzuschliessen, wie die RFID Reader. Aber es gibt auch eine Option via WLAN. Ausserdem man hat das so schon immer gemacht ;-)

ausgewertet werden, und zwar nicht nach konstanten Muster, sondern von verschiedenen Leuten auf verschiedenen Plattformen und dazu noch in

Wissenschaftler, oder welche die es sein wollen.

Nur zur Erinnerung: manche Leute haben falsche Vorstellung, was ein

trotzdem ein RTS.

Waldemar

Am 17.03.2015 19:11, schrieb Waldemar:

Selbst wenn 5 vor Ultimo die Vogonen kommen!

Assembler kann man auch nehmen, wenn es auf das exakte Timining der Leitung en

meist besser ist (die Compiler-Optimierungen sind aktuell sehr gut und der C-Code ist einfacher zu warten). Einige Treiber enthalten typischerweise Assembler-Cod e mit C gemixt. Es soll wohl neue ADA-Compiler geben, weil mal Geld (kommt im betreffenden Indistriezweig eher kaum vor, da die Budgets in der Regel hoffnungslos

nger von BASIC, Verilog oder VHDL (die Altera/Xilinx-Chips auf den Boards).

Seele brennt...

Am 17.03.2015 um 11:16 schrieb snipped-for-privacy@vtxmail.ch:

Waldemar schrieb:

Deshalb schrieb c't vor mehreren Usenet-Ewigkeiten schon von

Klaus

Waldemar schrieb:

Durchaus. Der Mainstream kommt ja auch nicht mehr ohne Parallelverarbeitung in mehreren Kernen usw. aus, mit z.T. heftigen Problemen mit der Synchronisation der Datenzugriffe und unvorhersehbarem Laufzeitverhalten (Thread-Wechsel...). Bei einer Verteilung auf mehrere

die Rechenleistung einfach hochskalieren.

V24 war schon immer ein organisatorisches Problem, das Protokoll hingegen ist extrem robust. Am Institut hatten wir einen 16 Kanal

V24/9600 Baud angeschlossen. Mit Software-Handshake, um Leitungen zu sparen. Das Netzwerk lief bei einer Ausdehnung von 30*40m problemlos,

mit einem Schieberegister, und die Daten mit TTL-Pegel auf die Reise geschickt. Auch das hat der Multiplexer problemlos geschluckt, ich hatte

direkt an TTL-Gatter angeschlossen waren, nicht ganz

werden sollen, und gemeint, einen Inverter vor das Logik-Signal setzen

wahlweiser Belegung von Buchsen und Steckern. Da ging praktisch nix mehr

drangeschrieben, in die das Kabel eingesteckt werden durfte.

Und selbst dann haben es noch Techniker geschafft, zwei Stecker mit brute-force verkehrt herum zusammenzuschrauben, und sich dann beschwert,

Stecker mit dem Hammer zusammengeklopft. Die doch recht stabilen Kragen der 25-poligen Stecker haben sie ja auch schon verbogen. Andere waren da viel ordentlicher, und haben z.B. die Leitungen der Thermoelemente im Motorraum sauber an andere Leitungen angebunden - optisch sehr ansprechend, kein Kabelverhau. Nur hatten sie dabei teilweise auch

verkraftet :-(

In meinen eigenen Systemen habe ich jedenfalls nicht vor, RS-232 einzusetzen, sondern I2C zur Verbindung der Module zu benutzen. Dann

Von WLAN bin ich seit dem EZ-Robot nicht mehr begeistert, abgesehehen

wie mit den alten Basic-Homecomputern, aber sonst eher nicht :-(

und gesetzlichen Feiertagen? ;-)

Zukunft steht in den Sternen, wenn sich die Cloud mal (wieder) verzogen hat :-]

Auch bei Datenbanken traue ich den Benutzern alles zu (s.o.), die

DoDi