uni-c Problem mit der RS-232 Schnittstelle

[Spiedercat]

Hi Karsten und Comunity ,

da haben wohl mehrere Anwender ein Problem . Bei zur Zeit 221 Zugiffen auf diesen Beitag. ( minus der eigenen und eigenen doppelten )

Ich würde es begrüßen wenn nicht nur Du und ich dem uni-c auf die Sprünge helfen.

Ganz arg vermisse ich natürlich auch die Stellungsnahme von cm.

An alle Bit-und Bytes- Verbieger

ein fröhliches Weihnachtsfest und eine guten Rutsch ins neue Jahr

wünscht Euch

Hans-Peter

[psclab38]

da haben wohl mehrere Anwender ein Problem . Bei zur Zeit 221 Zugiffen auf diesen Beitag. ( minus der eigenen und eigenen doppelten )

Das ist ja der erste "technische" Thread zu UNI-C in diesem Forum. Im heise-Forum hat sich schon lange nix mehr bewegt. Ich glaube einfach, daß nur sehr wenige das Modul bislang aufgebaut haben und überhaupt soweit gekommen sind, das Problem überhaupt festzustellen.

@Thoralt: Kannst Du bitte bei Gelegenheit mal eine eigene Kategorie für Uni-C aufmachen. Damit das Kind auch ein Zuhause bekommt.

Ich würde es begrüßen wenn nicht nur Du und ich dem uni-c auf die Sprünge helfen.

Hier sind Anwender mit Pascal-Compiler gefragt, aber da gab es bislang nicht viele.

Code: Alles auswählen

 EESerBaud: LongInt= 38400;
 ...
 serBaud(word(EESerbaud));        // nur mit 644

diese Zeilen sind in der 20MHz-Version mehr drin. Ist mir beim Vergleichen nur so aufgefallen.

Ganz arg vermisse ich natürlich auch die Stellungsnahme von cm.

Man sollte die Hoffnung nicht gleich fahren lassen.

Vielleicht betrachtet er es auch als Motivationsversuch für ne C-Firmware, ...

... kann ich mir nicht wirklich vorstellen. Obwohl eine C-Version für das FPGA-Modul auch längst überfällig ist.

... aber da wäre JTAG nicht schlecht gewesen .

Meine Zustimmung. Die FPGA-Bridge hat auch keinen JTAG-Anschluß (oder sollte ich da was übersehen haben?). Das schmerzt noch viel mehr.

Grüße und frohes Fest
Paul

[fusebit]

Moin,

sehr hilfreich dieses Forum, vielen Dank dafür.

Ich möchte hiermit kurz bestätigen, dass die 20 MHz Version nicht in der Lage ist Befehle über RS-232 entgenzunehmen.
Nach einem Quarztausch (zum Glück hatte mein Olimexino einen 16 MHz Steckquarz) und Firmwarewechsel funktioniert es jetzt

Am Jumper 3 war ich natürlich auch hängengeblieben...

Grüße

Dirk

[Eddy]

Hallo

Habe mich hier auch mal angemeldet da ich gerade auch bei dem Problem mit der seriellen Kommunikation hänge.
Folgendes ist mir aufgefallen:
- Ein paar mehr Stellen im Code (UNIC.pas) die unterschiedlich sind, aber eher unauffällige Punkte (meistens sind
da in der 20Mhz-Datei Typendefinitionen von Variabelen ergänzt)
- Die Hex-Datei der 16Mhz-Variante is um ca 32 KB grösser als die 20Mhz-Variante -> dies scheint mir nicht mit diese
paar Änderungen erklärbar zu sein. Vielleicht sind da andere Bibliotheken mit compiliert worden o.Ä.
- Wenn man mit dem UNI-C testet (Seriell oder USB) dann reagiert die FW mit einem CMDERR auf jeglich Eingabe (ausser
ein simpeles [RETURN]). Dies bedeutet, dass die FW das [CR] am Ende der Eingabe erkennt und auch richtig auswertet. Daher vermute ich, dass es eher etwas mit der Initialisierung von Variabelen bzw Strukturen zu tun haben wird.

Als nächstes werde ich mir die LAN-Schnittstelle mal anschauen...

Hat jemand Erfahrung mit der Kompilierung der Sourcen? Oder gibt es irgendwo eine Beschreibung dazu?

Danke im Voraus für eine Rückmeldung,

Eddy

[psclab38]

Hallo Eddy,

