Programmierbare Relaiskarte - Konfigurationsdaten Lesen/Speichern/Übertragen

[Daniel S. (cyber)]

Hallo,

ich sitze gerade an einem Projekt und steht vor dem Problem meine 
Konfiguration zu verwalten.

Bei dem Projekt handelt es sich um eine programmierbare Relaiskarte für 
meine Wohnzimmerwand.
Ich möchte mich hier ansich nicht über die Relaiskarte unterhalten 
sondern nur über die Software.


Es sind derzeit 8 Ausgänge die über eine Fernbedienung angesteuert 
werden. Hier sollen die Tasten aber programmiert werden ähnlich der 
Harmony von Logitech.

So kann ich also definieren wenn ich die Taste 1(DVD schauen) drücke das 
dann die ersten 3 Ausgänge geschaltet werden.

TV -> AN
AV -> AN
DVD -> AN

Der Rest der Ports soll entweder abgeschaltet oder unberücksichtigt 
bleiben.

Die Schaltung steht soweit, empfangen der IR-Signale und die UART 
(Senden/Empfangen) ebenfalls.

Das System wird am Computer angeschlossen. Nun kann ich eine neue Taste 
definieren. Drücke ich diese wird sie auf dem PC empfangen in Form von:

R:<Protokoll>:<Adresse>:<Command>;

Die Taste bekommt einen Namen geben wie oben geschrieben "DVD schauen" 
Dieser Name steht derzeit nur innerhalb der Konfiguration zur Verfügung. 
Später evtl. auch auf einem Display.

Jetzt kann ich noch definieren welchen Zustand die 8 Ausgänge einnehmen 
sollten:

0=OFF/1=ON/-=unberücksichtigt

Die Taste ist jetzt in der Konfigurationssoftware definiert und soll auf 
den Controller übertragen werden. Derzeit übertrage ich sie so:

C:<Name>:<Protokoll>:<Adresse>:<Command>:11100-00;

Die Zeilen haben immer eine Feste Länge.

Bis hier funktioniert es auch schon. Nun soll natürlich die 
Konfiguration auch irgendwie im Controller abgelegt werden. da würde 
sich ja nun der EEPROM anbieten. Aufgebaut ist es mit einem Mega8 also 
stehen mir 512Byte zur Verfügung. Eine Tastenzeile hat 40 Zeichen 
512/40=12 Somit könnte ich 12 Tasten speichern. Das ist mir eigentlich 
schon viel zu wenig. Denn Jeden Ausgang einzeln würde ja bedeuten das 
ich schon 8 von 12 belegt hätte und somit nur noch 4 für Kombinationen 
zur Verfügung hätte.


1. Die Frage ist erst einmal nach einer Möglichkeit genug Informationen 
speichern zu können. Ich könnte zwar die ":" weg lassen, da ich eine 
feste Länge habe aber das bringt mich ja auch nicht wirklich viel 
weiter.
Wäre es sinnvoll einen kleinen EEPROM anzusteuern mit mehr Speicher oder 
lieber eine Kleine SD-Karte? Eventuell ein ganz anderer Ansatz?
Dazu kommt das die Datenspeicherung natürlich kosten technisch nicht den 
Rest des Projektes übertreffen soll. Schaltung liegt derzeit bei rund 4€ 
ohne Relais.

2. So lange bin ich noch nicht bei den Mikrocontrollern, habe also noch 
ein wenig nachzuholen gerade in der Sprache C. Bin im Bereich 
Pascal/Delphi eher tätig.
Es wäre dann noch zu klären wie man es am ehesten umsetzt die Daten zur 
Laufzeit zu lesen. Ansatz aus meiner Erfahrung: Ich habe eine definierte 
Länge somit müsste ich den "Speicher" nach der Zeichenkette 
"<Protokoll>:<Adresse>:<Command>" durchsuchen und wenn diese passt die 
Zeile laden und die Ports setzen. Diese stehen ja auch immer an einer 
bestimmten Stelle vom Offset entfernt. Ich könnte es natürlich auch 
alles direkt im Programm definieren aber da geht mir echt die 
Flexibilität flöten die ich gerne hätte.
Mal eine Andere Konfiguration schnell ändern, die Fernbedienung 
austauschen, andere Tasten nutzen, es kommt ein Gerät hinzu, ein Gerät 
wird entfernt. Klar kommt das meiste eher selten vor aber es kann ja 
schon einmal vorkommen. Auch wenn für so etwas fürs Wohnzimmer mit 8 
Ports schon eine Menge ist, wäre es ja auch nicht auszuschließen das 
ganze über Schieberegister zu erweitern. Kleine Gimmicks mit 
irgendwelchen Lampen fürs Ambiente z.B. Oder ganz banal eine 
Urlaubssteuerung. Ich kenne heute noch Leute die irgendwelche 
Gerätschaften per Zeitsteuerung Schalten um den Schein zu erwecken als 
wären sie noch da…

Natürlich muss ich auch zugeben das ich mich eventuell ein wenig damit 
übernehme aber da muss ich nun durch :) Hoffe hier auch tatkräftige 
Unterstützung und Nachsicht wenn ich etwas nicht gleich kapiere oder es 
durch Delphi oder aber auch den PC anders gewohnt bin es umzusetzen.


Das Auslesen der gesamten Konfiguration wollte sich in einem Block 
setzen:

PC->µC: READ_CONF;
µC->PC: BEGIN_CONF;
        C:DVD Schauen:02:1234:0001:11100-00;
        C:TV         :02:1234:0002:10000-00;
        C:AV         :02:1234:0003:01000-00;
        C:Konsole    :02:1234:0002:00100-00;
        END_CONF;

Es soll zudem noch ein wenig Speicher über bleiben um eventuell später 
eine Uhr mit einzubauen, Sleep Timer, Display und nen WakeUp also 
Zeitgesteuert Ports schalten und USB…
Das ist aber nicht primär. Ggf. kommt dann noch ein größerer Controller 
ran. Erst sollte aber das Minimum funktionieren.


Kann mir jemand helfen hier eine akzeptable Lösung zu finden und hat 
evtl. auch noch etwas Nachsicht mit meinen C-Kenntnissen?

Gruß
Daniel

[Karl H. (kbuchegg)]

> Wäre es sinnvoll einen kleinen EEPROM anzusteuern mit mehr Speicher
> oder lieber eine Kleine SD-Karte? Eventuell ein ganz anderer Ansatz?

Vielleicht hab ich das ja auch missverstanden. Aber du musst ja nicht 
deine Konfiguration im Klartext, so wie du sie vom PC bekommst 
speichern. Weder im EEPROM noch im Arbeitsspeicher, mit der der Mega 
dann im Endeffekt die Tasten auswertet.

Du hast 8 Ausgänge. Da bieten sich schon mal die 8 Bits eines Bytes als 
'Speicher' für jeweils einen Relais-Zustand an.

Genauso wie das hier

C:<Name>:<Protokoll>:<Adresse>:<Command>:11100-00;

Bis auf den Namen, reicht es doch, wenn der Mega aus der 
Tasteninformation eine Zahl von 0 bis n macht, mit dieser Zahl dann in 
ein Array geht und sich aus dem Array 2 Bytes rausholt, in denen 
bitmässig codiert ist, welches Relais zu setzen bzw. rückzusetzen sind 
und dann genau diese Ausgänge schaltet.

So ganz klar ist mir nicht, was da jetzt das Problem ist. Aber mir 
scheint du speicherst dir viel zu viele nutzlose Information auf dem 
Mega in Klartext-Form.

[Daniel (Gast)]

Guten morgen,

naja bei den Ausgängen habe ich ja 3 Zustände OFF/ON/Status beibehalten.

Beispiel: Ich möchte DVD schauen und drücke die Taste 1. Ich habe vorher 
aber das Licht angeschaltet welches auf Port 5 und 6 liegt. Diese darf 
ich also nicht berühren. Wenn das Licht an ist, soll es an bleiben und 
wenn es ausgeschaltet ist dann soll es auch ausgeschaltet bleiben.

Ich glaube es ist ein Verständnisproblem.

Wenn ich die IR Daten im original Speicher werden 5 Bytes genutzt 
anstatt 10 aber selbst das bringt mich ja auch nicht so weit das ich n 
Möglichkeiten speichern kann.

Zudem wollte ich nicht den ganzen kram hin und her Konvertieren. Mag 
sein das ich da vielleicht noch defiziete habe weil ich mich um so etwas 
nie kümmern musste.

[Karl H. (kbuchegg)]

Daniel schrieb:
> Guten morgen,
>
> naja bei den Ausgängen habe ich ja 3 Zustände OFF/ON/Status beibehalten.

Deswegen ja auch 2 Bytes.
ON_Byte: In dem Byte besagt ein 1 Bit, dass das zugehörige Relais auf 
ein zu schalten ist.
OFF_Byte: Im diesem Byte besagt ein 1 Bit, dass das zugehörige Relais 
auf aus zu schalten ist.

Ein 0 Bit in beiden Bytes besagt: lass dieses Relais in Ruhe.


Wenn du die 8 Relais an einem Port beisammen hast, dann geht das 
schalten aller 8 Relais in einem Aufwasch dann ganz einfach

   Relaisport = ( Relaisport | ON_Byte ) & ( ~ OFF_Byte );

fertig. Alle 8 Relais werden laut Vorgabe im ON_Byte bzw. OFF_Byte 
geschaltet.
Ist im ON_Byte ein 1 Bit wird der AUsgang auf 1 geschaltet. Ist im 
OFF_Byte ein 1 Bit, wird das Relais ausgeschaltet. Ist in beiden ein 0 
Bit dann verändert dieser eine Ausgang seinen Zustand nicht.

Wie du das ganze über die UART überträgst, ist damit ja nicht gesagt. 
Lass ruhig die Textübertragung. Dagagen hab ich sicher nichts 
einzuwenden. Aber speichern musst du das ganze nicht als Text, wenn du 
mit 2 Bytes dieselbe Information genausogut speichern kannst. Dann muss 
eben der Empfangscode, der das ganze dann im EEPOM speichert den Text 
auswerten und die beiden Bytes zurechtbasteln.
Darum gehts mir. Ich hatte in deinem Eröffnungsposting den Eindruck, 
dass dir dieser letzte Punkt nicht so recht klar ist.


> Zudem wollte ich nicht den ganzen kram hin und her Konvertieren
Ähm. Du musst diesen Text aber so und so irgendwann mal auswerten. Ob du 
den Text jetzt beim Drücken einer Taste auseinanderklamüserst um zu 
sehen, welches Relais wie zu schalten ist, oder ob du den prinzipiell 
identischen Code nach dem Erhalt des Konfigurationstextes über die UART 
laufen lässt und das Ergebnis davon in einer Form abspeicherst, so dass 
sie
a) weniger Platz braucht
b) beim Tastendruck dann trivial auszuwerten ist
ist doch gehupft wie gesprungen. Den Text analysieren bleibt dir so und 
so nicht erspart. Der einzige Unterschied besteht darin, wann genau 
diese Analyse stattfindet: Nachdem der Konfigurationsstring übertragen 
wurde ODER nachdem ein Tastendruck festgestellt wurde.

