neue Asuro Lib V2.70 (Release Candidate 3)

[Sternthaler]

Ich sollte weniger, oder schneller, schreiben.
Hallo m.a.r.v.i.n

[radbruch]

Die Daten wären reines ascii und die Datei gegebenenfalls editierbar. Natürlich sollte die Lib mit Defaults laufen. Neulinge, die mit den Ergebnissen mit defaults nicht zufrieden sind, werden sicher auch in der Lage sein, die myasuro-Datei zu erzeugen. Und die Zufriedenen werden sich nicht dran stören.

Das Kalibrierungsproggi kann man bestimmt gut als erweitertes selftest unter die Leute bringen.

[damaltor]

ja das ist wahr, also ein kalibrierungsprogramm sollte möglich sein, und das halte ich auch für sehr sinnvoll. es müsste allerdings die datenübertragung möglichst sicher gestaltet werden, damit nicht aufgrund eines fehlerhaften bytes irgend ein mist übertragen wird und der dann in allen (!) programmen kompiliert wird. evtl sollte der nutzer zum abgleich den empfangenen wert nochmal eingeben oder so etwas.
braucht ein integer wirklich nur 2 bytes? wo steht, welchen typ die variable hat? signed oder unsigned? ich kenne mich mit speicherarchitekturen nicht besonders aus, es reicht gerade für ein paar grundsätzliche pointer und adressoperationen. ansonsten könnte man ja die letzten paar bytes des eeprom reservieren, beispielsweise alle über 500 oder alle über 480 oder so. allerdings sollte eine lib so knapp wie möglich sein und deshlab nicht immer auf den eeprom angewiesen sein. auch die wiederkehrenden eeprom lese aktionen machens nicht zwingend einfacher und auch wenn sie nur ein paar bytes belegen müssen die einfach nciht sein.
ich bleibe bei den defines =)
hier mal beispielcode zum schreiben eines bytes in den eeprom (übergeben werden die adresse (ein wert zwischen 0 und 511 bzw 0 und 0x1F) und die daten (ein char)

void EEPROM_write(unsigned int uiAddress, unsigned char ucData)
{
  /* Wait for completion of previous write */
  while(EECR & (1<<EEWE))
    ;
  /* Set up address and data registers */
  EEAR = uiAddress;
  EEDR = ucData;
  /* Write logical one to EEMWE */
  EECR |= (1<<EEMWE);
  /* Start eeprom write by setting EEWE */
  EECR |= (1<<EEWE);
}

und zum lesen muss nur die adresse übergeben werden:

unsigned char EEPROM_read(unsigned int uiAddress)
{
  /* Wait for completion of previous write */
  while(EECR & (1<<EEWE))
    ;
  /* Set up address register */
  EEAR = uiAddress;
  /* Start eeprom read by writing EERE */
  EECR |= (1<<EERE);
  /* Return data from data register */
  return EEDR;
}

Diese funktionen sind direkt aus dem datenblatt genommen, ich vermute deshalb dass sie so minimalistisch wie möglich sind. aber eben trotzdem eigentlich unnötig.

[Sternthaler]

@radbruch
Das mit den Möglichkeiten eines Kalibrierungsprogramms sehe ich ja auch als sehr gute Idee, um seinen eigenen Asuro möglichst perfekt einzustellen.
Ich wollte hier darauf hinweisen, dass es wichtig ist, jetzt schon mal über die Technik zum Einbinden von 'externen' Konfig-Daten nachzudenken. (Hätte ich ja auch schon füher schreiben können. )


ABER VIEL WICHTIGER zum aktuellen Release Candidate 2.

In der Doku zur Funktion EncoderStart() in encoder.c habe ich als Fehler beschrieben, dass die Funktion nicht geeignet ist die Rad-Encoder-Automatik wieder zu starten nach einem EncoderStop().
DAS DORT VON MIR ALS FEHLER BESCHRIEBEN VERHALTEN STIMMT SO NICHT.
stochri hat (natürlich) alles richtig gemacht, da er in EncoderInit() den ADC-Wandler im sogenannten 'free running'-Mode startet. Damit ist es eben doch Möglich die Automatik zu stoppen und mit EncoderStart() wieder zu starten. Tut mir Leid, Doku wird korrigiert.

[damaltor]

Na das klingt doch gut...

mehr ideen morgen, ab ins bett jetzt kinder =)