Habe mich hier auch mal angemeldet da ich gerade auch bei dem Problem mit der seriellen Kommunikation hänge.
Folgendes ist mir aufgefallen:
- Ein paar mehr Stellen im Code (UNIC.pas) die unterschiedlich sind, aber eher unauffällige Punkte (meistens sind
da in der 20Mhz-Datei Typendefinitionen von Variabelen ergänzt)
- Die Hex-Datei der 16Mhz-Variante is um ca 32 KB grösser als die 20Mhz-Variante -> dies scheint mir nicht mit diese
paar Änderungen erklärbar zu sein. Vielleicht sind da andere Bibliotheken mit compiliert worden o.Ä.
- Wenn man mit dem UNI-C testet (Seriell oder USB) dann reagiert die FW mit einem CMDERR auf jeglich Eingabe (ausser
ein simpeles [RETURN]). Dies bedeutet, dass die FW das [CR] am Ende der Eingabe erkennt und auch richtig auswertet. Daher vermute ich, dass es eher etwas mit der Initialisierung von Variabelen bzw Strukturen zu tun haben wird.

Da wird wohl der Entwickler (CM) seinen Compiler nochmal anwerfen müssen. Keiner von den derzeit aktiven Mitgliedern im Forum hat den kommerziellen Compiler.

Ich habe CM grade nochmal eine PM zukommen lassen, meine eMails bleiben wohl irgendwo in seinem Spamfilter hängen.

Als nächstes werde ich mir die LAN-Schnittstelle mal anschauen...

Das dürfte keinen Unterschied machen. Die USB/RS232/LAN-Anschlüsse gehen alle auf den gleichen UART des Controllers.

Hat jemand Erfahrung mit der Kompilierung der Sourcen? Oder gibt es irgendwo eine Beschreibung dazu?

s.o. das ist ein kommerzieller Pascal-Compiler. Alternative Firmware (C) gibt es zu diesem Modul (noch) nicht.

Grüße
Paul

[Eddy]

Ich habe mal ein Bug-Report in Trac (Heise) erstellt.
Mal schauen ob CM darauf reagiert.

Habe mal schnell einen Disassembler über die 16 und 20 MHz hex-Dateien laufen lassen.
Da kann man sehen, dass über den ganzen Code überall Unterschiede sind d.h. bei Prozeduren
fehlen Teile der Logik. Also wird es wohl ein Compiler-Directive oder Bibliothek-Problem sein.

Gruss Eddy

[hansfranz]

Ich hab auch mal mein uni-c mitsamt pm8 panel zusammengelötet leider ned recht erfolgreich. Sowohl das pm8 panel als auch die rs232 verbindung funktionieren nicht richtig.

aber vielleicht nochmal zurück zum anfang. ich hab zuerst das unic gelötet und natürlich zuerst mal auf die zusätzlichen kabel für die stromversorgung für die optokoppler vergessen. die sind aber jetzt erstmal drin. zweites problem ist der quarz. da ist ja im bausatz nur der 20mhz drinnen. nach den berichten hier im forum hab ich aber auch eine 16mhz version eingelötet, jetzt sollte also alles klappen.
nach setzen der fuses und programmieren der hex und eeprom files kommt erstmal zumindest beim einschalten ab und zu mal was über die schnittstelle. leider nur lauter $$$$$$$. Mein verdacht lag auf den fuse bits, die im AVR Studio 4 leider andere namen haben als im hardware hacks beschrieben. ich hab jetzt erstmal die beschreibung von Spiedercat übernommen:

das low Fuse-Byte auf
Full Swing Oszilator; Start-up time 16 CK + 0 ms; Crystal Osc.; BOD enabel ,

das high Fuse-Byte auf
Boot Flash section size= 512 words Boot start adresse= 0x7E00,

und das Extended Fuse-Byte auf
Brown-out detection level at VCC=4.3 V gestezt.

das sieht dann im AVR studio so aus:



danach meldet sich das uni-c lab auch brav beim einschalten mit

#/:254=1.0b [UNIC by CM/c't 03/2010] [PM8 ]EEPROM EMPTY!

am pm8 panel kommt was ähnliches also sollte ich mich halbwegs auf dem richtigen weg zu befinden. vielleicht noch zur anmerkung: am anfang hatte ich eine andere boot flash size und auch ext. crystal oszi eingestellt. da kam beim pm8 das gleiche aber am serial port nur müll.

Mein problem ist jetzt dass das uni-c auf keine status messages antwortet also bei VAL 255? kommt nix. ich teste das mit dem basic serial write and read.vi der labview examples. und auch im teraterm mit alt+r. scheint beides nicht zu klappen.

ich benutze:
einen usbto rs232 converter von delock
und all-avr von diamex als programmer in kombinantion mit avr studio 4.19

hat wer einen plan woran das liegen könnte? und wie man im tera term normalerweise messages sendet? meine variante mit alt+r scheint mir etwas umständlich. gibts da eine variante mit einfach schreiben und schicken mit enter?