Und seien wir uns mal ehrlich. So kompliziert ist die Analyse eines 
Strings "11100-00" dann auch wieder nicht

void ConvertToOnOffByte( const char* str, uint8_t* InfoOn, uint8_t* InfoOff )
{
  uint8_t i;

  *InfoOn = 0;
  *InfoOff = 0;

  for( i = 0; i < 8; i++ )
  {
    if( *str == '1' )
      *InfoOn|= 0x01;
    else if( *str == '0' )
      *InfoOff |= 0x01;

    *InfoOn <<= 1;
    *InfoOff <<= 1;
    str++;
  }
}

Fertig. Das schreibt sich schneller als es sich textuell erklärt.

Für die Speicherung der Information zu einer Taste noch ein schönes 
struct gebaut

#define MAX_KEY_NAME_LEN 20

struct keyInfo_
{
  char    name[MAX_KEY_NAME_LEN];
  uint8_t keyCode;
  uint8_t infoOn;
  uint8_t infoOff;
};

daraus dann ein Array für alle Tasten, ein entsprechender Code, der aus 
den Informationen von der Fernsteuerung einen Tastencode errechnet und 
die ganze Sache ist soweit abgesteckt, dass man es erfolgversprechend 
zum laufen kriegt.

pro Taste 23 Byte, macht bei 512 Byte 22 Tasten. Wenn das zu wenig ist, 
dann bleibt nur noch die Namenslänge abzuspecken. Kommt man anstelle von 
19 Zeichen auch mit 9 Zeichen für den Namen aus, dann sind es schon 39 
Tasten, die ins 512-Byte EEPROM passen. Und das ist dann ja doch schon 
eine Menge Holz auf einer Fernbedienung. Wenn man es ein wenig geschickt 
anstellt, kann man den keyCode auch noch einsparen, indem man direkt aus 
den Informationen, die man von der Fernbedienung kriegt, einen 
Arrayindex errechnet, und wir sind bei 42 Tasten maximal.

[Daniel (Gast)]

Jetzt hat es in meinem Hirn scheinbar auch klick gemacht.

Wenn ich das Obige Beispiel aufgreife, nur zum Verständnis:
11100-00 würde ON_Byte = E0 und OFF_Byte = 1B werden, so ist das doch 
gemeint oder?

Das würde bedeuten ich hätte pro Datensatz 6Byte gespart. Wenn ich nun 
vom IRMP das Protokoll(1Byte), Adresse(2Byte) und Command(2Byte) nutze 
habe ich wirklich einiges gespart. Also 7Byte für IR+Ports und dann ein 
paar für den Namen.
Wenn ich für den Namen dann 17 Zeichen lasse komme ich auf 21 
Datensätze.
Sind schon einmal 9 mehr aber irgendwie noch zu wenig. Wenn ich die 8 
Ports einzeln schalte bleiben noch 13. Eine Taste für Alles aus, bin ich 
bei 12.

Mein Kopf sagt mir das sollte bei weitem ausreichen. Mein Herz möchte 
gerne mehr, gerade wenn für Erweiterungen noch Platz sein soll, z.B. 
weitere 8 Ports für ein Licht Spiel... Ist aber denke ich erst einmal 
Nebensache.

Ich brauche also nun eine Funktion die mit aus den 8 Zeichen jeweils das 
On und das OFF-Byte erzeugt. Zudem eine weitere Funktion die Zeichen in 
uint8_t und uint16_t wandelt. Natürlich noch eine die mir einen 
Substring aus dem String herausholt.

Ich merke schon die Defizite wenn man es nur gewohnt ist auf einem PC zu 
programmieren. Das fällt einem wesentlich leichter, zumal C nicht gerade 
zu meinem Sprachgebrauch gehört. Hätte damals was anständiges lernen 
sollen ;)

Korrigiert mich wenn ich hier falsch denke, ist alles Neuland für mich.
Bleibt noch die Frage wie ich das am besten im EEPROM suche.
Eine Taste wird gedrückt. Es wird mit das Protokoll, Adresse und Command 
übergeben.
Protokoll ist 02; Adresse BF40; Command 0002.
Nun gehe ich an die erste Adresse + 17Bytes im EEPROM und prüfe die 
ersten 5Bytes. Passen diese lese ich die nachfolgenden 2Bytes aus zum 
setzen der Ports. Sollte das nicht passen gehe ich weitere 24Bytes 
weiter und Prüfe wieder 5Bytes bis ich etwas passendes gefunden habe 
oder ins leere laufe.
Ich habe gelesen das der Zugriff auf den EEPROM relativ langsam ist und 
eine Suche innerhalb auch nicht gerade das beste sein soll. Ist das 
überhaupt dann performant so vorzugehen?

Mein erstes Projekt war ein Belichtungstimer. der ist dagegen ja echt 
ein Kinderspiel...

[Daniel (Gast)]

Da war ich wohl zu langsam und es beantwortet sich schon etwas.

Das mit dem KeyCode der Fernbedienung ist mir allerdings noch nicht so 
ganz klar. Ich nutze das IRMP. Protokoll könnte ich wohl raus lassen. 
Bisher haben alle meine Fernbedienungen das NEC Protokoll aber auf die 
Adresse würde ich schon gerne mit achten. Ich habe jetzt die Länge siehe 
oben vom Namen etwas kürzer aber dafür Protokoll, Adresse und Command 
mit drin.

[Karl H. (kbuchegg)]

Daniel schrieb:
> Jetzt hat es in meinem Hirn scheinbar auch klick gemacht.
>
> Wenn ich das Obige Beispiel aufgreife, nur zum Verständnis:
> 11100-00 würde ON_Byte = E0 und OFF_Byte = 1B werden, so ist das doch
> gemeint oder?

Mal sehen. In 11100-00 ist codiert

On    11100000
Off   00011011

Also: 0xE0 bzw. 1B.  Jep. Stimmt.


> Das würde bedeuten ich hätte pro Datensatz 6Byte gespart. Wenn ich nun
> vom IRMP das Protokoll(1Byte),

Brauchst du das wirklich?
Wenn die Fernsteuerung erst mal steht, ändert sich diese Information ja 
nicht.
Eine Fernsteuerung sendet immer mit einem Protokoll. Und zwar immer mit 
derselben.
Eine Phillips Fernsteuerung benutz ein anderes Protokoll als eine von 
Samsung. Und die wieder ein anderes Protokoll als eine Fernsteuerung von 
NEC. Aber derselbe Klotz, den du in der Hand hältst benutzt immer das 
gleiche Protokoll.

> Adresse(2Byte) und Command(2Byte) nutze

Ach da würde ich mir mal ansehen, in welchem Zahlenbereich sich da die 
Werte bei deiner konkreten Fernbedienung bewegen. Da geht sicher was. 2 
Byte pro Teilbereich sind viel Holz. Adresse ist normalerweise das 
'Gerät'. Hast du wirklich 65535 unterschiedliche Geräte? Oder sind es 
konzeptionell dann doch eher maximal 4 (also 2 Bit anstelle von 2 Byte). 
Hast du wirklich 65536 unterschiedliche Kommandos oder bewegt sich diese 
Zahl dann doch eher im Zahlenraum 0 bis 127? Oder gar 0 bis 63, was 
vorteilhaft wäre, dann das wären dann nur 6 Bit. Zusammen mit den 2 BIt 
von der Geräteadresse macht das wieder 8 Bit und das wäre dann perfekt 
um in einem einzelnen uint8_t zusammengefasst zu werden. Konzeptionell 
maximal 4 Geräte mit jeweils 64 unterschiedlichen Kommandos - das sollte 
auch den verwöhntesten Ansprüchen der nächsten Jahre mehr als genügen. 
Zur Not muss man eben die einzelnen Bits eindeutig machen. Das kann man 
aber erst sagen, wenn man sich mal angesehen hat, was deine 
Fernbedienung eigentlich wirklich konkret liefert, wenn man eine Taste 
(jede Taste) mal drückt und sich ansieht, was da daher kommt.


> Mein Kopf sagt mir das sollte bei weitem ausreichen. Mein Herz möchte
> gerne mehr, gerade wenn für Erweiterungen noch Platz sein soll, z.B.
> weitere 8 Ports für ein Licht Spiel... Ist aber denke ich erst einmal
> Nebensache.

Es gibt ja immer noch Tastenkombinationen.
Denk an die alten Taschenrechner. Da gibt es eben eine Taste, die in die 
zweite Bedieneben schaltet. Aus der Tastenfunktion x^2 wird so mal ganz 
schnell sqrt(x). Und aus sin(x) wird dann sin-1(x), aus exp(x) wird ein 
ln(x), einfach indem man vorher die Taste INV drückt (oder wie auch 
immer die auf deinem Taschenrechner heißt). Spricht ja nichts dagegen, 
dass du eine Taste 'Lichtprogramm' hast, die du drückst, dann noch eine 
Zahlentaste 0 bis 9 hinterher und du hast aus 10 Lichtprogrammen eines 
ausgewählt, obwohl die Tasten 0 bis 9 eigentlich eine ganz andere 
Bedeutung haben (zb Einzelrelaisansteuerung)


Du denkst mir da zu eindimensional. Sieh dich in deiner Umgebung um. Man 
kann viel lernen, indem man beobachtet, wie andere Dinge machen. Und 
plötzlich geht einem dann oft sogar ein Licht auf, WARUM die das genau 
so gemacht haben.

[Karl H. (kbuchegg)]

> Nun gehe ich an die erste Adresse + 17Bytes im EEPROM
> und prüfe die ersten 5Bytes. Passen diese lese ich die
> nachfolgenden 2Bytes aus zum setzen der Ports. Sollte das
> nicht passen gehe ich weitere 24Bytes weiter und Prüfe wieder
> 5Bytes bis ich etwas passendes gefunden habe oder ins leere laufe.

Machs doch nicht so komplizert.
Was interessieren dich da Bytezahlen?

Wenn ein Benutzer eine Taste drückt, reicht es, wenn die Schaltung ein 
paar Hunderstel Sekunden später reagiert. Du hast alle Zeit der Welt. 
Für einen Menschen ist das immer noch praktisch 'sofort'.

> Bleibt noch die Frage wie ich das am besten im EEPROM suche

Indem du dir einen Datensatz nach dem anderen ins SRAM holst (daher auch 
der struct) und dann vergleichst

uint8_t keyInfoSize EEMEM = 0;
struct  keyInfo_ eemem_KeyDesc[22] EEMEM;


uint8_t nrKeysInEEPROM;   // wieviele sind befüllt? (Wird bei Programmstart aus dem EEPROM geholt)