[Sternthaler]

@damaltor (ich werde immer erst um diese Zeit wach)
int ist tatsächlich nicht immer 2 Byte groß. Die tatsächliche Größe hängt vom verwendeten Rechner/CPU (evl. Compiler) ab.
Aus diesem Grund gibt es auch noch eine andere Variante um integer-Variablen zu definieren. Da werden dann z.B. die Typen uint32_t oder int16_t benutzt.
Das u bedeutet dann, dass der Wert als unsingned zu interpretieren ist, und die Zahl gibt die BIT-Anzahl an.
Diese Typen sind in der Include-Datei [AVR-Installation]\avr\include\inttypes.h definiert und stellen auf jedem System sicher, dass die Variablen tatsächlich immer die Größe haben, die der Programmierer haben möchte.
Bei dem unsigned ändert sich auf keinen Fall etwas an der BIT-Anzahl. Du kannst in einer mit 'unsigned char' oder eben mit uint8_t Zahlen zwischen 0 und 255 in den 8 Bits speichern. Wird die Variable als 'char' oder int8_t definiert, ändert sich der Bereich zu -128 bis +127.
Komisch: Eigendlich kannst du in beiden Typen doch immer nur 8 Bits an- bzw. ausgeknipst setzen. Wo kommt also das Vorzeichen mal her und dann doch wieder ohne Vorzeichen.
--> Das Höchstwertige Bit wird bei den signed-Werten einfach mal so als Vorzeichen INTERPRETIERT (0=Plus; 1=Minus und dann kommt da noch bei den negativen Zahlen das 2'er-Komplement hinzu. Bitte weiter fragen bei Bedarf.)
Bei den UNsigned-Werten wird das höchste Bit als weiteres Bit für den Zahlenwert benutzt.


P.S.: Danke für deine Code-Stücke für das EEPROM.

[damaltor]

also dass das von der architektur abhängt, das hab ich schonmal gehört, und das zweierkomplement kenne ich auch. so ganz grob weiss ich wie das aussehen muss, aber beispielsweise wird bei float-zahlen doch auch das vorzeichen als eigenes bit gespeichert (0=+,1=-), dann der exponent + BIAS, dann die normierte mantisse ohne 1. irgendwo muss doch vermerkt werden, ob ein wert nun unsigned ist oder nicht, ansonsten wüsste ja niemand ob man 11111111 nun als 255 oder asl -127 ausgeben / rechnen sollte... aber naja. auf die paar bytes kann man zwar wahrscheinlich verzichten, das ist schon wahr. aber ich denk dann immer, man müsste nicht drauf verzichten, schliesslich könnten die werte genausogut einmal definiert werden und dann verwendet werden. schliesslich wurde ja auhc die lib zerlegt, um immer mal einige bytes der nicht benötigten funktionen sparen zu können.

[_HP_]

Hallo Lib-Entwickler,

nachdem ich mich eine Weile mit der Frage herumgeschlagen hatte, warum es eine myasuro.h Datei gibt, diese aber nirgends verwendet wird, habe ich in diesem Thread den Grund gefunden. Es wäre wünschenswert, wenn der Hinweis, das diese Werte noch keine Bedeutung habe auch im Kommentar der Datei selbst stehen würde.

Und was mir noch aufgefallen ist: Der 72kHz - Timer wurde auf 36kHz geändert. Leider steht nirgens WARUM?! Könntet Ihr mir das bitte erklären und dann auch in die Doku einfließen lassen. Das wäre Klasse.

Zur Diskussion um die ASURO-spezifischen Werte: Ich bin auch dafür, diese von jedem Nutzer selbst ermiteln zu lassen - und zwar mit gut dokumentierten Testprogrammen. Das fördert das Verständnis über die Sensorproblematik erheblich, und wenn es dann klappt, dann weiß man auch warum...

Sonst aber ein großes Lob für die viele Arbeit, die Ihr Euch gemacht habt. Wenn ich darf - würde ich gern an einer Weiterentwicklung der Lib mitarbeiten...

Gruss,

_HP_

[m.a.r.v.i.n]

Hi _HP_,

nachdem ich mich eine Weile mit der Frage herumgeschlagen hatte, warum es eine myasuro.h Datei gibt, diese aber nirgends verwendet wird, habe ich in diesem Thread den Grund gefunden. Es wäre wünschenswert, wenn der Hinweis, das diese Werte noch keine Bedeutung habe auch im Kommentar der Datei selbst stehen würde.

Im aktuellen Entwicklungsstand werden die Defines bereits verwendet. Ich denke, dass dieses Wochenende eine weitere Release veröffentlicht wird.

Und was mir noch aufgefallen ist: Der 72kHz - Timer wurde auf 36kHz geändert. Leider steht nirgens WARUM?! Könntet Ihr mir das bitte erklären und dann auch in die Doku einfließen lassen. Das wäre Klasse.

Gute Frage. Diese Änderung wurde schon vor geraumer Zeit gemacht. Wenn ich mich recht erinnere, im Zusammenhang mit dem Umbau der IR Schnittstelle zur Hinderniserkennung. Mehr weis ich leider auch nicht.

Zur Diskussion um die ASURO-spezifischen Werte: Ich bin auch dafür, diese von jedem Nutzer selbst ermiteln zu lassen - und zwar mit gut dokumentierten Testprogrammen. Das fördert das Verständnis über die Sensorproblematik erheblich, und wenn es dann klappt, dann weiß man auch warum...

An den Testprogrammen hapert es derzeit noch.

Sonst aber ein großes Lob für die viele Arbeit, die Ihr Euch gemacht habt. Wenn ich darf - würde ich gern an einer Weiterentwicklung der Lib mitarbeiten...

Mitarbeiter sind immer herzlich willkommen. Dazu müßtest du dich als Entwickler bei Sourceforge anmelden und mir deinen Entwicklernamen per PN zukommen lassen. Dann kann ich dich als Entwickler zur Asuro Lib eintragen.

[Sternthaler]

Und was mir noch aufgefallen ist: Der 72kHz - Timer wurde auf 36kHz geändert. Leider steht nirgens WARUM?! Könntet Ihr mir das bitte erklären und dann auch in die Doku einfließen lassen. Das wäre Klasse.

Doch, es gibt folgenden Kommentar in der Doku: (Im Source asuro.c zur Funktion Init() geschrieben.)

Hinweis zur 36 kHz-Frequenz vom Timer 2
Genau diese Frequenz wird von dem Empfaengerbaustein benoetigt und kann
deshalb nicht geaendert werden.
In der urspruenglichen, vom Hersteller ausgelieferten LIB, war diese
Frequenz allerdings auf 72 kHz eingestellt. Durch eine geschickte
Umkonfigurierung durch waste konnte diese aber halbiert werden.
Sinnvoll ist dies, da der durch diesen Timer2 auch ausgeloesste Timer-
Interrupt dann nur noch die Haelfte an Rechenzeit in Anspruch nimmt.


Uff, da bin ich aber froh, dass das schon erledigt ist.

Was gemacht wurde, ist wie angedeutet etwas 'tricki':
Anstatt den Timer so zu programmieren, dass die HARDWARE bis zu dem vorgegeben Wert zählt, den Interrupt auslößt und dann den Zähler wieder initialisiert, wurde es so programmiert, dass in der Interrupt-Funktion zum Timer das Register TCNT2 um Hex 25 erhöht wird. Damit wird erreicht, dass das Taktverhältnis (An-/Aus-Zeit vom Port-Pin zur IR-Kommunikation) 50% bleibt. Ausserdem ist das Verhalten zum Wecheln genau dieses Port-Pins geändert worden.

Unterm Strich ist das Ausgangssignal am Port-Pin gleich geblieben. Nur wird, wie beschrieben, der Interrupt nur noch halb so oft aufgerufen.
That's all, ich hoffe das hilft.