Vielleicht lässt sich aus den Arduino-Libraries etwas lernen, deshalb schaue ich mir gerade die Sourcen etwas an. https://github.com/arduino/Arduino/tree/1.5.2/hardware/arduino/avr/cores/arduino Interesant ist der Hardware Abstraction Layer ( HAL ), bei dem z.B. der Zugriff auf die Pins geregelt wird: https://github.com/arduino/Arduino/blob/1.5.2/hardware/arduino/avr/cores/arduino/wiring_digital.c Leider braucht das PIN-setzen dadurch auch einige Zeit.
Es scheint schon einige Versuche zu geben, die Arduino API auf die STM32 MCs zu portieren: https://github.com/gbulmer/openstm32sw/tree/master/stm32f4/libmaple/examples Es wäre interessant, dafür eine ähnlich einfach zu installierende und bedienende IDE wie für den ARDUINO zu haben.
Die Fehlerquote für Einsteiger und Amateure ist dadurch aber auch geringer. Der Sinn liegt aber im Auge des Betrachters. Die MCs werden immer Leistungsfähiger, warum nicht auch den API Level anheben. Mit den Desktop PC hat es doch auch wunderbar funktioniert.
Arduino schrieb: > ..., warum nicht auch den API Level anheben. > Mit den Desktop PC hat es doch auch wunderbar funktioniert. Und auch mit Embedded Systemen, wie neulich am ICE zu bewundern, wo ein Bremssignal 1 Sekunde von der Betätigung bis zur Bremsung im Windows-System rumgeistert...
Da die Mikrocontroller immer zahlreicher und aufwendiger werden, gibt es auch immer mehr Ansätze für eine Standart-API. Bsp.: Elektro EFL : http://www.elektor.de/jahrgang/2013/mai/embedded-firmware-library.2458054.lynkx STM32 standard peripheral library ( leider Herstellerabhängig ) Vielleicht wäre eine Standardisierung der Hardware-Abstraction Layer eine Aufgabe für das MC-Netz
> Und auch mit Embedded Systemen, wie neulich am ICE zu bewundern, wo ein > Bremssignal 1 Sekunde von der Betätigung bis zur Bremsung im > Windows-System rumgeistert... Nur weil viele APIs verwendet werden, kommt noch kein gutes Systemdesign heraus. Die richtige Verwendung der APIs ist das A und O. Hier im Forum liest man ja des öfteren, dass die Leute API Dokumentationen lesen und doch fehlt ihnen das Verständnis der Design Pattern die hinter der API stecken. Eine API ist ein Werkzeug. Falsch eingesetzt richtest es mehr Schaden an, als dass es die Arbeit erleichtert. Grüsse
Hier läuft gerade eine Diskussion zu FreeRTOS auf dem Arduino. Meiner Meinung nach hätte ein Multitasking system schon lange als Stantard in die Arduino Umgebung gehört. Insbesondere mit dem Arduino Due ( Arm Prozessor ) wäre so was nicht schlecht.
chris schrieb: > Hier läuft gerade eine Diskussion zu FreeRTOS auf dem Arduino. Meiner > Meinung nach hätte ein Multitasking system schon lange als Stantard in > die Arduino Umgebung gehört. > Insbesondere mit dem Arduino Due ( Arm Prozessor ) wäre so was nicht > schlecht. Es ist sehr schön das du der meinung bist.. nur was mir sehr befremdend vorkommt.. du fragst im von dir geposteten >da ich mich nicht mit FreeRTOS auskenne: Wie aufwendig ist es, das >System für Arduino in Betrieb zu nehmen? Muss man viel Zeit investieren, >bis es mal grundsätzlich kompiliert? somit würde ich mal stark meinen das du keine ahnung hast von rtos... der name rtos steht für real time operating system .. das bedeutet man soll voraussagen können wann wer was macht nicht einfach random bisschen "parallel" machen .. von mutex,semaphoren,memorymanagement und dem ganzen will ich gar nicht sprechen ... sowas hat mit arduino nichts zu tun..
>somit würde ich mal stark meinen das du keine ahnung hast von rtos... Du solltest die Posts genauer lesen. Meine Frage war nicht, wie ein RTOS funktioniert, sondern wie groß der Aufwand für die Installation in der Arduino Umgebung ist. In der Arduino ist es üblich, dass die Dinge schnell funktionieren. Wenn man FreeRTOS also in 5 Minuten ausprobieren kann, lohnt es sich. >der name rtos steht für real time operating system .. das bedeutet man >soll voraussagen können wann wer was macht nicht einfach random bisschen >"parallel" machen .. >von mutex,semaphoren,memorymanagement und dem ganzen will ich gar nicht >sprechen ... Dir fehlt die Phantasie. Wie das Arduino Konzept zeigt, kann man sehr wohl komplizierte Sachverhalte auf Wesentliches reduzieren un jedem zur Verfügung stellen. Wer hätte gedacht, dass die Mikrocontrollerprogrammierung in C dank Arduino von jedem Laien innerhalb kurzer Zeit verwendet werden kann?
chris schrieb: > Wer hätte gedacht, dass die > Mikrocontrollerprogrammierung in C dank Arduino von jedem Laien > innerhalb kurzer Zeit verwendet werden kann? Jau. Sehen wir hier oft genug, was dann dabei rauskommt. (Sorry, could not resist)
Das liegt aber nicht am Arduino sondern an der Weigerung der Einsteiger sich erst mal mit den Grundlagen und der Programmiersprache auseinander zu setzen. Bevor man die HW anpackt erst mal 2-3 Wochen die ein C/C++ Buch lesen und sich mit der Arduino API beschäftigen. Viel zu viele Einsteiger meine, dass sie das mit "Trail & Error" geregelt bekommen! Großer Irrtum. Aber erzählen kann man/ich ja viel. ;-) Grüsse
Markus M. schrieb: > Das liegt aber nicht am Arduino sondern an der Weigerung der Einsteiger > sich erst mal mit den Grundlagen und der Programmiersprache auseinander > zu setzen. So ist es. Nur ist es so, dass diejenigen, die mit dem entsprechenden Vorwissen an die µC-Programmierung herangehen, Arduino nicht mehr brauchen bzw. wollen. Da fragt man sich: Für wen ist dann Arduino überhaupt gemacht?
>Für wen ist dann Arduino überhaupt gemacht? Ich denke, dieses Thema wurde hier ausführlich diskutiert: Beitrag "Re: Arduino - bringt's das ?" Ich schließe mich ( mit ähnlicher Historie ) PittyJ an.
chris schrieb: > Interesant ist der Hardware Abstraction Layer ( HAL ), bei dem z.B. der > Zugriff auf die Pins geregelt wird: > > https://github.com/arduino/Arduino/blob/1.5.2/hard... > > Leider braucht das PIN-setzen dadurch auch einige Zeit. Nicht nur das, der Zusammenhang zwischen Bits und Ports geht auch verloren. Wenn ich damit z.B. einen 8Bit-DAC ansteuern will, kriege ich zwischen 2 Werten riesige Spikes. Das ist nicht zu gebrauchen. Auch ist die Pinnumerierung unterschiedlich zwischen DIP/SMD und ich habe Lücken (VCC, GND-Pins usw.). Ich sehe daher keinerlei Vorteil gegenüber der Pinbenamung lt. Datenblatt. Im Gegenteil, mit Bitmacros lassen sich die einzelnen Pins direkt verwenden: http://www.mikrocontroller.net/attachment/157663/sbit.h Das Macro funktioniert sogar auch bei den Ports, die mit LDS/STS adressiert werden (ist dann aber nicht Interrupt fest). Und auch den Lernaufwand, daß 8 Pins einen Port bilden, halte ich nicht für zu hoch.
@Peter Kann man eigentlich, in der Arduinoentwicklungsumgebung, beides machen? Also die "verpackten" Funktionen nutzen UND eine Makrosammlung wie sbit.h einbinden. Ich finde es immer angenehm, wenn am Anfang, innerhalb der Initialisierung alles gut "Lesbar" ist - die Ausführungszeit ist da ja nicht so wichtig - und man wo es darauf ankommt, die Bits "persönlich" begrüßen kann.
>Nicht nur das, der Zusammenhang zwischen Bits und Ports geht auch >verloren. Es ist eine Abstraktion. Man kann somit Programme zwischen einem Arduino Uno http://arduino.cc/de/Main/ArduinoBoardUno( Atmega328 ), Arduino Mega http://arduino.cc/de/Main/ArduinoBoardMega und einem Arduino Due http://arduino.cc/de/Main/ArduinoBoardDue ( ARM SAM3X8E ) austauschen. Die Pins auf den Boards sind mit den Nummern der Pin-Treiber versehen. Vielleicht ist es etwas ähnliches wie mit einem LINUX-INTEL und einem LINUX-ARM PC: auf beiden kann die gleich Software laufen.
> Kann man eigentlich, in der Arduinoentwicklungsumgebung, beides machen?
Ja. Arduino nutzt C++ als Programmiersprache.
Du bist nur mehr oder wenig eingeschränkt, da Arduino ein paar Resourcen
des MC für sich beansprucht, die dir dann nicht mehr zur Verfügung
stehen. Da ist es ratsam mal in den Source Code zu schauen.
Grüsse
Hier habe ich eine sehr interessante FastSpi Bibliothek für den Arduino zur Ansteuerung der WS2811 LEDs gefunden: http://code.google.com/p/fastspi/downloads/detail?name=FastSPI_LED2.RC1.zip In der Datei lib8tion.h finden sich schnelle C Funktionen mit Assembler Inhalt. Ein Beispiel aus dem Kommentar:
1 | /*
|
2 | - Scaling (down) of unsigned 8- and 16- bit values.
|
3 | Scaledown value is specified in 1/256ths.
|
4 | scale8( i, sc) == (i * sc) / 256
|
5 | scale16by8( i, sc) == (i * sc) / 256
|
6 | |
7 | - Fast 8- and 16- bit unsigned random numbers.
|
8 | Significantly faster than Arduino random(), but
|
9 | also somewhat less random. You can add entropy.
|
10 | random8() == random from 0..255
|
11 | random8( n) == random from 0..(N-1)
|
12 | random8( n, m) == random from N..(M-1)
|
13 | |
14 | - Fast 16-bit approximations of sin and cos.
|
15 | Input angle is a uint16_t from 0-65535.
|
16 | Output is a signed int16_t from -32767 to 32767.
|
17 | sin16( x) == sin( (x/32768.0) * pi) * 32767
|
18 | cos16( x) == cos( (x/32768.0) * pi) * 32767
|
19 | Accurate to more than 99% in all cases.
|
20 | */
|
Damit lassen sich einige C-Programm deutlich beschleunigen
Peter Dannegger schrieb: > Nicht nur das, der Zusammenhang zwischen Bits und Ports geht auch > verloren. Seh ich nicht so, das ist für mich ein Vorteil. Wenn ich "höhere" Treiber schreibe, wie zB für ein LCD oder ein 595-Schieberegister, nervt es mich oft dass ich mir immer zwei Werte merken muss. Auserdem darf ich sie z.B. nicht in einer Struktur ablegen, sonst nehm ich gcc die Möglichkeit, richtig zu optimieren. Deine sbit.h ist zwar schön und gut, und ich verwende sie auch ab und zu. Aber manchmal ist man damit auch limitiert. Ich kann damit z.B. keine "Kanalnummer " (= Kombination aus Port + Pin) an eine Funktion übergeben. Wenn ich etwas generisch halten will funktioniert das damit nicht. Wie auch immer: Sooft ich mich darüber ärgere, ich lande auch immer wieder bei sbit.h oder dem typischen Bitgeschiebe. Der Overhead bei der Arduino-Style-Lösung ist einfach zu groß. Meine effektivste Implementierung braucht ca. 20 Takte. Das ist leider ein Overhead von 1900%. Wenn man ab und zu eine Status-Led schaltet, OK. Ein Schieberegister anzusteuern ist so allerdings Schwachsinn.
Hallo, Peter Dannegger schrieb: > chris schrieb: >> Interesant ist der Hardware Abstraction Layer ( HAL ), bei dem z.B. der >> Zugriff auf die Pins geregelt wird: >> >> https://github.com/arduino/Arduino/blob/1.5.2/hard... >> >> Leider braucht das PIN-setzen dadurch auch einige Zeit. > > Nicht nur das, der Zusammenhang zwischen Bits und Ports geht auch > verloren. > Wenn ich damit z.B. einen 8Bit-DAC ansteuern will, kriege ich zwischen 2 > Werten riesige Spikes. Das ist nicht zu gebrauchen. das ist für mich nicht trivial offensichtlich, warum ist das denn so? > Und auch den Lernaufwand, daß 8 Pins einen Port bilden, halte ich nicht > für zu hoch. hmm, ist das denn bei einem Atmel SAM3X8E (Arduino Due) überhaupt so? Vlg Timm
chris schrieb: > Damit lassen sich einige C-Programm deutlich beschleunigen Was zu beweisen wäre. Schliesslich machen diese Arduino-Funktionen nicht das selbe wie ihre vollwertigen Varianten. Oliver
Timm Reinisch schrieb: > Peter Dannegger schrieb: >> Nicht nur das, der Zusammenhang zwischen Bits und Ports geht auch >> verloren. >> Wenn ich damit z.B. einen 8Bit-DAC ansteuern will, kriege ich zwischen 2 >> Werten riesige Spikes. Das ist nicht zu gebrauchen. > > das ist für mich nicht trivial offensichtlich, warum ist das denn so? Na stell dir einfach vor, dein DAC wäre an 4 Pins von PORTC und 4 Pins von PORTB angeschlossen. Und jetzt willst du den Analogwert von 0x7F auf 0x80 ändern. Da du nicht beide Ports in einem Befehl beschreiben kannst, sieht der DAC für kurze Zeit einen Zwischenzustand, z.B. 0x7F - 0x8F - 0x80. Auf der analogen Seite ein Spike. Wenn man statt in Pins hingegen in Ports denkt, dann kann man den DAC an einen Port hängen und in einem Rutsch beschreiben. Ich kenne das Arduino-API nicht. Aber es scheint als würde das HAL komplett von Ports abstrahieren und man hätte einfach nur eine Anzahl von Pins. Wenn man dann gar nur einen Pin per API-Aufruf setzen könnte, dann müßte man für obiges Beispiel 8 API-Rufe absetzen (es ändern sich ja alle 8 Pins) und hätte 7 Zwischenzustände. Ich hoffe mal, es ist nicht ganz so braindead ;) XL
Axel Schwenke schrieb: > Ich kenne das Arduino-API nicht. Aber es scheint als würde das HAL > komplett von Ports abstrahieren und man hätte einfach nur eine Anzahl > von Pins. Wenn man dann gar nur einen Pin per API-Aufruf setzen könnte, > dann müßte man für obiges Beispiel 8 API-Rufe absetzen (es ändern sich > ja alle 8 Pins) und hätte 7 Zwischenzustände. Ich hoffe mal, es ist > nicht ganz so braindead ;) Das was du hier beschreibst ist ziemlich exakt das, wie die Arduino API von den Ports wegabstrahiert wurde. Man kann natürlich noch immer über die PINx und PORTx Register zugreifen und ich denke, die besseren Arduino Programmierer machen das auch bei Bedarf. Aber zumindest bei den Fragern, die hier im Forum aufschlagen, löst der Gedanke, dass es da auch noch Ports gibt regelmässig Schweissausbrüche aus.
Karl Heinz Buchegger schrieb: > Axel Schwenke schrieb: >> ... Wenn man dann gar nur einen Pin per API-Aufruf setzen könnte, >> dann müßte man für obiges Beispiel 8 API-Rufe absetzen (es ändern sich >> ja alle 8 Pins) und hätte 7 Zwischenzustände. Ich hoffe mal, es ist >> nicht ganz so braindead ;) > > Das was du hier beschreibst ist ziemlich exakt das, wie die Arduino API > von den Ports wegabstrahiert wurde. Tja. Man hätte ja auch ein API bauen können, wo man in einer Daten- struktur[1] mehrere Pins und deren gewünschte Zustände übergibt. Und dann auf der anderen Seite der API alle Pins, die zum selben Port gehören, mit einem Schreibzugriff updaten. Aber klar, das wäre zu kompliziert für die intendierte Zielgruppe :P XL [1] für ein Beispiel sehe man sich die Manpage zu select(3) an und wie da die fd_set Datenstruktur verwendet wird.
Bei jeder API ist es so, dass sie bestimmten Beschränkungen unterliegt. Wer könnte wohl auf die Idee kommen, einen 8 Bit ADC an einen Arduino anschließen zu wollen?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.