uint8_t searchKey( uint8_t code, struct keyInfo_* pFound )
{
  struct keyInfo_ keyDesc;

   for( uint8_t i = 0; i < nrKeysInEEPROM; i++ )
   {
     eeprom_read_block( &keyDesc, &eemem_KeyDesc[i], sizeof( keyDesc ) );
     if( keyDesc.keyCode == code )
     {
       *pFound = keyDesc;
       return TRUE;
     }
   }

   return FALSE;
}

[Daniel (Gast)]

Karl Heinz Buchegger schrieb:
> Du denkst mir da zu eindimensional. Sieh dich in deiner Umgebung um. Man
> kann viel lernen, indem man beobachtet, wie andere Dinge machen. Und
> plötzlich geht einem dann oft sogar ein Licht auf, WARUM die das genau
> so gemacht haben.

Das stimmt leider...

Zum Speichern der IR-Daten. Natürlich habe ich nicht so viele Commandos 
und auch nicht so viele Geräte. Ich habe aber daheim eine RGB LED Kette. 
Diese reagiert z.B. auf die Fernbedienung von sich selbst, auf die 
meines Verstärkers und die meines Receivers. Sie wird also sicher nur 
das Commando auswerten. Ich müsste also nun im Source Protokoll und 
Gerät festlegen. Oder aber auch im EEPROM damit ich mal die 
Fernbedienung tauschen kann. Das ist mir wichtig. Es werden hier 2 
Schaltungen gebaut. Eine für einen Kollegen und eine für mich. Ich würde 
him nun ungerne vorschreiben was er für eine Fernbedienung zu nutzen 
hat.

Dann wäre ich dafür damit ich da relativ flexibel bin diese Daten im 
EEPROM ebenfalls abzulegen. Einmal das Protokoll und das Gerät. Diese 
aber eben separat und nicht mit im Struct der IR-Codes. Damit habe ich 
da zumindest die Freiheit auch mal die Fernbedienung zu ändern.

Bin gerade auf der Arbeit und kann natürlich nicht nachsehen was diese 
Fernbedienung so alles aufgibt. es ist von meinem TV, die ich derzeit 
angeschlossen habe. Da soll natürlich mal eine eigene hin.

Der Ansatz mit der Doppelbelegung ist nicht schlecht aber dann muss ich 
natürlich hier am Source so abändern dass dann neben Den Ports auch eine 
Art Shift Funktion zur Verfügung steht. Die Fernbedienung die ich nutzen 
möchte später hat ca. 40 Tasten und ist von meinem alten AMP. Da brauch 
man nicht unbedingt eine Shift Funktion. Tasten wären zu genüge 
vorhanden.

Wäre allerdings noch das Auslesen auf dem EEPROM.

[Karl H. (kbuchegg)]

> Ich habe gelesen das der Zugriff auf den EEPROM relativ langsam ist

Langsam ist relativ.
Für einen µC ist es langsam. Für einen Menschen ist es immer noch 
schnell.
Denn aus Sicht eines µC sind wir 
schnarch-langsame-super-zeitlupen-Säcke.

Und wenn es dann tatsächlich zu langsam ist, dann gibt es auch dann noch 
Mittel und Wege :-)
Zb mit einem Index im Speicher. zb. durch aufsteigendes Sortieren und 
binäre Suche. Zb durch Hashing. zb durch ....

Aber erst mal: implementier es so, dass es leicht zu lesen und zu 
verstehen ist. Und DANN siehst du dir an, ob es zu langsam im Gebrauch 
ist. Optimier nicht, solange nicht feststeht, dass du überhaupt 
optimieren musst. Erst mal ist es viel wichtiger ein korrektes Programm 
zu haben. Ein korrektes Programm welches zu langsam ist, ist immer noch 
nützlich. Ein schnelles Programm, welches nicht korrekt funktioniert ist 
hingegen zu gar nichts zu gebrauchen.

[Karl H. (kbuchegg)]

Daniel schrieb:

> Wäre allerdings noch das Auslesen auf dem EEPROM.

Siehe den Post unmittelbar vor deinem :-)

[Daniel (Gast)]

Du bist ja verdammt schnell, da komm ich mit den Fragestellungen ja gar 
nicht mehr nach und meist sind die dann schon beantwortet. :)

Die Hilfe ist mal echt klasse auch wenn ich mir dabei gerade sehr klein 
vorkomme.

Kann den Feierabend ja schon nicht mehr abwarten. :)

Werde das bis zum Feierabend auf mich wirken lassen und dann versuch ich 
es so umzusetzen.

Ich bedanke mich schon einmal vorab für die große Hilfe die du geleistet 
hast und auch die Geduld.

Klasse Forum :)

[Daniel (Gast)]

Hab mir mal schnell in C das ganze kopiert und getestet.
In der Convert Funktion ist ein kleiner Fehler drin. Nachdem die 8 Ports 
gelesen sind wird erneut eine Bit Verschiebung gemacht wodurch das erste 
Bit weg fällt.

void ConvertToOnOffByte( const char* str, unsigned char* InfoOn, unsigned char* InfoOff )
{
  int i;

  *InfoOn = 0;
  *InfoOff = 0;

  for( i = 0; i < 8; i++ )
  {
    if( *str == '1' )
      *InfoOn |= 0x01;
    else if( *str == '0' )
      *InfoOff |= 0x01;

    if (i < 7)
    {
      *InfoOn <<= 1;
      *InfoOff <<= 1;
      str++;
    }
  }
}

Ist mit C darum kein uint8_t

Wo ich aber nun hänge ist es die Zeichenkette zu zerlegen. Ich tue mich 
verdammt schwer damit :(

Jetzt hat es geklappt nachdem ich die Terminierung weg gelassen habe am 
Anfang. Ich dachte ich könnte die Zeichenkette auf "" setzen

void ReadName(const char* str, char* strname)
{
  int i;
  //strname[0] = '\0';
  
  for (i = 2; i < 21; i++)
  {
    strname[i-2] = str[i];  
  }
  strname[i-2] = '\0';
}

Eine SubStr Funktion gibts ja so nicht. Ich müsste mir eine bauen. Bevor 
ich mich aber an so etwas setze, auch wenn sicher nur eine kleinigkeit 
ist, gehts auch schöner?

Jetzt kommt der Punkt an dem ich das Struct füllen muss... Graus...

[Karl H. (kbuchegg)]

Daniel schrieb:
> Hab mir mal schnell in C das ganze kopiert und getestet.
> In der Convert Funktion ist ein kleiner Fehler drin. Nachdem die 8 Ports
> gelesen sind wird erneut eine Bit Verschiebung gemacht wodurch das erste
> Bit weg fällt.

Schreib es dem Umstand zu, dass ich direkt hier drinnen 'programmiere' 
:-)

Aber wenn schon, dann bitte so.

void ConvertToOnOffByte( const char* str, unsigned char* InfoOn, unsigned char* InfoOff )
{
  int i;

  *InfoOn = 0;
  *InfoOff = 0;

  for( i = 0; i < 8; i++ )
  {
    *InfoOn <<= 1;
    *InfoOff <<= 1;

    if( *str == '1' )
      *InfoOn |= 0x01;
    else if( *str == '0' )
      *InfoOff |= 0x01;

    str++;
  }
}

Da muss man jetzt keinen 'Sonderfall' draus konstruieren :-)

[Karl H. (kbuchegg)]

Daniel schrieb:

> Eine SubStr Funktion gibts ja so nicht.

Na ja. Kann man schon machen.
Aber typischerweise 'zerlegt' man einen String nicht dadurch, dass man 
Teilstrings durch die Gegend kopiert, sondern indem man sich Pointer 
mitten in den String hinein merkt. Bei dir geht das sogar ganz 
wunderbar, weil dein Original da diese ':' als Trenner hat, die man 
durch \0 ersetzen kann und dann entsprechende Teilstrings hat.
Und das beste am ganzen :-) : genau da schlägt dann die Stunde von 
strtok()

[Daniel (Gast)]

Tut mir leid, ich bin immer ein Sonderfall ;)
Habs aber begriffen.

War der Befehl nun ein Wink mit dem Zaunpfahl? :)

[Karl H. (kbuchegg)]

Daniel schrieb:
> Tut mir leid, ich bin immer ein Sonderfall ;)
> Habs aber begriffen.
>
> War der Befehl nun ein Wink mit dem Zaunpfahl? :)

Der Zaunpfahl-Balken ist eigentlich:
Du solltest in Betracht ziehen erst mal ordentlich C zu lernen, ehe du 
dich an reale Projekte wagst. Das hat doch keinen Sinn, wenn du von den 
Möglichkeiten deiner Programmiersprache gerade mal 10% beherrscht.


:-)

Aber natürlich hab ich den Zaunpfahl auch ausgearbeitet :-)
Brauch halt auch ein wenig Zeit dafür.

> Aber typischerweise 'zerlegt' man einen String nicht dadurch, dass
> man Teilstrings durch die Gegend kopiert, sondern indem man sich
>  Pointer mitten in den String hinein merkt. Bei dir geht das sogar
> ganz wunderbar, weil dein Original da diese ':' als Trenner hat,
> die man durch \0 ersetzen kann und dann entsprechende Teilstrings
> hat.
> Und das beste am ganzen :-) : genau da schlägt dann die Stunde
> von strtok()


(ohne Fehlerbehandlung)

  char Answer[80] = "C:<Name>:<Protokoll>:<Adresse>:<Command>:11100-00;"

  char * Drive;
  char * Name;
  char * Protocoll;
  char * Address;
  char * Command;
  char * Bits;


  Drive     = strtok( Answer, ":" );
  Name      = strtok( NULL, ":" );
  Protocoll = strtok( NULL, ":" );
  Address   = strtok( NULL, ":" );
  Command   = strtok( NULL, ":" );
  Bits      = strtok( NULL, ";" );

das baut dir dann das hier auf

  Answer
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
  |C|0|<|N|a|m|e|>|0|<|P|r|o|t|o|k|o|l|l|>|0|<|A|d|r|e|s|s|e|>|0|<|...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
   ^   ^               ^                     ^                   ^
   |   |               |                     |                   |
   |   |               |                     |                   |
 Drive |            Protocoll            Address              Command
      Name

(wobei die 0 in der Zeichnung als die C-String Nullterminierung \0 zu 
lesen ist)

jeder Pointer zeigt auf den Beginn eines 0-terminierten Strings.

Nichts wird stringmässig umkopiert. Lediglich ein paar ':' sind gegen 
'\0' ausgetauscht worden (und natürlich auch der ; zum Schluss, was in 
der Zeichnung nicht sichtbar ist).
Alles perfekt um die Funktion

     ConvertToOnOffByte( Bits, &On, &Off );

damit aufrufen zu können, bzw. den Namen in eine STruktur kopieren zu 
können

    ....

   struct keyInfo_ nextInfo;

 ...
   Drive     = strtok( Answer, ":" );
   Name      = strtok( NULL, ":" );
   Protocoll = strtok( NULL, ":" );
   Address   = strtok( NULL, ":" );
   Command   = strtok( NULL, ":" );
   Bits      = strtok( NULL, ";" );
 ...

   strcpy( nextInfo.name, Name );
   ConvertToOnOffByte( Bits, &nextInfo.infoOn, &nextInfo.infoOff );
  ...