zusätzlich funktioniert das pm8 panel nicht richtig. ich kann zwar durch alle bereiche durchschalten aber nix einstellen. es steht zb beim ADC und DAC nur "+<[Pu". drehregler ändert nix sondern erzeugt nur ein blinken des roten leds. das FPGA ist mit lauter FFFFFFFF gefüllt?!? da sollte ich doch was einstellen bzw ablesen können?

soweit so gut, vielleicht kann mir wer helfen
gruß hansfranz

[fusebit]

Moin,

muss das nicht so?
Es ist doch ein Quarz und bei mir läuft es so bestens...

[psclab38]

Die Fuses sollten natürlich richtig gesetzt sein,
FC-DF-FF oder
FC-DF-EF sollten reichen, Full-Swing ist nicht nötig.

Der Bootblock wird nicht benutzt, die Größe ist damit egal.

#/:254=1.0b [UNIC by CM/c't 03/2010] [PM8 ] EEPROM EMPTY!

... und nicht vergessen auch das eep-File zu laden. Die Pascal-Firmwaren brauchen das.

[hansfranz]

Die Fuses sollten natürlich richtig gesetzt sein,
FC-DF-FF oder
FC-DF-EF sollten reichen, Full-Swing ist nicht nötig.

Der Bootblock wird nicht benutzt, die Größe ist damit egal.

#/:254=1.0b [UNIC by CM/c't 03/2010] [PM8 ] EEPROM EMPTY!

... und nicht vergessen auch das eep-File zu laden. Die Pascal-Firmwaren brauchen das.

eeprom hab ich eigentlich immer geladen aber vielleicht klappt das ned richtig wenn die fuses falsch sind. ich hab mich jetzt an die zweite variante gehalten also FC-DF-EF:




damit klappt zumindest mal das pm8. RS232 aber leider immer noch nicht. beim einschalten ist jetzt aber die EEEPROM EMPTY! message weg Dankeschön Paul!

Wie schickt ihr denn die messages ans uni-c? bei mir klappt das offensichtlich nicht richtig (ich nimm die labview VI "basic serial Write and Read.vi" der examples oder terra term mit alt+R.

[psclab38]

eeprom hab ich eigentlich immer geladen aber vielleicht klappt das ned richtig wenn die fuses falsch sind.

In Deinem ersten Screenshot sieht man, daß Du nach dem Laden des Flash kein EEProm geladen hast. Das Laden des Flash löscht implizit auch das EEPROM. Das kann man verhindern, indem man zusätzlich die Fuse EESAVE setzt.
Also die Reihenfolge beachten: zuerst Flash laden, dann EEPROM.

damit klappt zumindest mal das pm8. RS232 aber leider immer noch nicht. beim einschalten ist jetzt aber die EEEPROM EMPTY! message weg Dankeschön Paul!

Gerne

Wie schickt ihr denn die messages ans uni-c? bei mir klappt das offensichtlich nicht richtig (ich nimm die labview VI "basic serial Write and Read.vi" der examples oder terra term mit alt+R.

Probiere mal Hyperterm (wenn Du noch XP hast), ansonsten kennt Putty auch einen Seriell-Modus.


Gruß
Paul

[hansfranz]

Ich habe mal ein Bug-Report in Trac (Heise) erstellt.
Mal schauen ob CM darauf reagiert.

Habe mal schnell einen Disassembler über die 16 und 20 MHz hex-Dateien laufen lassen.
Da kann man sehen, dass über den ganzen Code überall Unterschiede sind d.h. bei Prozeduren
fehlen Teile der Logik. Also wird es wohl ein Compiler-Directive oder Bibliothek-Problem sein.

Gruss Eddy

gibts da eigentlich schon eine antwort?

[psclab38]

gibts da eigentlich schon eine antwort?

Hier ist mal der Link http://www.heise.de/ct/projekte/machmit/ctlab/ticket/86
Außer einer Bestätigung eines weiteren leidenden Anwenders: Nein, es gibt von CM keine Antwort. Auch per Mail habe ich nix bekommen.

Paul

[dg1vs]

gibts da eigentlich schon eine antwort?

Hier ist mal der Link http://www.heise.de/ct/projekte/machmit/ctlab/ticket/86
Außer einer Bestätigung eines weiteren leidenden Anwenders: Nein, es gibt von CM keine Antwort. Auch per Mail habe ich nix bekommen.
Paul

Hallo zusammen, hat irgendjemand eine Antwort von cm bekommen?

Gruß Karsten

[Eddy]

Hi Karsten, all,

Nein, leider keinerlei Reaktion seitens CM.

Gruss Eddy