Analyse der Arduino Libraries

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...

> 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

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?

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.

> 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

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

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.