[Daniel (Gast)]

Verdammt so schnell kann ich mir die Funktion ja schon fast nicht mehr 
selber anschauen.

Wollte aber sagen, mein Beispiel funktioniert auch, auch wenn es nicht 
so spektakulär ist.

 char MyData[35] = "C:Name der Taste    1:0001:11100-00;";
  char * pch;
  pch = strtok (MyData,":");
  while (pch != NULL)
  {
    printf ("%s\n",pch);
    pch = strtok (NULL, ":");
  }

Verdammt so schnell kann ich mir die Funktion ja schon fast nicht mehr 
selber anschauen.

Wollte aber sagen, mein Beispiel funktioniert auch, auch wenn es nicht 
so spektakulär ist

[Karl H. (kbuchegg)]

> Ist mit C darum kein uint8_t


Doch!

Du willst da einen uint8_t haben!
Brauchst doch nur stdint.h inkludieren und du hast diese Datentypen.

Und wenn nicht (weil dein Compiler zu alt ist), dann machst du dir eben 
welche

typedef unsigned char uint8_t;

[Daniel (Gast)]

Cool danke. Habs nun drin.

Schade das mein Urlaub gerade vorbei ist.

[Daniel S. (cyber)]

Dann will ich mal ein wenig meines Fortschritts zeigen.

Hab es mit dem EEPROM noch nicht drin, musste mich erst einmal richtig 
in den Source denken.
Die Zeile die ich mittels UART zum setzen der Konfiguration übergebe 
habe ich so angepasst das diese ins struct gesetzt wird und dann die 
Ports setzt. Das klappt auch wunderbar.

Hier wird das Struct, Protokoll und Adresse zugewiesen

void BuildStruct(char* Line, struct keyInfo_* pFound, uint8_t* Prt, uint16_t* Adr)
{
  struct keyInfo_ keyDesc;
  char * Comm;
  char * Name;
  char * Protocoll;
  char * Address;
  char * Command;
  char * Bits;
  uint8_t iProtocoll;
  uint16_t iAddress;
  uint16_t iCommand;

  Comm       = strtok( Line, ":" );
  Name       = strtok( NULL, ":" );
  Protocoll  = strtok( NULL, ":" );
  iProtocoll = strtol(Protocoll, NULL, 16);
  Address    = strtok( NULL, ":" );
  iAddress   = strtol(Address, NULL, 16);
  Command    = strtok( NULL, ":" );
  iCommand   = strtol(Command, NULL, 16);
  Bits       = strtok( NULL, ";" );

  strcpy(keyDesc.name, Name);
  memcpy(&keyDesc.keyCode, &iCommand, sizeof(uint16_t));
  ConvertToOnOffByte( Bits, &keyDesc.infoOn, &keyDesc.infoOff );

  *pFound = keyDesc;
  *Protocoll = iProtocoll;
  *Adr = iAddress;
}

Hier meine UART Empfangroutine:

  if (uart_data_received())
    {
  temp = uart_getc();
      
  if (temp == ';' || StringLen > 45) 
  {
    Line[StringLen] = '\0';
    uart_puts(Line);
    uart_puts("\r\n");

    if (Line[0] == 'P')
    {
       uart_puts("Received Dataset\n\r");

       char buf[5];
       uint8_t iProtocoll;
       uint16_t iAddress;
       struct keyInfo_ nextInfo;
       BuildStruct(Line, &nextInfo, &iProtocoll, &iAddress);
  
       uart_puts("Name: ");
       uart_puts(nextInfo.name);
       uart_puts("\r\n");
       uart_puts("Protokoll: ");
       itoa (iProtocoll, buf, 16);  
       uart_puts(buf);
       uart_puts("\r\n");
       uart_puts("Adresse: ");
       itoa (iAddress, buf, 16);
       uart_puts(buf);
       uart_puts("\r\n");
       uart_puts("Command: ");
       itoa (nextInfo.keyCode, buf, 16);
       uart_puts(buf);
       uart_puts("\r\n");

       OUT_PORT = ( OUT_PORT | nextInfo.infoOn ) & ( ~ nextInfo.infoOff );
    }

    StringLen = 0;
    Line[0] = '\0';
    uart_puts("CLEAR");
    uart_puts("\r\n");

  }

  if (temp != ';')
  {
    Line[StringLen] = (unsigned char)temp;
    StringLen++;
  }
}

Damit habe ich das Stuct, Protokoll und die Adresse.
Das setzen der Ausgänge funktioniert ebenfalls wenn ich die Line ändere.

Muss jetzt noch an dem Übertragungsprotokoll arbeiten um die ersten drei 
Bytes zu setzen im EEPROM für Protokoll und Gerät und dann das Auslesen 
und Speichern der Daten. Ein weiteres Byte für die Anzahl der 
Datensätze.

Ich danke dir für die Hilfe, bin Stolz das es mit deiner Hilfe bis hier 
hin so gut klappt. Ist spät und ich muss so langsam ins Bett, leider...


Ja mit C habe ich echt meine Probleme. Vieles von der Stringverarbeitung 
übernimmt die Pascal IDE bereits für mich. Wenn man allerdings sucht 
aber nicht die passenden Suchwörter findet läuft man leider leicht ins 
leere. Als nächstes steht ein vernünftiges C Buch auf meiner Liste.
Freue mich allerdings das mir dennoch so gut geholfen wird.

[Karl H. (kbuchegg)]

Den Umweg über eine locale struct Variable kannst du dir sparen und den 
memcpy will ich jetzt erst mal nicht gesehen haben :-)

void BuildStruct(char* Line, struct keyInfo_* pFound, uint8_t* Prt, uint16_t* Adr)
{
  char * Comm;
  char * Name;
  char * Protocoll;
  char * Address;
  char * Command;
  char * Bits;
  uint8_t iProtocoll;
  uint16_t iAddress;
  uint16_t iCommand;

  Comm       = strtok( Line, ":" );
  Name       = strtok( NULL, ":" );
  Protocoll  = strtok( NULL, ":" );
  Address    = strtok( NULL, ":" );
  Command    = strtok( NULL, ":" );
  Bits       = strtok( NULL, ";" );

  *Prt       = strtol( Protocoll, NULL, 16 );
  *Adr       = strtol( Address, NULL, 16 );

  iCommand   = strtol( Command, NULL, 16 );

  strcpy( pFound->name, Name);
  pFound->keyCode = iCommand;
  ConvertToOnOffByte( Bits, &pFound->infoOn, &pFound->infoOff );
}

Die Pointer Variablen könnte man allesamt wegoptimieren, wenn man auf 
Fehlerbehandlung verzichtet, was bei einem maschinell erzeugtem String 
durchaus drinnen ist.

void BuildStruct(char* Line, struct keyInfo_* pFound, uint8_t* Prt, uint16_t* Adr)
{
  strtok( Line, ":" );
  strcpy( pFound->name, strtok( NULL, ":" ) );
  *Prt            = strtol( strtok( NULL, ":" ), NULL, 16 );
  *Adr            = strtol( strtok( NULL, ":" ), NULL, 16 );
  pFound->keyCode = strtol( strtok( NULL, ":" ), NULL, 16 );
  ConvertToOnOffByte( strtok( NULL, ";" ), &pFound->infoOn, &pFound->infoOff );
}

wird schon.

  if (temp == ';' || StringLen > 45)

wie ist Line definiert?
Ich hoffe mal für dich als

  char Line[47];

und nicht als Array der Länge 46 oder kleiner. Denn sonst greift deine 
Sicherheitsabfrage ins Leere um hier

    Line[StringLen] = '\0';

schlimmeres zu verhindern.

Solche magischen Zahlen mitten im Code sind schlecht. Entweder man macht 
sich ein entsprechendes #define mit einer konstanten Zahl dafür, oder 
man arbeitet gleich mit sizeof. Dann sucht sich der Compiler selbst die 
Größe des Arrays raus.

