DCG2 BUG?

Hier könnt ihr Diskussionen über die Software des Labornetzteiles des c't-Lab führen.
amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Beitrag von amd-65 » 16.02.2008, 08:46

amd-65 hat geschrieben: Alles was größer 63 Zeichen ist sollte verworfen werden. Es muß aber so erfolgen, daß der gesammte nicht in den Puffer passende String verworfen wird.
Ich habe es jetzt so geändert, das ein zu langer Antwort-String immer gekürzt durchgeleitet wird. Bei einem zu langen Kommando wird eine Fehlermeldung geschickt. Die kommt auch dann, wenn das Kommando an ein anderes Modul ging.

Gruß
amd-65

linux-is-sexy
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 65
Registriert: 29.11.2007, 14:38
Wohnort: Aachen

Beitrag von linux-is-sexy » 16.02.2008, 09:16

Mal ne dumme Frage: Warum kann ich nicht einfach 128 zeichen nehmen?

Liegt es daran, dass ich dann an die Grenzen des Atmegas komme?

Auf jeden Fall: Danke fuer die Aenderung!

Gruesse LiS
“Intelligence is the ability to avoid doing work, yet getting the work done” Torvalds

amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Beitrag von amd-65 » 16.02.2008, 14:13

linux-is-sexy hat geschrieben:Mal ne dumme Frage: Warum kann ich nicht einfach 128 zeichen nehmen?

Liegt es daran, dass ich dann an die Grenzen des Atmegas komme?
Du kannst den Puffer vergrößern. Dann solltest Du das aber bei allen Modulen machen. Der UART-Sende-Puffer sollte dann auch größer sein. Ich würde den mindestens 25% größer als den Zeilen-Puffer machen. Momentan solltest Du die UART-Puffer aber nur bis auf max. 255 Byte vergrößern. Es müssen ca. 350Byte vom RAM frei bleiben, da der Stack soviel benötigt.

Gruß
amd-65

HSiebrecht
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 116
Registriert: 30.11.2007, 23:50
Wohnort: Westfalen

Beitrag von HSiebrecht » 17.02.2008, 16:34

@LiS

Hallo, in einem vorherigen Postings hast Du folgendes geschrieben :

Ich habe als erstes Modul ADA-IO mit IO DA und AD und der Adresse 0, als zweites DCG mit DCP und Adresse 1, als drittes DDS mit TRMSC und Adresse 2.

Gruesse LiS

Lass mal die Moduladressen gleich, setze aber die ADA-IO an das Ende des OPTO-Bus, also da terminieren. Eventuell hilft das. Siehe auch einen alten Thread aus dem alten Forum, der BUG ist in CM's Firmware noch nicht beseitigt.

http://www.heise.de/ct/foren/S-Schoenhe ... 7302/read/
Viele Grüße

Helmut

Die meisten Desaster in der IT Welt haben eine gemeinsame Ursache: Wir machen mal eben.

linux-is-sexy
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 65
Registriert: 29.11.2007, 14:38
Wohnort: Aachen

Beitrag von linux-is-sexy » 19.02.2008, 19:42

Hi,
Ich habe beide Firmware Versionen vom DCG und DDS mit einem eigenen Programm und mit dem COMtest.vi gequält. Die C-Versionen haben sich auch bei 1.5MB/s keine Fehler geleistet. CM's Versionen haben bereits bei 38.4KB/s Aussetzer gezeigt. Ich habe dann einen verstümmelten Befehl oder eine Fehlermeldung als Antwort gesehen. Ich habes das auch bei 38.4kB mit zwei Modulen in Reihe getestet (DCG + DCG oder DDS + DCG).
Angenommen es gaebe eine C Firmware fuer ADA-IO und fuer das DIV...koennte man dann doch die 1000 oder sogar mehr Messwerte pro Sekunde erhalten?

Gruesse
LiS
“Intelligence is the ability to avoid doing work, yet getting the work done” Torvalds

amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Beitrag von amd-65 » 19.02.2008, 22:04

linux-is-sexy hat geschrieben:Hi,
Angenommen es gaebe eine C Firmware fuer ADA-IO und fuer das DIV...koennte man dann doch die 1000 oder sogar mehr Messwerte pro Sekunde erhalten?
Die eigentliche Übertragungsrate war zwar 1,5MByte/s, die Messages wurden aber mit einer deutlich niedrigen Wiederholrate gesendet. Das DCG bremst momentan auf 1 Kommando oder durchgeleitete Antwort je 4ms.

Gruß
amd-65

Antworten