Tutorial Arduino programmieren,

[pluto]

Es ist nicht nur der Preis, auch Power hat er mehr, immerhin ist er mit 72MHz getaktet und erst noch ist er 32Bit.
ATtiny/Atmega max 20MHz, nur 8Bit.

Das meinte ich damit... Es gibt von STM32 auch ein "Käfer" mit ähnlichen Leistungen.....
Auch die Anzahl der "Pins".... beim 303 ca um die 80 Stück und beim 103 weniger, wobei es ja von allen Cortex(en) ja auch wieder verschiedene Varianten gibt.
Beim 103 ist ja eine "kleinere" Variante gebaut, den gibt es auch größer....

Dafür ist Arduino/atMega besser Dokumentiert und auch noch in Deutscht.... man findet einfach leichter Informationen, habe ich so den Eindruck... bei STM32 ist man quasi auf das Datenblatt angewiesen.... bis du das durch hast, vergeht aber einige Zeit....

[Mathias]

Für ein STM32 Discovery Board gibt es eine erprobte Lösung hier:
viewtopic.php?f=9&t=11264&start=35

Dein Wissen, was du mir dort weiter gegeben hat, habe ich im Wiki veröffentlicht: http://wiki.freepascal.org/ARM_Embedded_Tutorial/de
Ohne dies ginge gar nicht mit STM32.

Aber es wäre trotzdem ein Wunsch, wen es auch mit Lazarus laufen würde.

Dafür ist Arduino/atMega besser Dokumentiert und auch noch in Deutscht.... man findet einfach leichter Informationen, habe ich so den Eindruck... bei STM32 ist man quasi auf das Datenblatt angewiesen.... bis du das durch hast, vergeht aber einige Zeit....

Du hast nicht nur den Eindruck, es ist leider auch so. Beim AVR-Tutorial habe ich fast alles im Nerz gefunden. Beim STM32 findet man praktisch nichts.
Der Grund wird wohl sein, das der Arduino sehr verbreitet ist.
Beim Datenblatt vom STM32 hast du recht, dies ist ein dickes Buch.

Ich habe mal bei Amazon geguckt, für den Arduino gibt es massenweise Bücher, wovon die meisten nur für Anfänger sind.
Für den STM32 habe gar keines gefunden.

[Timm Thaler]

So unbekannt, ist das Tutorial doch nicht.

Nicht machen!

Die Leute im µC Forum sind größtenteils C-fixiert. Um nicht zu sagen manisch C-fixiert. Lass Dich mit denen auf keine Diskussion über Lazarus oder Pascal ein, wenn Du nicht ganz sicher bist auf dem Bodensatz des Diskussionniveaus fischen zu wollen.

[Timm Thaler]

Deswegen verwendet man bei Arrays _immer_ die Funktionen low() und high().

Probiere ich gern aus, wenn ich mal wieder an dem Projekt mit dem nRF dran bin, und würde das dann auch ins Tut übernehmen. Momentan gibts andere Projekte, aber das kommt bestimmt wieder auf den Tisch.

[Socke]

Siehe FPC-Quelldate rtl/inc/dynarr.inc

So wie ich das sehe, bezieht dich dies auf dynamische Arrays, mit denen kann der AVR sowieso nicht umgehen.
Sind die Functionen Lenght, High und Low nicht nur Alias ?

Offensichtlich sind nur low() und high() bei statischen Arrays als compiler-intrinsische Funktion implementiert. In einer höheren Optimierungstufe sollte das herumgerechne aber eleminiert werden.

[Mathias]

Offensichtlich sind nur low() und high() bei statischen Arrays als compiler-intrinsische Funktion implementiert.

Wen ich das so lese wird dies das optimalste sein ?

Code: Alles auswählen

for i := to 7 do ...

[Socke]

Wen ich das so lese wird dies das optimalste sein ?

Code: Alles auswählen

for i := to 7 do ...

Änderst du den Array, hast du sofort ein massives Problem in deinem Programm. Am besten verwendest du immer bei statischen und dynamischen Arrays low() und high():

Code: Alles auswählen

for i := low(myarray) to high(myarray) do ...

[/quote]

[Mathias]

Egal welche Variante ich von den dreien nehme, der Kompilierte Code ist immer gleich gross.

Code: Alles auswählen

{$O-} // Optimierung aus
var
    a:array[0..7] of Char;