#define ARRAY_LEN(x) (sizeof(x) / sizeof(*x))

  if (temp == ';' || StringLen > ARRAY_LEN - 2 )
  {
    ...

[Daniel (Gast)]

Guten morgen,

Warum müssen es 47 sein? Ich dachte die Terminierung ist nur ein 
Zeichen. 45 Zeichen + '\0' sollten dann doch 46 sein?

 Line[StringLen] = '\0';

Hier ist StringLen = 46.
Mit der Konstanten geb ich dir allerdings recht. Bisher ist das eben 
alles noch ein Versuchs Source. Wie gesagt ist eigentlich erst mein 
zweites Projekt abgesehen von LEDs blinken zu lassen und auf Tasten zu 
reagieren sowie ein paar Timer.
Als ich das Projekt angefangen habe, hatte ich die Ausmaße noch nicht im 
Kopf. Jetzt wird mir schon klar das es etwas umfangreicher ist. Anfangs 
sollten auch keine Keys über die Software programmiert werden.

[Daniel (Gast)]

OK.. Ja verstanden... Mein Fehler Es sind 47

[Daniel S. (cyber)]

Mir scheint mit dem EEPROM stehe ich echt auf Kriegsfuß...

Ich darf mir sicher gleich wieder etwas anhören aber da muss ich dann 
wohl durch...

Warum erwartet eeprom_write_byte als Adresse ein uint8_t aber 
eeprom_write_word ein uint16_t?
Block nen Void....

Ich kann ein Byte, Word und Stuct speichern/lesen aber schlau werde ich 
da nicht wirklich draus.

        if (strcmp(Line, "READ") == 0)
        {
          eeprom_read_block((void*)StringOfData, (const void*)12, 10);
          uart_puts("Line: ");
          uart_puts(Line);
          uart_puts("\r\n");
          uart_puts("READ from EEPROM: ");
          uart_puts(StringOfData);
          uart_puts("\r\n");
        }

        if (strcmp(Line, "WRITE") == 0)
        {
          char StringOfData[10] = "Test\0";
          eeprom_write_block((const void*)StringOfData, (void*)12, 10);
          uart_puts("Line: ");
          uart_puts(Line);
          uart_puts("\r\n");
          uart_puts("WRITE to EEPROM: ");
          uart_puts(StringOfData);
          uart_puts("\r\n");
        }


        if (strcmp(Line, "R") == 0)
        {
          uint8_t MyByte;
          char buf[10];
          MyByte = eeprom_read_byte((uint8_t*)0);
          //eeprom_read_block((void*)StringOfData, (const void*)12, 10);
          uart_puts("Line: ");
          uart_puts(Line);
          uart_puts("\r\n");
          uart_puts("READ from EEPROM: ");
          //uart_puts(StringOfData);
          sprintf(buf, "%x", MyByte);
          uart_puts(buf);
          uart_puts("\r\n");
        }

        if (strcmp(Line, "W") == 0)
        {
          uint8_t MyByte;
          char buf[10];
          //char StringOfData[10] = "Test\0";
          //eeprom_write_block((const void*)StringOfData, (void*)12, 10);
          MyByte = 0xEE;
          eeprom_write_byte((uint8_t*)0, MyByte);
          uart_puts("Line: ");
          uart_puts(Line);
          uart_puts("\r\n");
          uart_puts("WRITE to EEPROM: ");
          //uart_puts(StringOfData);
          sprintf(buf, "%x", MyByte);
          uart_puts(buf);
          uart_puts("\r\n");
        }

Bitte nicht auf das strcmp achten, das ist nur zum testen. In meinem C 
Programm habe ich das schon abgeändert. Dort hole ich mir den ersten 
Teilstring mit Hilfe vom Index des ':' und kopiere dann mit strncpy den 
Bereich heraus, damit ich nicht einen falschen Befehl interpretiere.

Im Programm soll es ja bisher so aussehen an der ersten Adresse steht 
das genutzte Protokoll gefolgt vom Gerät, danach folgt nrKeysInEEPROM. 
Damit sollten die ersten 5 Bytes beschrieben sein. Ab da also Adresse 4 
folgen dann die Tasten.

Die Adresse wäre dann doch eemem_KeyDesc[i] + mein Offset.

struct  keyInfo_ eemem_KeyDesc[22] EEMEM;

Die Zeile verstehe ich so das insgesamt 22 Adressen existieren die einen 
Abstand in der Größe des Structs haben.

Gibt es die Möglichkeit so etwas zu testen direkt in C bzw. ohne den 
EEPROM des Controllers zu belasten?

[Daniel (Gast)]

Hallo,

bin leider gestern nicht zum Programmieren gekommen aber es steht ja nun 
das Wochenende an, dann gehts weiter.

Habe mir allerdings überlegt das es unsinnig ist den Tasten Namen zu 
geben. Selbst wenn ich irgendwann mal ein Display anschließen sollte 
sehe ich das von der Couch aus eh nicht. Ich gebe also den Ports Namen. 
Diese können dann auch kleiner ausfallen, da ja ein gerät dich eine 
recht kurze Bezeichnung hat.

1 Byte Protokoll
2 Byte Gerät
40-80 Byte pro Port
1 Byte geschriebene Datensätze

Das macht dann 43-83 Byte und habe dann 429 - 469 Byte frei für die 
Konfigurationsdaten.
Ein Datensatz besteht dann nur noch aus 4Byte(2 Byte Adresse und 2 Byte 
für On/Off Byte). Damit habe ich dann nun doch eine verdammt große Menge 
die ich abspeichern könnte.
Da hätte ich auch eher drauf können kommen...

[Daniel S. (cyber)]

Guten Abend,

mittlerweile funktioniert schon ein wenig mehr.
Lesen / schreiben des IR-Systems
Lesen / schreiben der Portnamen inkl. Prüfung ob sie geschrieben sind
Lesen / schreiben Anzahl der Datensätze
 Auslesen aller Portnamen in einem durchlauf
die Struct wurde um ein Byte vergrößert für zusätzliche Informationen

Nun sitze ich gerade daran die Konfiguration in den EEPROM zu 
übertragen.

Auf Windows Seite existiert bisher ein recht einfaches Programm um die 
Informationen lesen und schreiben zu können.

Hier mal die Prozedur zum auslesen der Portnamen:

void CMD_Get_PortNames()
{
  uint8_t PortNum;
  uint16_t PortAddr = 0;
  char PortName[MAX_PORTNAME_LEN];
  char buf[6];  

  uart_puts("GET_PORTNAMES:BEGIN;\r\n");
  for (PortNum = 1; PortNum <= 8; PortNum++)
  {
    uart_puts("R:");
    itoa(PortNum, buf, 10);
    uart_puts(buf);
    uart_putc(':');

    PortAddr = CONF_PORTNAMES_START_ADDR + ((PortNum -1) * MAX_PORTNAME_LEN);
    PortName[0] = '\0';
    if (eeprom_read_byte((uint8_t*)PortAddr) != 0xFF)
    {
      eeprom_read_block((void*)PortName, (const void*)PortAddr, MAX_PORTNAME_LEN);
    }
    uart_puts(PortName);
    uart_puts(";\r\n");
  }
  uart_puts("GET_PORTNAMES:END;\r\n");
}

Hier noch ein kleiner Auszug aus meiner RS232 Empfangsroutine:

void WorkOnCommand()
{
  char temp;                                                              // Zeichen vom UART
  char Command[MAX_CMD_TOKEN_LEN];                                        // Befehlstoken
  uint8_t Index;                                                          // Index um den Befehlstoken zu identifizieren

  if (uart_data_received())                                                // Prüfen ob ein Zeichen empfangen wurde
  {
    temp = uart_getc();                                                    // Empfangenes Zeichen lesen

    if (temp == ';' || StringLen > MAX_COMMAND_LEN -2)                    // Wenn das Zeichen kein "Ende" ist oder die Länge überschreitet dann
    {
      Line[StringLen] = '\0';                                              // String terminieren 
      uart_puts("READ: "); uart_puts(Line); uart_puts("\r\n");            // Ausgabe der Empfangenen Befehlszeile

      Index = strcspn(Line, ":");                                          // Index des ersten Trenners suchen
      strncpy(Command, Line, Index);                                      // Aus der Zeile das Befehlstoken kopieren
      Command[Index] = '\0';                                              // string Terminieren

      if (strcmp(Command, "SET_PORTNAME") == 0)                            // Setzen des Portnamen
      {
        CMD_Set_PortName(Line);
      }

      if (strcmp(Command, "GET_PORTNAME") == 0)                            // Anzahl der Datensätze lese
      {
        CMD_Get_PortName(Line);
      }

      if (strcmp(Command, "GET_PORTNAMES") == 0)                          // Auslesen aller Portnamen
      {
        CMD_Get_PortNames();
      }

      if (strcmp(Command, "GET_CONFIG") == 0)                            // Auslesen der Konfiguration
      {
        CMD_Get_GetConfig();
      }

      StringLen = 0;
      Line[0] = '\0';
      uart_puts("\r\n");
    }

    if (temp != ';')
    {
      Line[StringLen] = (unsigned char)temp;
      StringLen++;
    }
  }
}

Natürlich habe ich mir mittlerweile auch 2 Bücher gekauft für C und die 
Programmierung der AVR-RISC Familie mit C.

[Daniel (Gast)]

Guten morgen,

Gestern liefen die ersten Tests mit dem SOurce auf dem Controller bis 
zum setzen der Ports. Da wurde ich dann auf dem "Es funktioniert" Effekt 
raus gerissen da sich irgend etwas aufgehangen hat am Controller.

Das ist meine Main.
Zuerst werden die Ports 2-7 für 1.5 Sekunden auf On gesetzt und dann 
deaktiviert(ist noch auf dem Anfang). Dann wird die UART inizialisiert. 
Danach das IRMP initialisiert, Die Callback LED und die Routine gesetzt.
Init_IR(); liest aus dem EEPROM das Protokoll und die Geräteadresse der 
Fernbedienung. WorkOnCommand(); fragt die UART Schnittstelle ab.

int main (void)
{
  OUT_DDR |= ((1 << OUT_1) | (1 << OUT_2) | (1 << OUT_3) | (1 << OUT_4) | (1 << OUT_5) | (1 << OUT_6));
  OUT_PORT |= ((1 << OUT_1) | (1 << OUT_2) | (1 << OUT_3) | (1 << OUT_4) | (1 << OUT_5) | (1 << OUT_6));
  _delay_ms(1500);
  OUT_PORT &= ~((1 << OUT_1) | (1 << OUT_2) | (1 << OUT_3) | (1 << OUT_4) | (1 << OUT_5) | (1 << OUT_6));

  uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) ); 
  IRMP_DATA irmp_data;

  struct keyInfo_ nextInfo;

  irmp_init();                                                            // initialize irmp
  
  LED_DDR |= (1 << LED_PIN);                                              // LED pin to output
  LED_PORT |= (1 << LED_PIN);                                              // switch LED off (active low)
  irmp_set_callback_ptr (led_callback);
  
  timer1_init();                                                          // initialize timer1
  sei ();                                                                 // enable interrupts

  uart_puts("IR Demo Programm\r\n");

  Init_IR();

  for (;;)                                                                // Endlosschleife
  {
    WorkOnCommand();                                                      // Einlesen und verarbeiten der RS232 Befehle

    if (irmp_get_data(&irmp_data))
    {

      if (irmp_data.flags & IRMP_FLAG_REPETITION)
      {
        // Benutzer hält die Taste länger runter entweder:
        // ich ignoriere die (Wiederholungs-)Taste oder:
        // ich benutze diese Info, um einen Repeat-Effekt zu nutzen
      }
      else
      {
        // Es handelt sich um eine neue Taste
        if (irmp_data.protocol == IR_Protocol && irmp_data.address == IR_Address)            // Nur Befehle verarbeiten wenn das IR-System stimmt
        {
          WriteIRDataToUART(irmp_data);

          if (searchKey(irmp_data.command, &nextInfo) == TRUE)
          {
            OUT_PORT = ( OUT_PORT | nextInfo.infoOn ) & ( ~ nextInfo.infoOff );
            uart_puts("Set Ports done\r\n");
          }
          else
          {
            uart_puts("Key not found\r\n");
          }
        }
      }
    }
  }
}

Soweit klappt es auch. Ich kann die Keys in den EEPROM schreiben und 
auch wieder auslesen. Drücke ich nun eine Taste auf der Fernbedienung 
die nicht gespeichert ist meldet er auch 'Key not found'.
Drücke ich die Taste 'Power' die gespeichert ist mit '--000000' meldet 
er auch 'Set Ports done'.
Drücke ich die Taste '1' mit '--000001' so wird der letzte Port gesetzt. 
Wird nun die Taste 'Power' gedrückt geht der Port auch wieder aus.
Drücke ich die Taste 'OK' mit '--110011' so gehen auch die 
entsprechenden Ports an und meldet auch hier wieder 'Set Ports done'. 
Nun fangen die Probleme an. Es werden keine Tasten mehr erkannt.

UART funktioniert noch, ich kann die Konfiguration abrufen und auch 
setzen. die callback für die IR Aktivität verrichtet auch noch ihren 
Dienst. Sie blinkt wenn ich die Fernbedienung betätige. Es wird aber 
eben kein IR Signal mehr ausgegeben. IRMP ist unverändert es ist nur das 
NEC Protokoll aktiv.
Ich muss dazu sagen das es sich hier um den PORT C handelt und da 
natürlich auch UART genutzt wird. Darum sind hier die ersten beiden Bits 
immer mit '-' gesetzt. Da er allerdings meldet 'Set Ports done' sollte 
dort ja nicht das Problem liegen. Die Main läuft ja ebenfalls noch, 
sonst würde UART ja nicht mehr funktionieren.

Wo könnte hier noch das Problem liegen?

Gruß Daniel

[Daniel S. (cyber)]

Wenn ich folgende Zeile auskommentiere gibt es keine Probleme:

