Plutos-AVR

[pluto]

Hallo,
ich dachte ich erstelle mal ein eignen Thread. Ich habe meine AVR Umgebung inzwischen Überarbeitet.

Änderungen:
Samstag, 08.09.2018
- AM2320: Die Methoden "readTemp" und "readHum" überarbeitet und Fehler Erkennung eingebaut.
über die Errror Variable kann nun abgefragt werden ob es Problem gab(ist noch nicht optimal).

- AM2320: crc16 Hinzugefügt. Vielen Dank an Mathias der, die Methode von C++ nach Pascal übersetzt hat.
Hier ist noch geplant: Eine Auswahl Möglichkeit hinzuzufügen, da die Methode mehr Speicher benötigt und mehr Zeit braucht.

Freitag, 07.09.2018
- AM2320: Ist nun ein eigene Klasse(object)
- AM2320: Über die Methoden "readTemp" und "readHum" können nun die Werte ausgelesen werden

- DS3231 Ist ebenfalls eine eigene Klasse(object)

[Mathias]

Hier hast du ein UInt16, ein Int ohne Vorzeichen.

Code: Alles auswählen

function TAVR_Sensor_Am2320.readTemp(): UInt16;

Und hier gibt es ein negatives Result.

Code: Alles auswählen

result:=-(Temp_T and $7fff)

Hat deine Funktion in C++ keinen Funktionskopf ?

[pluto]

Hat deine Funktion in C++ keinen Funktionskopf ?

Doch schon.... Aber der Hilft nicht unbedingt weiter....

Code: Alles auswählen

 
 float readTemperature();
  float readHumidity();
 

[Mathias]

Aber hast den Fehler gefunden ?

[pluto]

Aber hast den Fehler gefunden ?

Nein, noch nicht, ich verstehe die Syntax an dieser Stelle einfach nicht:

Code: Alles auswählen

-(int16_t)(t&0x7fff);

Im Prinzip die Ganze Funktion, bis auf den Anfang.... Wie sieht das in Pascal aus?

[Mathias]

Das (int16_t) eine Typenumwandlung, in komplizierter C-Schreibweise.

Code: Alles auswählen

// C
ft = -(int16_t)(t&0x7fff);
// Pascal
ft := - Int16(t and $7FFF);

Hast du das UInt16 im Procedurekopf schon in Int16 umbenannt ?

[Timm Thaler]

Nein, noch nicht, ich verstehe die Syntax an dieser Stelle einfach nicht:

Code: Alles auswählen

-(int16_t)(t&0x7fff);

Die codieren die Zahl einfach bißchen bekloppt. Statt im üblichen Zweierkomplement wird die Zahl als Betrag (Bit14..0) und Vorzeichen (Bit15) übergeben. Zum Verstehen des Unterschiedes siehe die Tabelle unter https://de.wikipedia.org/wiki/Zweierkomplement.

Die Funktion prüft mit if(t & 0x8000), ob Bit15 gesetzt, also ein Vorzeichen vorhanden ist und entfernt dann mit (t&0x7fff) das Vorzeichen. Anschließend wird mit (int16_t) von unsigned integer auf signed integer gecastet und mit - die bisher noch positive Zahl (Betrag) negiert, so dass ein echtes Zweierkomplement herauskommt.

[Timm Thaler]

- AM2320: Ist nun ein eigene "class"
- DS3231 Ist ebenfalls eine eigene class

Btw: Nicht machen!

Klassen funktionieren zwar auch bei den AVRs, erzeugen aber einen erheblichen Overhead im Kompilat, der Dir eigentlich nichts bringt.

[pluto]

Das (int16_t) eine Typenumwandlung, in komplizierter C-Schreibweise.

Danke, Ein teil habe ich mir schon fast gedacht, den anderen noch nicht... Werde ich morgen mal ausprobieren.

Hast du das UInt16 im Procedurekopf schon in Int16 umbenannt ?

Ich meine ja..

Klassen funktionieren zwar auch bei den AVRs, erzeugen aber einen erheblichen Overhead im Kompilat, der Dir eigentlich nichts bringt.

Wie sonst sollte man z.b. mehrer LCD oder AM2320 Sensoren nutzen können? Wenn nicht in Klassen? Mit Records?

[Mathias]

Wie sonst sollte man z.b. mehrer LCD oder AM2320 Sensoren nutzen können? Wenn nicht in Klassen? Mit Records?

Object wäre eine Alternative.

[pluto]

Object wäre eine Alternative.

Das habe ich ja genutzt. Timm Thaler meinte aber man sollte es besser nicht nutzen.... oder habe ich es Falsch verstanden?

Ich meinte mit class object eigentlich....

[Mathias]

Timm Thaler meinte aber man sollte es besser nicht nutzen....

Funktionieren tut es, aber es verbraucht Speicher, welcher bei einem AVR knapp werden kann.

Ich habe mal versucht Proceduren in eine erweiterten Record zu packen, dies braucht aber mehr Speicher als wen man Proceduren nackt schreibt.

Ob dies bei C++ auch der Fall ist, das eine Classe mehr Speicher verbraucht, müsste man mal testen. Immerhin baut fast alles bei Arduino auf Classen aus. Schon ein serial.begin ist eine Classen-Funktion.

[pluto]

Ob dies bei C++ auch der Fall ist, das eine Classe mehr Speicher verbraucht, müsste man mal testen. Immerhin baut fast alles bei Arduino auf Classen aus. Schon ein serial.begin ist eine Classen-Funktion.

Aus diesem Grund habe ich es inzwischen in eigene Klassen(object) gepackt. Weil es einfach "übersichtlicher" ist finde ich....
Ich denke die Proceduren müssen gar nicht in das Record. Es könnte reichen, wenn da z.b. nur die Adresse drin steht...

Werde ich mal ausprobieren. Ob das eine Alternative ist und ob das wirklich deutlich weniger Speicher verbraucht. Aktuell erzeugt fpc bei mir eine hex die ca 30.5 kb oder so groß ist und avrude macht daraus dann 11 kb oder so.... ist natürlich schon viel, wenn man nur 32 kb hat.

Ich finde aber für den Anfang ist das schon OK... Vielleicht vergleiche ich mal die Größe mit Klassen(object) und ohne ob das WIRKLICH so viel ausmacht.

[mse]

Ich meinte mit class object eigentlich....

Dann schreibe das bitte auch so. "object" richtig angewandt kann für uP's Sinn machen, "class" nicht, da es einen grossen Overhead bedeutet. Auch musst du darauf achten, dass nicht unnötig RTTI angelegt wird.
Falls du dich für die Programmierung von Microchip uP's in Pascal interessierst, Edsons PicPas ist ein weiteres interessantes Projekt:
https://forum.lazarus.freepascal.org/in ... 595.0.html
Kennt jemand den Stand des LLVM AVR Backends? Falls das bereits brauchbar ist, wäre auch MSElang von Interesse.

[pluto]

Dann schreibe das bitte auch so. "object" richtig angewandt kann für uP's Sinn machen, "class" nicht, da es einen grossen Overhead bedeutet.

Mich wundert nur, dass der FPC das scheinbar Kompiliert.... Vielleicht wäre an dieser stelle ein "Hinweis" oder sogar eine "Warnung" nicht schlecht.
Ich habe aber schon vorher gelesen, dass CLASS nicht geht bzw. nicht Sinnvoll ist.

Falls du dich für die Programmierung von Microchip uP's in Pascal interessierst, Edsons PicPas ist ein weiteres interessantes Projekt:

Klar, aber ich bin immer Froh wenn es die Infos auf Deutsch gibt, so wie es hier der Fall war...