begin
  for i := 0 to high(a) do UARTSendChar(a[i]);  
  for i := 0 to Length(a) -1  do UARTSendChar(a[i]);  
  for i := 0 to 7 do UARTSendChar(a[i]);  

[Timm Thaler]

Egal welche Variante ich von den dreien nehme, der Kompilierte Code ist immer gleich gross.

Was schlichtweg daran liegt, dass der Compiler natürlich in allen 3 Varianten den gleichen Endwert für die Schleife nimmt: 7

Der Unterschied liegt daran, dass bei a) die Schleife angepasst wird, wenn Du die Feldlänge änderst, bei b) ebenfalls, aber Probleme macht, wenn Du die -1 vergisst und bei c) eine Änderung nicht übernommen wird.

Bei a) denkt der Compiler am besten für Dich mit.

[Mathias]

Was schlichtweg daran liegt, dass der Compiler natürlich in allen 3 Varianten den gleichen Endwert für die Schleife nimmt: 7

Aber wen ich den Kommentar von Socke lese, habe ich gedacht, das dies anders aussieht.

Oder hat er damit dynamische Array gemeint, welche bei AVR sowieso nicht unterstützt sind ?

[Socke]

Was schlichtweg daran liegt, dass der Compiler natürlich in allen 3 Varianten den gleichen Endwert für die Schleife nimmt: 7

Aber wen ich den Kommentar von Socke lese, habe ich gedacht, das dies anders aussieht.

Ich hatte dies aufgrund diesen Postsvon Timm Thaler gemutmaßt; dass dem bei statischen Arrays nicht so ist, haben wir wohl herausgefunden. Da der code-Abschnitt von Timm Thaler aber unvollständig ist, kann ich das dort geschilderte Problem nicht nachvollziehen.

[Timm Thaler]

Ich hatte dies aufgrund diesen Postsvon Timm Thaler gemutmaßt; dass dem bei statischen Arrays nicht so ist, haben wir wohl herausgefunden. Da der code-Abschnitt von Timm Thaler aber unvollständig ist, kann ich das dort geschilderte Problem nicht nachvollziehen.

Das bezieht sich auf den Teil im Tutorial zum SPI: http://wiki.freepascal.org/AVR_Embedded ... Cbertragen

Hier wird ein Array vorher nicht bekannter Länge "by reference" übergeben*. Da kann der Compiler keine Konstante für das Schleifenende einbauen, die Arraylänge muss jedesmal übergeben werden.

In Mathias Beispiel ist aber die Arraylänge bekannt, und da ist der Compiler halt so schlau, jedesmal die Konstante gleich einzubauen.

*) Ich bin mir jetzt nicht sicher, ob das schon als "dynamisches Array gilt. Ich glaube mich aber zu erinnern, dass Arrayübergabe "by reference" nur mit nullbasierten Arrays funktioniert.

[Mathias]

Ich glaube mich aber zu erinnern, dass Arrayübergabe "by reference" nur mit nullbasierten Arrays funktioniert.

Gehen tut es, folgender Code spuckt 0 3 aus. Wichtig ist das var bei Test.

Code: Alles auswählen

var
  ar1: array[10..13] of Byte = (1,2,3,4);
 
  procedure Test(var p: array of Byte);
  var
    s: ShortString = '';
  begin
    str(Low(p): 6, s);
    UARTSendString(s);
    str(high(p): 6, s);
    UARTSendString(s);
  end;
 
begin
  UARTInit;
  UARTSendString('Anfang' + #13#10);
  Test(ar1);

[Timm Thaler]

Gehen tut es, folgender Code spuckt 0 3 aus.

Ah richtig, in der Routine war das Array dann immer nullbasiert, woraufhin ich die Zeichenbuffer auch nullbasiert angelegt habe, um mich nicht zu sehr zu verwirren. Mit low() und high() wäre das auch kein Problem, kannte ich damals noch nicht.

Aber ist das Array in der Routine nun ein "dynamisches Array" in dem Sinn, den Pascal dafür verwendet (http://wiki.freepascal.org/Dynamic_array), oder kann man das so nicht sagen?

[Mathias]

Auf dem PC betrachtet, ist eine dynamische Array auf dem Heap und eine statische im Datenspeicher.
Anscheinend ist der Function egal, ob der Zeiger von Heap oder vom Daten speicher kommt. Aber ein Längenbyte muss interen auf jeden Fall übergeben werden, ansonsten weis die Function nicht wie lange die array ist.