OUT_PORT = ( OUT_PORT | nextInfo.infoOn ) & ( ~ nextInfo.infoOff );

Dabei hängt an diesem Port jedoch nicht der IR-Empfänger. UART läuft ja 
weiter und die Ports werden auch gesetzt.

#define OUT_PORT  PORTC
#define OUT_DDR    DDRC
#define OUT_1      PC0
#define OUT_2      PC1
#define OUT_3      PC2
#define OUT_4      PC3
#define OUT_5      PC4
#define OUT_6      PC5

Zum testen habe ich jetzt einmal eine Routine in die UART Verarbeitung 
eingebaut und setze die Ports direkt mittels UART.

void CMD_Set_Ports_Direct(char* Line)
{
  uint8_t infoOn, infoOff;

  strtok( Line, ":" );
  ConvertToOnOffByte( strtok( NULL, ";" ), &infoOn, &infoOff );

  OUT_PORT = ( OUT_PORT | infoOn ) & ( ~ infoOff );
}

Dann klappt die Zeile ohne Probleme. Nur sobald ich diese wieder in die 
IR Routine einsetze hängts.

Weiß hier jemand Rat?

[Daniel S. (cyber)]

Ich weiß echt nicht weiter. Egal was ich anstelle es wird nicht mehr auf

if (irmp_get_data(&irmp_data))[c]reagiert.

[code]GET_CONFIG:BEGIN;
COUNT:3;
L:1:1:10101010:1001----;
L:2:2:10101010:10--11--;
L:3:3:10101010:000000--;
GET_CONFIG:END;[/code]

So schaut die Konfiguration derzeit aus. Diese liegt auch vollständig im EEPROM. Die letzten beiden Ports sind für UART reserviert, habe ja nur einen Mega8 gerade da.
Drücke ist Key1 so werden die Ports gesetzt. Drücke ich Key3 werden alle abgeschaltet. Drücke ich Key2 so werden auch diese gesetzt. Drücke ich wieder Key3 so werden sie auch wieder abgeschaltet. Drücke ich allerdings Key1, Key2, Key3 dann wird Key1 und Key2 ausgeführt. danach ist Ende...

Setze ich die Ports direkt über die UART so läuft es ohne Probleme. Lasse ich nur das setzen der Ports raus so läuft die IR-Routine ebenfalls ohne Probleme.
Die Main wird weiterhin ausgeführt UART funktioniert ja. IRMP ist nur auf NEC gesetzt und der IR Pin ist B0. F_INTERRUPTS ist auf 15000 gesetzt. Der ATMega8 läuft mit 16Mhz.
UART ist von Peter Fleury

[c]
void WriteMyPorts(uint8_t infoOn, uint8_t infoOff)
{
  uint8_t i, a = 7;

  for( i = 0; i < 8; i++ )
  {
    if ( (infoOn & (1 << i)) && !(infoOff & (1 << i)) )
    {
      OUT_PORT |= (1 << a);
    }
    else if ( !(infoOn & (1 << i)) && (infoOff & (1 << i)) )
    {
      OUT_PORT &= ~(1 << a);
    }
    else
    {

    }
    a--;
  }
}


void Init_IR()
{        
  IR_Protocol = eeprom_read_byte((uint8_t*)CONF_PROTOCOL_ADDR);            // Protokoll aus dem EEPROM lesen
  IR_Address = eeprom_read_word((uint16_t*)CONF_ADDRESS_ADDR);            // Adresse aus dem EEPROM lesen
}

uint8_t searchKey( uint8_t code, struct keyInfo_* pfound )
{
  struct keyInfo_ keyDesc;
  uint8_t NumDS = 0, CurrNumDS = 0;
  uint16_t Addr;

  CurrNumDS = eeprom_read_byte((uint8_t*)CONF_NUM_DATASETS);
  if (CurrNumDS == 0xFF)
  {
    CurrNumDS = 0;
  }

  for (NumDS = 1; NumDS <= CurrNumDS; NumDS++)
  {
    Addr = CONF_DATASETS_START_ADDR + ((NumDS -1) * sizeof(keyDesc));
    eeprom_read_block(&keyDesc, (void*)Addr, sizeof(keyDesc));

    if (keyDesc.keyCode == code)
    {
      *pfound = keyDesc;
      return TRUE;
    }
  }
  return FALSE;
}


void Handle_IR_Code(void)
{
  IRMP_DATA irmp_data;

  struct keyInfo_ nextInfo;


  if (Mode == NO_KEY)
  {
    if (irmp_get_data(&irmp_data))
    {
      Mode = KEY_RECEIVED; uart_puts("SET MODE = KEY_RECEIVED\r\n");

      if (irmp_data.flags & IRMP_FLAG_REPETITION)
      {
        // Benutzer hält die Taste länger runter entweder:
        // ich ignoriere die (Wiederholungs-)Taste oder:
        // ich benutze diese Info, um einen Repeat-Effekt zu nutzen
      }
      else
      {
        // Es handelt sich um eine neue Taste
        if (irmp_data.protocol == IR_Protocol && irmp_data.address == IR_Address)            // Nur Befehle vedrarbeiten wenn das IR-System stimmt
        {
          WriteIRDataToUART(irmp_data);

          if (searchKey(irmp_data.command, &nextInfo) == TRUE)
          {
            //OUT_PORT = ( OUT_PORT | nextInfo.infoOn ) & ( ~ nextInfo.infoOff );
            WriteMyPorts(nextInfo.infoOn, nextInfo.infoOff);
            //uart_puts("Set Ports done\r\n");
            Mode = NO_KEY; uart_puts("SET MODE = NO_KEY\r\n");
          }
          else
          {
            uart_puts("Key not found\r\n");
            Mode = NO_KEY; uart_puts("SET MODE = NO_KEY\r\n");
          }
        }
      }
    }

    /*  if (Mode == KEY_RECEIVED)
      {
        Mode = NO_KEY;
        WriteMyPorts(nextInfo.infoOn, nextInfo.infoOff);
        uart_puts("Set Ports done\r\n");
        memset(&nextInfo, 0, sizeof (nextInfo));
      } */
  }
}


int main (void)
{
  OUT_DDR |= ((1 << OUT_1) | (1 << OUT_2) | (1 << OUT_3) | (1 << OUT_4) | (1 << OUT_5) | (1 << OUT_6));
  OUT_PORT |= ((1 << OUT_1) | (1 << OUT_2) | (1 << OUT_3) | (1 << OUT_4) | (1 << OUT_5) | (1 << OUT_6));
  _delay_ms(1500);
  OUT_PORT &= ~((1 << OUT_1) | (1 << OUT_2) | (1 << OUT_3) | (1 << OUT_4) | (1 << OUT_5) | (1 << OUT_6));

  uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) ); 


  irmp_init();                                                            // initialize irmp
  
  LED_DDR |= (1 << LED_PIN);                                              // LED pin to output
  LED_PORT |= (1 << LED_PIN);                                              // switch LED off (active low)
  irmp_set_callback_ptr (led_callback);
  
  timer1_init();                                                          // initialize timer1
  sei ();                                                                 // enable interrupts

  uart_puts("IR Demo Program\r\n");

  Init_IR(); // Auslesen des IR-Systems aus dem EEPROM

  for (;;)                                                                // Endlosschleife
  {
    WorkOnCommand();                                                      // Einlesen und verarbeiten der RS232 Befehle

    Handle_IR_Code();
  }
}

[Frank M. (ukw) (Moderator)]

Daniel S. schrieb:

> Drücke ist Key1 so werden die Ports gesetzt. Drücke ich Key3 werden alle
> abgeschaltet. Drücke ich Key2 so werden auch diese gesetzt. Drücke ich
> wieder Key3 so werden sie auch wieder abgeschaltet. Drücke ich
> allerdings Key1, Key2, Key3 dann wird Key1 und Key2 ausgeführt. danach
> ist Ende...

"Ist Ende" heißt, dass irmp_get_data() niemals mehr TRUE zurückliefert?
Zeigt die Callback-LED weiterhin was an?

> void WriteMyPorts(uint8_t infoOn, uint8_t infoOff)
> {
>   uint8_t i, a = 7;
> 
>   for( i = 0; i < 8; i++ )
>   {
>     if ( (infoOn & (1 << i)) && !(infoOff & (1 << i)) )
>     {
>       OUT_PORT |= (1 << a);
>     }
>     else if ( !(infoOn & (1 << i)) && (infoOff & (1 << i)) )
>     {
>       OUT_PORT &= ~(1 << a);
>     }
>     else
>     {
> 
>     }
>     a--;
>   }
> }

Ein Tipp: Für einen AVR ist das Schieben von Bits über eine variable 
Anzahl ein Riesenaufwand. Aus den Befehlen 1<<i bzw. 1<<a wird richtig 
viel Maschinencode. Besser ist es hier, eine Maske durchzuschieben - 
immer um den konstanten Wert 1. Schau Dir oben mal an, wie das Karl 
Heinz es macht, z.B. in ConvertToOnOffByte().

>   for (NumDS = 1; NumDS <= CurrNumDS; NumDS++)
>   {
>     Addr = CONF_DATASETS_START_ADDR + ((NumDS -1) * sizeof(keyDesc));
>     eeprom_read_block(&keyDesc, (void*)Addr, sizeof(keyDesc));
> 
>     if (keyDesc.keyCode == code)
>     {
>       *pfound = keyDesc;
>       return TRUE;
>     }
>   }
>   return FALSE;
> }

NumDS würde ich von 0 bis < CurrNumDS laufen lassen, dann sparst Du den 
Abzug von 1 zwei Zeilen tiefer. Überhaupt solltest Du mehr von 0 und 
nicht von 1 an "denken" beim Programmieren ;-)

Wie ist eigentlich CONF_DATASETS_START_ADDR definiert? Eventuell muss da 
bei der Berechnung von Addr die C-Pointerarithmetik beachtet werden.

Einen Fehler kann ich direkt nicht sehen, aber ich vermute, dass Du 
entweder in einer Endlosschleife landest oder Dir irgendwas im RAM durch 
einen Programmierfehler kaputtschießt. Ich sehe nur nicht auf Anhieb, 
wo.

Aber Moment, was sehe ich denn da:

>   if (Mode == NO_KEY)
>   {
>     if (irmp_get_data(&irmp_data))

Kann es sein, dass Du vergisst, Mode wieder zurückzusetzen auf NO_KEY, 
wenn Du mal einen Frame mit gesetztem IRMP_FLAG_REPETITION Bit 
empfängst?

Wenn Mode auf KEY_RECEIVED bleibt, wird niemals mehr ein IR-Telegramm 
empfangen!

Statt

>       if (irmp_data.flags & IRMP_FLAG_REPETITION)
>       {
>         // Benutzer hält die Taste länger runter entweder:
>         // ich ignoriere die (Wiederholungs-)Taste oder:
>         // ich benutze diese Info, um einen Repeat-Effekt zu nutzen
>       }

solltest Du schreiben:

      if (irmp_data.flags & IRMP_FLAG_REPETITION)
      {
          Mode = NO_KEY; uart_puts("Repetition: SET MODE = NO_KEY\r\n");
      }

Das wird Deinen Fehler wohl beheben.

Gruß,

Frank

[Daniel (Gast)]

Hallo und danke für die Antwort.

Die callback zeigt mir weiterhin an wenn ein IR Signal anliegt.

Die Prozedur WritePorts habe ich mir nur mal eben "schnell" sofern man 
das bei mir schnell nennen kann geschrieben um festzustellen ob es mit 
dem
{c]OUT_PORT = ( OUT_PORT | nextInfo.infoOn ) & ( ~ nextInfo.infoOff 
);[/c] ein Problem gibt. Zudem werden mir hier die Ports vertauscht. Hat 
ein wenig gebraucht bis mir das aufgefallen ist.

Wenn ich diese eben direkt über die UART setze gibt es weder mit 
WritePorts noch mit dem obigen Befehl Probleme.

Das mit dem von 0 anfangen werde ich beherzigen und nachher mal umsetzen 
wenn ich daheim bin.

Das hier ist die Definition:

#define CONF_PROTOCOL_ADDR         0                                      // Adresse im EEPROM um das Protokoll abzulegen (1Byte)
#define CONF_ADDRESS_ADDR           1                                      // Adresse im EEPROM um die Adresse abzulegen (2Byte)
#define CONF_PORTNAMES_START_ADDR   3                                      // Start Adresse für die Port Namen (8x10Byte)
#define CONF_NUM_DATASETS          84                                      // Adresse im EEPROM; Anzahl der Geschriebenen Datensätze
#define CONF_DATASETS_START_ADDR  85                                      // Startadresse der Tastendatensätze            
#define MAX_DATASETS              40                                      // Anzahl der Datensätze die möglich sind
#define MAX_COMMAND_LEN            47                                      // Maximale Länge des zu empfangen Befehls über RS232
#define MAX_PORTNAME_LEN          12                                      // Länge des Portnamen
#define MAX_CMD_TOKEN_LEN          20                                      // Größe des Befehlstoken
#define MAX_KEY_NAME_LEN          20                                      // Länge des Namens innerhalb eines IR Datensatzes

struct keyInfo_                                                            // IR Datensatz
{
  //char    name[MAX_KEY_NAME_LEN];                                        // Name der Taste
  uint16_t keyCode;                                                        // Taste auf der Fernbedienung
  uint8_t Options;                                                        // 1Byte für zusätzliche Informationen
  uint8_t infoOn;                                                          // On Byte: Hier stehen die On Bits des Ports drin
  uint8_t infoOff;                                                        // Off Byte: Hier stehen die Off Bits des Ports drin 
};

uint8_t StringLen = 0;                                                    // Anzahl empfangener Zeichen
char Line[MAX_COMMAND_LEN];                                                // die Befehlszeile
uint8_t IR_Protocol = 0xFF;                                                // Das verwendete Protokoll;
uint16_t IR_Address = 0xFFFF;                                              // Das verwendete Gerät;

Frank M. schrieb:
> Aber Moment, was sehe ich denn da:
>
>>   if (Mode == NO_KEY)
>>   {
>>     if (irmp_get_data(&irmp_data))
>
> Kann es sein, dass Du vergisst, Mode wieder zurückzusetzen auf NO_KEY,
> wenn Du mal einen Frame mit gesetztem IRMP_FLAG_REPETITION Bit
> empfängst?
>
> Wenn Mode auf KEY_RECEIVED bleibt, wird niemals mehr ein IR-Telegramm
> empfangen!

Hier muss ich zugeben das dies erst seit gestern Abend existiert. Ich 
wollte einmal sehen ob die Zeit hier nicht passt vom Ablauf her und die 
Prozedur eben nicht mehr aufgerufen wird solange die Ports nicht gesetzt 
sind. Also Zeittechnisch etwas nicht passt.

Hier hast aber recht, gab grad eine mit dem Brett vor den Kopf. Klar 
wenn IRMP_REPETITION_FLAG gesrtzt ist wird der Mode nicht zurück 
gesetzt. Kann ich aber mittels UART zurück setzen. :) Dies existierte 
vorher nicht und dennoch hing es sich weg. Ich habe die Routine

(irmp_get_data(&irmp_data))

 nicht weiter intern verfolgt. Das könnte ich noch prüfen.
Wie gesagt es hängt sich nur weg wenn ich die Ports setze, egal ob mit 
Write Ports oder direkt.

[Frank M. (ukw) (Moderator)]

Daniel schrieb:

> Hier hast aber recht, gab grad eine mit dem Brett vor den Kopf. Klar
> wenn IRMP_REPETITION_FLAG gesrtzt ist wird der Mode nicht zurück
> gesetzt. Kann ich aber mittels UART zurück setzen. :) Dies existierte
> vorher nicht und dennoch hing es sich weg. Ich habe die Routine
> (irmp_get_data(&irmp_data))nicht weiter intern verfolgt. Das
> könnte ich noch prüfen.

Brauchst Du nicht, ich kenne den IRMP-Source zufällig in- und auswendig 
:-)

Bitte korrigiere den Fehler, teste bitte, ob Du das Fehlverhalten 1:1 
mehrfach hintereinander reproduzieren kannst und dann hänge bitte den 
Source als Anhang an, insbesondere:

   main.c (oder wie immer das Modul heisst)
   irmpconfig.h

Eventuell noch weitere Header-Files, z.B. das, wo 
CONF_DATASETS_START_ADDR definiert ist.

Eine Ausgabe auf dem UART, ob irmp_get_data() überhaupt noch aufgerufen 
wird und was dessen Return-Code ist, wäre auch noch hilfreich.

Ich verstehe auch den Sinn der globalen(?) Variablen Mode nicht. Wo 
brauchst Du die noch außerhalb von Handle_IR_Code()? Wenn nirgendwo, 
kann die komplett weg und der Aufruf von irmp_get_data() kann unbedingt 
erfolgen.

Gruß,

Frank

[Daniel (Gast)]

Wie gesagt ich hab dies gestern einfach mal eingebaut um zu prüfen was 
sich wie verhällt. diesen Source habe ich auch hier gesetzt. Vorher 
fehlte der Mode. In der Final soll er natürlich nicht mehr vorhanden 
sein.

Werde nachher den Source komplett anhängen. Das Mode nehme ich natürlich 
auch wieder raus.

[Daniel S. (cyber)]

µC ist ein ATMega8 mit 16Mhz. Board ist das Pollin Eval Board. Keine 
Ahnung ob es wichtig sein könnte aber ich erwähne es mal.

Habe Mode und DMode nun wieder vollständig entfernt. Bei den meisten 
Routinen habe ich nun auch 0 bis < als gesetzt. Bei den anderen muss ich 
erst mein Windows Source ändern und werde dann auch die Port Nummern mit 
0 beginnen. Musste natürlich bei der Ausgabe über UART wieder +1 nehmen 
sonst mag mein Windows Programm das nicht mehr.

WriteToPorts ist nun auch wieder draußen. Diese war nur zum testen 
aktiv.

Aktuelle Konfiguration

[2013-08-21 20:26:49]-> GET_CONFIG;
[2013-08-21 20:26:49]<- READ: GET_CONFIG
[2013-08-21 20:26:49]<- GET_CONFIG:BEGIN;
[2013-08-21 20:26:49]<- COUNT:3;
[2013-08-21 20:26:49]<- L:1:1:10101010:--110-11;
[2013-08-21 20:26:49]<- L:2:2:10101010:--1-0000;
[2013-08-21 20:26:49]<- L:3:3:10101010:--000000;
[2013-08-21 20:26:49]<- GET_CONFIG:END;

L:<DatensatzNr>:<IR-Taste>:<Options>:<Port>;

Die Definition des gesetzten Bit bedeutet '-' = alter Zustand bleibt, 
'0' = off und '1' = on.

Solange ich die Ports nicht setze läuft es alles reibungslos. Bei der 
gesetzten Konfiguration laufen Taste 2 und 3 ohne Probleme. Drücke ich 
aber die Taste 1 dann wird der Port noch gesetzt. Die UART meldet Ports 
sind gesetzt und von da an wird immer FALSE gemeldet.

irmp_get_data()

 wird weiterhin aufgerufen liefert aber ein FALSE zurück.
Das Fehlverhalten ist reproduzierbar. Ich versuche es ja schon einige 
male.

Im Anhang alle Dateien des Projekts. Derzeit ist alles in der IR-Demo.c 
enthalten. Das war ursprünglich mal die IR Demo vom IRMP. Bin noch in 
der Lernphase, ist mein zweites Projekt.

[Daniel S. (cyber)]

Ich muß mich korrigieren habe eben bemerkt das ich die ganze Zeit von 
PortD als Ausgang gesprochen habe, dabei war es PortC. Habe das Programm 
nun auf PortD mal umgestellt aber leider hier auch keine Verbesserung.

[Frank M. (ukw) (Moderator)]

Daniel S. schrieb:
> µC ist ein ATMega8 mit 16Mhz. Board ist das Pollin Eval Board.

Sind da irgendwelche Jumper gesetzt, d.h. bestimmte Pins vom ATmega mit 
irgendwelchen Komponenten auf dem Board verbunden?

> Im Anhang alle Dateien des Projekts. Derzeit ist alles in der IR-Demo.c
> enthalten. Das war ursprünglich mal die IR Demo vom IRMP. Bin noch in
> der Lernphase, ist mein zweites Projekt.

Ich kann auf Anhieb keinen Fehler erkennen. Das schließt aber nicht aus, 
dass da einer oder mehrere Fehler sind :-)

Folgende Sachen sind mir aufgefallen:

1. Du hast lange if-Ketten, die sich ungünstig auf die 
Bearbeitungs-Geschwindigkeit auswirken:

      if (strcmp(Command, "SET_IR_SYSTEM") == 0)                          // Setzen des IR-Systems in den EEPROM
      {
        CMD_Set_IR_System(Line);
      }

      if (strcmp(Command, "GET_IR_SYSTEM") == 0)                          // Liest das IR-System fom EEPROM
      {
        CMD_Get_IR_System();
      }

      if (strcmp(Command, "SET_NUM_DS") == 0)
                        ....

Hier wäre es sinnvoll, ab dem 2. if ein else davorzusetzen, also:

      if (strcmp(Command, "SET_IR_SYSTEM") == 0)                          // Setzen des IR-Systems in den EEPROM
      {
        CMD_Set_IR_System(Line);
      }

      else if (strcmp(Command, "GET_IR_SYSTEM") == 0)                          // Liest das IR-System fom EEPROM
      {
        CMD_Get_IR_System();
      }

      else if (strcmp(Command, "SET_NUM_DS") == 0)
                        ....

Grund: Der Prozessor kann mit dem Vergleichen aufhören, sobald eine 
Bedingung zutrifft, da die Bedingungen sich ausschließen.

Dann ist mir das noch aufgefallen:

      if (strcmp(Line, "SYS_SYNC") == 0)                                  // Synchronisieren des Datenstroms
      {
      }

Abgesehen davon, dass diese Zeilen null Effekt haben, muss da nicht auch 
Command statt Line stehen?

Was mir noch auffällt: Du hast sehr viele Stringkonstanten im Source, 
z.B. bei den obigen if-Statements. Diese werden beim Start des 
Prozessors alle ins RAM kopiert. Davon hast Du aber sehr sehr wenig! Was 
sagt denn das AVR-Studio zur Data-Größe am Ende des Compiliervorgangs?

Ich vermute, dass durch diese viele Stringkonstanten Dein Stack sehr 
knapp bemessen ist, dann irgendwann überläuft und das Programm fortan 
nicht mehr korrekt arbeiten kann.

Abhilfe ist sehr einfach:

Ersetze alle Vorkommnisse von

   strcmp (Variable, "abcdefgh")

durch

   strcmp_P (Variable, PSTR("abcdefgh"))

Dann bleiben die Stringkonstanten im Flash. Das Makro PSTR liefert eine 
Adresse aus dem Flash und nicht aus dem RAM zurück, strcmp_P() ist die 
äquivalente Form von strcmp, liest aber dann aus dem Flash.

Du musst dann noch am Anfang ein

#include <avr/pgmspace.h>

einfügen.

Das sollte viele Bytes im RAM einsparen, die Dir wahrscheinlich zur 
Laufzeit fehlen.

Gruß,

Frank

[Daniel (Gast)]

Guten morgen,

Frank M. schrieb:
> Sind da irgendwelche Jumper gesetzt, d.h. bestimmte Pins vom ATmega mit
> irgendwelchen Komponenten auf dem Board verbunden?
Auf dem Eval Board sind keine Jumper gesetzt außer für UART, der Rest 
ist nicht weiter verbunden. Reset geht direkt auf den ISP und mit Taster 
gegen Masse. Auf dem Addon-Board ebenfalls nichts weiter angeschlossen.

Frank M. schrieb:
> Ich vermute, dass durch diese viele Stringkonstanten Dein Stack sehr
> knapp bemessen ist, dann irgendwann überläuft und das Programm fortan
> nicht mehr korrekt arbeiten kann.
Darüber habe ich mir ehrlich gesagt bisher keine Gedanken gemacht. Werde 
dies nachher mal umsetzen. So umzudenken vom PC auf µC fällt mir nicht 
einfach. Auf dem PC kann man schon mal verschwenderischer mit Ressourcen 
umgehen, hat man ja mehr von.

Auf dem PC hätte ich vermutlich auch If - Else genommen. Warum ich das 
hier nicht gemacht habe kann ich gerade nicht erklären. Werde das 
natürlich auch abändern.

if (strcmp(Line, "SYS_SYNC") == 0)

 Hier ist es egal an wo in dem String der Sub-String steht, es soll auf 
jeden Fall dieser Bereich ausgeführt werden.

Frank M. schrieb:
> Davon hast Du aber sehr sehr wenig! Was
> sagt denn das AVR-Studio zur Data-Größe am Ende des Compiliervorgangs?

Meinst du das hier?:
  Task "RunOutputFileVerifyTask"
        Program Memory Usage   :  6244 bytes   76,2 % Full
        Data Memory Usage     :  757 bytes   73,9 % Full
  Done executing task "RunOutputFileVerifyTask".

[Daniel S. (cyber)]

Hallo,

Habe entsprechende Anpassungen gemacht aber sehr viel hat es nicht 
gebracht.

  Task "RunOutputFileVerifyTask"
        Program Memory Usage   :  6622 bytes   80,8 % Full
        Data Memory Usage     :  675 bytes   65,9 % Full
  Done executing task "RunOutputFileVerifyTask".

Dafür habe ich aber gerade festgestellt das er irgendwann wieder ein 
Signal durlässt. Gerade mehrfach getestet. Ich setze --100001 und direkt 
danach --000000 läuft ohne Probleme. Hier kann ich auch unbegrenzt hin 
und her schalten. Setze ich aber nun auf --111111 dann ist erst einmal 
Ende. Nach knapp über einer Minute reagiert er dann wieder mit einem 
IR-Signal.

Ich habe nun sehr viele Befehle auskommentiert die ich zum testen so 
nicht benötige. Nach dem Kompilieren hat sich der Wert für Data Memory 
Usage aber leider nicht geändert. Er steht immer noch auf 675Byte trotz 
7 entfernter Befehle. Leider ändert sich hier auch nichts an der 
Verarbeitung. Diesmal hat es fast 2 Minuten gedauert bis der nächste 
Datensatz angenommen wurde.

Es ist im übrigen egal ob ich den IR-Code auswerte oder direkt den Port 
Togle also sobald ein IR Signal ankommt und egal welches es ist ich 
togle alle 6 Bits. Selbst dann hängt er für eine Weile. Ob das bei der 
Fehlersche hilft weiß ich leider nicht.

[Daniel S. (cyber)]

Ich habe jetzt noch einmal die Demo vom IRMP mit UART von P.F. auf den 
Controller gejagt und dabei nur folgendes eingesetzt.

if (irmp_get_data (&irmp_data))
{
  // ir signal decoded, do something here...
  // irmp_data.protocol is the protocol, see irmp.h
  // irmp_data.address is the address/manufacturer code of ir sender
  // irmp_data.command is the command code
  // irmp_protocol_names[irmp_data.protocol] is the protocol name (if enabled, see irmpconfig.h)
  itoa (irmp_data.protocol, buf, 10);   // protocol in decimal
  uart_puts (irmp_protocol_names[irmp_data.protocol]);
  uart_puts(" (");
  uart_puts(buf);
  uart_puts(") ");
  itoa (irmp_data.address, buf, 16);   // address in hex
  uart_puts (buf);
  uart_putc (' ');
  itoa (irmp_data.command, buf, 16);   // command in hex
  uart_puts (buf);
  uart_putc(' ');
  if (irmp_data.flags & IRMP_FLAG_REPETITION)
  {
    // Benutzer hält die Taste länger runter
    // entweder:
    //   ich ignoriere die (Wiederholungs-)Taste
    // oder:
    //   ich benutze diese Info, um einen Repeat-Effekt zu nutzen
    uart_puts("Wiederholung");
  }
  else
  {
    // Es handelt sich um eine neue Taste
    uart_puts("New Key");
  }
  uart_putc ('\r');
  uart_putc ('\n');

  // Test
  if (irmp_data.protocol == 2 && irmp_data.address == 0xBF40 && irmp_data.command == 0x01 && !(irmp_data.flags & IRMP_FLAG_REPETITION))
  {
    infoOn = 0xFC;
    OUT_PORT = infoOn;
  }
  else
  if (irmp_data.protocol == 2 && irmp_data.address == 0xBF40 && irmp_data.command == 0x03 && !(irmp_data.flags & IRMP_FLAG_REPETITION))
  {
    infoOn = 0x00;
    OUT_PORT = infoOn;
  }
}

Selbiges Problem irmp_get_data liefert FALSE. Die Callback wird aber 
noch aufgerufen, die LED reagiert bei eingehendem Signal.

Also bin ich noch einen Schritt weiter gegangen und habe die UART Lib 
von P.F. auch komplett entfernt. Hier ebenfalls ein Hänger.

an den Ports selbst kann es ja nicht liegen die setze ich ja für 1.5 
Sekunden beim Start.

if (irmp_data.protocol == 2 && irmp_data.address == 0xBF40 && irmp_data.command == 0x01 && !(irmp_data.flags & IRMP_FLAG_REPETITION))
{
  OUT_PORT |= ((1 << OUT_1) | (1 << OUT_2) | (1 << OUT_3) | (1 << OUT_4) | (1 << OUT_5) | (1 << OUT_6));
}
else
if (irmp_data.protocol == 2 && irmp_data.address == 0xBF40 && irmp_data.command == 0x03 && !(irmp_data.flags & IRMP_FLAG_REPETITION))
{
  OUT_PORT &= ~((1 << OUT_1) | (1 << OUT_2) | (1 << OUT_3) | (1 << OUT_4) | (1 << OUT_5) | (1 << OUT_6));
}

Selbst dieses funktioniert nicht. Da muß doch echt irgendwo der Wurm 
drin sein.

Auf dem Addon Board ist ein TSOP1136 verbaut selbst den habe ich nun 
extern wie im Artikel beschrieben angeschlossen. Ergebnis: keine 
Änderung. Nun habe ich ihn auf 8Mhz gesetzt aber selbst das bringt keine 
Änderung.

Jetzt bin ich ratlos.

[Daniel S. (cyber)]

Ich habe das Programm nun mal auf einem Mega16 aufgespielt einmal mit 
8Mhz und einmal mit 16Mhz und hier läuft das Programm ohne Probleme.

Hier hat sich auch nicht viel geändert:
  Task "RunOutputFileVerifyTask"
        Program Memory Usage   :  5564 bytes   34,0 % Full
        Data Memory Usage     :  675 bytes   65,9 % Full
  Done executing task "RunOutputFileVerifyTask".

Ich frage mich nur warum es nicht auf dem Mega8 laufen will. Abgesehen 
davon das ich hier alle Pins des PortC nutzen kann und beim Mega8 hier 
noch UART drauf liegt hat sich nichts geändert.
Habe jediglich das Target geändert und die beidem Pins des PortC dazu 
genommen.

Hat hier jemand eventuell einen Ansatz warum dieses Problem auftritt 
oder sogar schon einmal ein gleiches Problem?

Was ich allerdings noch nicht versucht habe ist einfach mal einen 
frischen Mega8 zu nehmen. Habe gerade keinen hier liegen. :(

Würde schon gerne wissen warum der Mega8 diese Probleme macht.

[Daniel S. (cyber)]

Guten Morgen,

ich habe noch einmal eine Frage bezüglich meines Sources.

          if (nextInfo.Options == 0x01)
          {
            NewSet = OUT_PORT;
            NewSet = ( OldSet | nextInfo.infoOn ) & ( ~ nextInfo.infoOff );

            if (OUT_PORT == NewSet)
            {
              OUT_PORT = ( OUT_PORT | nextInfo.infoOff ) & ( ~ nextInfo.infoOn );
            }
            else
            {
              OUT_PORT = ( OUT_PORT | nextInfo.infoOn ) & ( ~ nextInfo.infoOff );
            }
            
          }
          else
          {
            OUT_PORT = ( OUT_PORT | nextInfo.infoOn ) & ( ~ nextInfo.infoOff );
          }

Options = 0x01 bedeutet toggle. Gerade wenn eine Einzeltaste 
programmiert ist dann soll natürlich auch nur der Ausgang gesetzt bzw. 
zurück gesetzt werden. Bsp: Taste1 = TV - dementsprechend TV an oder aus 
wenn ich erneut die Taste betätige.
Es wird geprüft ob die aktuelle Maske der neuen entspricht, falls ja 
dann invertieren.

Ist dieses Konstrukt soweit ok?