www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik rs232 USBProg Problem


Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe die Firmware geflasht, und usbprog wird auch erkannt (winXp) hab 
dann den treiber installiert, aber HTerm meldet immer, das sämtlichen 
Baudraten angeblich nicht unterstüzt werde :(
Gibt es da nen Trick wie ich USBProg zur mitarbeit überreden kann?

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat niemand ne Idee oder sezt niemand ide RS232 Firmware ein?
Hat shconmal jemand das an Windows zum laufen gekriegt?

Autor: Steffen O. (derelektroniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Meinung nach, geht beim USBprog nur eine Baudrate, und zwar 9600 
Baud. Du kannst aber mal Benedikt anschreiben, und dann macht er noch 
eine Funktion, dass man auch die Baudrate wechseln kann, hat er 
zumindest auf seiner Seite geschrieben.
Ich hatte nämlich das selbe Problem, benötige aber kleinere Baudraten, 
also kann ich es auch nicht verwenden....

Bei mir erscheint nach dem Flashen der RS232- Firmware der USBprog im 
Gerätemanager mit so einem Fragezeichen, also er wurde irgendwie nicht 
korrekt installiert, keine Ahnung wieso.
Normalerweiße sollte er ja als virueller Com- Port erscheinen.
Wie hast du den installiert, bzw. welchen Treiber hast du da verwendet?


Gruß, Steffen

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AUf der Firmwareseite gibt eine eine inf Datei, die hab ich 
runtergeladen und dann mittels "Treiber aktualisieren" im Gerätemanager 
installiert.

Oh man hab das voll überlesen! Mit 9600 geht es, wenn man da frei wählen 
könnte wäre das natürlich nett.
Hab nur das Problem das er beim loop-Test Zeichen verschluckt :-\

Autor: Steffen O. (derelektroniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, jetzt hab ich es auch geschafft, der USbprog wird nun korrekt als 
COM5 erkannt.
Welche der Stiftleisten ist eigentlich RX und TX? Ich hab das auf der 
Homepage von Benedikt irgendwie nicht verstanden, was da was ist.

Gruß, Steffen

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo... Das Projekt ist echt nett... aber leider alles SEHR konfus.
Also laut Schaltplan ist die Reihenfolge:

 1 = VCC
 2 = PD0 = RXD
 3 = PD1 = TXD
 4 = GND

Falls Benedikt mitliest: Nen Treiber für Win98 wäre auch nice, habe 
leider keine Ahnung was dafür nötig wäre :-\

Autor: Steffen O. (derelektroniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meinst du diese Pinbelegung an der Stifleiste, die man auch verwendet 
zum umflashen des USBprog?

Ja, du hast recht, meiner Meinung nach gehören manche Sachen noch ein 
wenig besser dokumentiert.

Gruß, Steffen

Autor: Läubi .. (laeubi) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Laut 
Schaltplan(http://svn.berlios.de/svnroot/repos/usbprog/trunk/...) 
sollte eine 4 Polige Buchse existieren, ich vermute mal das ist die 
welche relativ nah am Mega32 sizt (siehe Bild), das eckige Pad sollte 
Pin 1 sein (vorsichtshalber nachmessen).

Habe mir gerade die USBSerial firmware mal runtergeladen, mal abgesehen 
von den Warnungen hab ichs sogar schon hinbekommen zu kompilieren :)
main.c:16: warning: function declaration isn't a prototype
main.c:17: warning: function declaration isn't a prototype
main.c:277: warning: function declaration isn't a prototype
main.c:289: warning: function declaration isn't a prototype
main.c: In function 'main':
main.c:315: warning: passing argument 1 of 'USBNInit' discards qualifiers from pointer target type
main.c:315: warning: passing argument 2 of 'USBNInit' discards qualifiers from pointer target type
main.c: At top level:
usbn2mc.h:27: warning: inline function 'USBNBurstWrite' declared but never defined
usbn2mc.h:27: warning: inline function 'USBNBurstWrite' declared but never defined

Bin nur zu "neu" und will da nirgends dran rumpfuschen, zumal es ein 
alter Stand ist (gut wäre es wenn Benedikt mal die aktuellen SOurcen als 
tar zur Verfügung stellen würde, hab leider kein SVN)

Autor: Steffen O. (derelektroniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin am verzweilfeln: Wenn ich also die Firmware draufflashe, dann 
wird der USBprog ordentlich als COM5 erkannt. Nun verbinde ich an JP3 
(der, der dem ATmega32 am nächsten ist) mit einem Jumper eben die zwei 
Pins, die man auch Verbinden muss, damit der USBprog in Bootloadermode 
geht. Dann müsste ich doch eigentlich RX mit TX verbunden haben, oder?
Dann stelle im in HTerm COM5 und 9600 Baud ein, und sende ein Zeichen, 
dieses kommt jedoch nicht zurück....
Wieso klappt das nicht?

Gruß, Steffen

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1) Jumper für Firmwareupdaten
2) Firmware draufspieln
3) Gerät abstecken
4) Jumper abziehen (sosnt startest du wieder im Updatemodus)
5) Gerät anstecken
6) Verbinden (9600N1 Hardwareflußkontrolle aus)
7) ggf Jumper stecken

Wie gesagt das funktioniert ÜBERHAUPT nicht zuverlässig, die Firmware 
scheint mir recht ungetestet, es gehen Zeichen verloren etc... Deshalb 
einfach mal ein paar mehr Zeichen senden, ich benutz zudem hterm weil 
Hyperterminal garnicht mit USB Prog zusammenarbeiten will.

Werde mal Benedikt ne Mail schreiben, würde ja die Firmware auch 
weiteretnwickeln aber irgenwei steig ich bei dem Code nicht ganz 
durch...

Autor: Steffen O. (derelektroniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, du hast Recht, nun klappts auch! Aber auch bei mir das gleiche: Ich 
sende mit HTerm immer hallo, einmal kommt hlo zurück, ein anders mal 
halo, und wieder ein anderes mal klappts auch ganz.
Scheint wirklich nicht gut getestet zu sein.....

Gruß, Steffen

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mir den Source mal angesehen, das "Problem" scheint mir das jedes 
Zeichen ein eigener USB request ist ohne Buffer... dadurch geht 
natürlich durch die Latenz bei USB viel verloren.
Ich würde ja die Firmware anpassen scheitere aber schon daran erstmal 
ein Zeichen zu senden, mir sind leider die Interna nicht ganz klar und 
auf der HP find ich auch keine gute Beschreibung wie das von staten geht 
den USBN als Serielle Schnittstelle zu verwenden :-\

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ja, du hast Recht, nun klappts auch! Aber auch bei mir das gleiche: Ich
> sende mit HTerm immer hallo, einmal kommt hlo zurück, ein anders mal
> halo, und wieder ein anderes mal klappts auch ganz.
> Scheint wirklich nicht gut getestet zu sein.....

Bei mir war es so, dass vom gesendeten String "Hallo Welt" nur folgendes 
zurückgekommen ist (über Loop): "H". Nach Aus-/Einstecken funktioniert 
es dann wieder für genau ein Zeichen.

Hat schonmal irgendjemand von euch die Logic-Analyzer-Firmware zum 
laufen gebracht? Hab selbst mittlerweile schon in Linux getestet - aber 
auch dort: keine Funktion.

Grüße, gast

Autor: Steffen O. (derelektroniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab jetzt mal den GPS- Empfänger von hier 
(Beitrag "GPS - Empfänger günstig bei Ebay") und mit dem klappt der 
Empfang über die Firmware, ohne ein verlorenes Zeichen!!

Warscheinlich liegt dieser Zeichenverlust daran, dass man eben RX und TX 
verbunden hat.
Also, wenn ich das jetzt so teste, bin ich eigentlich echt zufrieden 
damit, bis auf das, dass man eben nur eine Baudrate hat.

Gruß, Steffen

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, das geht aber vermutlich nur weil der Datenstrom bei so einem 
Modul doch recht einseitig ist, das sendet ja die meiste Zeit und 
empfängt nur alle jubeljahre mal einen kleinen Befehl von ein paar 
Bytes.

Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mit hat jemand eine Version vorkurzem zugesendet. Könnte für euch 
interessant sein:

ich hab mal n bisschen mit der Firmware gespielt und versucht die tiny
Version noch kleiner zu machen. Die Descriptoren liegen jetzt im Flash
(werden nur bei Bedarf mit den pgm_space Befehlen geladen).

Außerdem habe ich eine generische USB-CDC Implementierung erstellt. HID
folgt vielleicht auch noch...
Eine minimale main.c würde so aussehen:

#include "usbn2mc.h"
#include "usbn2mc/class/CDC/usbcdc.h"

// reponse for requests on interface
void USBNInterfaceRequests(DeviceRequest *req, EPInfo* ep)
{
}

/* id need for live update of firmware */
void USBNDecodeVendorRequest(DeviceRequest *req)
{
    switch(req->bRequest)
    {
//    case STARTAVRUPDATE:
//        avrupdate_start();
    break;
    }
}

int main(void)
{
    sei();            // activate global interrupts

    USB_CDC_init();        // setup usbstack as CDC device

    USBNAddStringDescriptor("USBprog EmbeddedProjects");
    USBNAddStringDescriptor("USBprogRFM12");

    USBNInitMC();        // start usb controller
    USBNStart();        // start device stack

    for(;;);
}

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Benedikt,

Dnake für die Dateien, das sieht auf den ersten Blick ja ganz gut aus, 
braucht man dafür spezielle Treiber wie bei der usbserial Version von 
dir wenn man das unter Win einsetzen möchte?

Und kannst du vieleicht kurz erklären was man beim senden beachten muß? 
(hat es z.B. ne feste Baudrate? Ich seh jezt in den Files so direkt 
nix...)

// EP0 in/out:     USB         (USBN: FIFO0 TXC0 RXC0)
// EP3 interrupt in: CDC control (USBN: FIFO1 TXC1)
// EP1 bulk out:   CDC data    (USBN: FIFO2 RXC1)
// EP1 bulk in:      CDC data    (USBN: FIFO3 TXC2)

EP0 --> Kann ich ignorieren?
EP3 --> Muß man da was spezielles hinsenden (CTS...RTS....)
EP1(out) --> Empfangen von Daten vom PC (müßte das nicht EP2 sein???)
EP1(in) --> Senden von Daten an den PC

Wollt das nur mal klären bevor ich jezt wieder stundenlang erfolglos 
rumwurschtel...

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wollts jezt mal kompilieren, aber:
avr-gcc.exe  -mmcu=atmega32 -Wall -gdwarf-2  -Os -fsigned-char -MD -MP -MT usbozi.o -MF dep/usbozi.o.d  -c  ../usbozi.c
avr-gcc.exe  -mmcu=atmega32 -Wall -gdwarf-2  -Os -fsigned-char -MD -MP -MT usbn2mc.o -MF dep/usbn2mc.o.d  -c  ../usbn2mc.c
avr-gcc.exe  -mmcu=atmega32 -Wall -gdwarf-2  -Os -fsigned-char -MD -MP -MT usbnapi.o -MF dep/usbnapi.o.d  -c  ../usbn2mc/tiny/usbnapi.c
avr-gcc.exe  -mmcu=atmega32 -Wall -gdwarf-2  -Os -fsigned-char -MD -MP -MT usbn960x.o -MF dep/usbn960x.o.d  -c  ../usbn2mc/tiny/usbn960x.c
avr-gcc.exe  -mmcu=atmega32 -Wall -gdwarf-2  -Os -fsigned-char -MD -MP -MT usbcdc.o -MF dep/usbcdc.o.d  -c  ../usbn2mc/class/CDC/usbcdc.c
../usbn2mc/class/CDC/usbcdc.c:57: error: 'USB_CDC_CLASS_DESC_LENGTH' undeclared here (not in a function)
../usbn2mc/class/CDC/usbcdc.c:131: error: empty scalar initializer
../usbn2mc/class/CDC/usbcdc.c:131: error: (near initialization for 'cdc_config_desc.class_desc')
../usbn2mc/class/CDC/usbcdc.c: In function 'USB_CDC_EP1_receive':
../usbn2mc/class/CDC/usbcdc.c:176: warning: passing argument 1 of 'USB_CDC_rxCallback' from incompatible pointer type
make: *** [usbcdc.o] Error 1
Das einzige was ich geändert habe ist:
#include "usbn2mc/tiny/usbnapi.h"
in
#include "../../tiny/usbnapi.h"
Weil er sosnt bei mir die Headerfile nicht gefunden hat.

Und in der usbn2mc
//#include "UART/uart.h"
und
void USBNDebug(char *msg) {
  //UARTWrite(msg);
}

(im zip gab es keinen Ordner mit den benötigten Dateien...)

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habs jezt doch hinbekommen durch ein zusätzliches Define, dafür läßt 
sich das "Gerät" aber laut WinXP nicht starten... :-\

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt auch mal den USB-232 Wandler mit Usbprog
ausprobiert (mit dem Source aus dem SVN).

Gerät wird erkannt. COM Port wird eingerichtet.
Senden von USB auf RS232 geht. Empfangen von RS232 und
senden auf USB geht komplett nicht. Kein einziges Zeichen!
Das empfangen von RS232 funktioniert nur bis in den ATMega.
Hab da die rote LED im Receive Interrupt eingebaut. Bis
da hin geht es gut. Aber über den USBN9604 wird irgendwie
nichts weitergegeben.

Aus lauter Verzweiflung habe ich dann den Takt für den
ATMEga mal auf 8MHz geändert und die Baudrateneinstellung angepasst.
Und schon kann ich auch Zeichen empfangen.

Meine Vermutung ist jetzt das es bei 16MHz mit meinem Layout
nicht so ganz hinhaut. Ist ein Nachbau mit ATMega im DIP
Gehäuse. Die Leitungen sind aber sauber und kurz verlegt.
Ich werde am Wochenende mal ein bißchen an
USBNWrite() rumfummeln und versuchen es dort stabiler
zum laufen zu bekommen.

Ein Tip an Benedikt:
  sei();      // activate global interrupts
  UARTInit();    // only for debugging

  // setup usbstack with your descriptors
  USBNInit(usbrs232,usbrs232Conf);

  _USBNAddStringDescriptor(""); //pseudo lang
  _USBNAddStringDescriptor("USBprog EmbeddedProjects");
  _USBNAddStringDescriptor("usbprogRS232");
  _USBNCreateStringField();


  USBNInitMC();    // start usb controller
  USBNStart();    // start device stack

Der Receive Interrupt für den UART wird schon freigegeben
bevor die Init für den USBN durch ist. Dort wird aber auch
in den USBN geschrieben! Wenn an RxD etwas hängt was
am senden ist könnte das Ärger geben. Ich würde den UART
Receive Interrupt erst nach USBNStart(); aktivieren.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab auch ein "selbstgebautes" bei 16Mhz sollte das unkritisch 
sein.

Ich sende damit folgendermaßen ein Zeichen: 
Beitrag "Hilfe zu USB/CDC Implementierung (USBN9604)"
Was aber leider recht lahm ist :-\

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Also ich hab auch ein "selbstgebautes" bei 16Mhz sollte das unkritisch
>sein.

Als mkII Clone arbeitet mein Selbstbau auch gut.
Fehler in der Schaltung oder im Layout schliesse ich jetzt aus.

Als USB->RS232 Sender funktioniert der usbprog.
Das Problem liegt beim empfangen. Ich habe alles mögliche ausprobiert.
Mit dem Programm aus dem Online-Pool programmiert, das
usbserial aus dem SVN genommen, den Sourcecode selber kompiliert
und an manchen Stellen in usbn2mc.c etwas konservativer programmiert.
Den Receive Interrupt erst nach USBNStart() aktiviert.
Alle UART Debug Meldungen aus dem Sourcecode entfernt.

Ich kriege es einfach nicht hin :( Beim Empfang gibt es nur Probleme.
Die Daten gehen per RS232 in den ATMega rein. Das zeigt mir eine
toggelnde LED im Receive Interrupt. Jedesmal wenn ich eine Taste
im Terminalprogramm drücke ändert sie den Zustand. Laut Osci
werden dann auch Daten in den USBN geschrieben. CS,WR,A0 sieht
alles gut aus. Am PC kommt aber nicht immer was an. Manchmal
ja, manchmal nein.

Ein Loopback mit Rx und Tx direkt am Usbprog funktioniert
so gut wie gar nicht. Das kann man sich gleich sparen.

Ich hab dann auch mal einen MAX232 an RX angeschlossen und
Daten von einem echten COM Port gesendet. Auch da wieder:
Mal geht ein bißchen was, meistens aber nur Stille auf dem
Empfangsterminal. Obwohl das ist nicht ganz richtig.
Die erste Taste wird gar nicht angezeigt. Die zweite Taste
dann ja! Und dann kommt meist nichts mehr.
Das bei allen drei Variationen, also Programm aus dem
Online-Pool programmiert, das fertige Bin aus dem SVN
und Sourcecode selber übersetzt.

Ich gebs auf. Für CDC nehme ich doch lieber einen FT232 oder
einen PIC18 mit USB.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Code, den Benedikt gepostet hat ist von mir. Funktioniert als 
USB<->RFM12 Wandler problemlos. Ich werd mal ne Version für USB<->RS232 
incl. Baudrate fertig machen. Vielleicht klappts noch diese WE.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manuel Stahl wrote:
> Der Code, den Benedikt gepostet hat ist von mir. Funktioniert als
> USB<->RFM12 Wandler problemlos. Ich werd mal ne Version für USB<->RS232
> incl. Baudrate fertig machen. Vielleicht klappts noch diese WE.
Das wäre Klasse!
Magst du vieleicht die USB<->RFM12 auch veröffentlichen?

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon lange geschehen:

http://www.mikrocontroller.net/articles/AVR_RFM12#...

svn://mikrocontroller.net/rfm12

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manuel Stahl wrote:
> Schon lange geschehen:
>
> http://www.mikrocontroller.net/articles/AVR_RFM12#...
>
> svn://mikrocontroller.net/rfm12
Kannst du die Sotware vieleicht hier hochladen? Ich hab leider kein 
Programm für SVN, und gibt es dafür auch nen Treiber für XP?
Sorry wenns schon irgenwo steht aber ich kanns nicht entdecken, ggf 
könnte man das ja auch mal auf der FirmwareSeite vom USBProg hinpacken 
:)

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier die Rev19. Die hab ich erfolgreich getestet, verwendet aber noch 
nicht meine überarbeitete USB-CDC Version.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und hier noch ein aktueller Snapshot der Entwicklung.

Bei beiden ist Eclipse mit CDT und AVR-Plugin zum Übersetzen nötig.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Manuel Stahl
Schonmal vielen Dank werde es mal heute Abend ausprobieren.
Du sendest ja auch immer ein zeichen zur Zeit über die USB hast du 
schonmal versucht mehrer Zeichen gleichzeitig zu senden?

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die überarbeitete Bibliothek für den USBN9604 wird das auf jedenfall 
können!

Ich mach mal ein neues Thema für den USBprogRFM12 auf, vielleicht gibts 
noch mehr Interesse...

Beitrag "USBprogRFM12"

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem Code aus USBprogRFM12_head.zip bekomme ich
ein gelbes Ausrufezeichen für den COM-Port.
Das Gerät kann nicht gestartet werden (Code 10)

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@holger: ich weiß, deshalb hab ich ja auch den funktionierenden Code aus 
Rev19 hochgeladen.

Falls aber jemand Basteln will, sollte er an der head-Version 
weitermachen, da diese dem aktuellen Stand entspricht.

Autor: Canis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich bin noch blutiger Anfänger und habe heute versucht den USBprog als 
RS232 Wandler zu nutzen ... mit mäßigem Erfolg. Wie schon beschrieben 
werden Zeichen teilweise verschluckt und ich muss auch die Baudrate 
ändern können.

@manuel stahl
Daher wollte ich Dich fragen, ob Du an dieser Stelle schon etwas gemacht 
hast?

@Alle
Ansonsten noch die allgemeine Frage, wenn ich an den Sourcen etwas 
ändere ... wie kann ich daraus eine neue Firmware kompilieren, die ich 
dann über das Flashtool ins UsbProg schreiben kann?
Bisher nutzte ich für meine Projekte WinAVR + Ponyprog + Parallel 
Programmer

Schon mal Vielen Dank!
Gruß

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ja, bin weitergekommen. Baudrate einstellen geht aber leider immernoch 
nicht, da der entsprechende Wert seltsamerweise nicht richtig vom PC 
empfangen wird.

Wer sich's anschauen will: usbcdc.c Zeile 226

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So jetzt gehts. Baudrate ist auch implementiert!

Nicht implementiert, aber prinzipiell kein Problem sind Character-Size, 
Parity, Stop-Bit und Hardware-Handshake.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Manuel!

Toll, dass du dich so bemühst und die Firmware vorantreibst.
Ich habe sie gerade bei mir ausprobiert mit einem kleinen Problem:
Gerät kann nicht gestartet werden - Code 10

natürlich mit beiliegender inf-Datei.
OS: WinXP

Wäre nett, wenn du mir/uns da helfen könntest.

mfg
gast

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann das unter Windows nachvollziehen, hab aber auch keine Idee an 
was es liegt. Vielleicht kann da jemand mir mehr Windows USB Erfahrung 
mal schauen...

Unter Linux hab ich keine Fehler mehr.

Autor: Marco G. (stan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Gerät kann nicht gestartet werden" bekomme ich hier auch.

usbview sagt folgendes:
> Device Descriptor:
> bcdUSB:             0x0110
> bDeviceClass:         0x02
> bDeviceSubClass:      0x00
> bDeviceProtocol:      0x00
> bMaxPacketSize0:      0x08 (8)
> idVendor:           0x1781
> idProduct:          0x0C64
> bcdDevice:          0x0100
> iManufacturer:        0x01
> iProduct:             0x02
> iSerialNumber:        0x00
> bNumConfigurations:   0x01
>
> ConnectionStatus: DeviceConnected
> Current Config Value: 0x00
> Device Bus Speed:     Low
> Device Address:       0x00
> Open Pipes:              0

Die rote LED blinkt beim Einstecken 3 mal kurz...

Die 2 Versionen im svn funktionieren auch nicht so richtig (USPprogRS232 
und USBprogRS232_fix).

Arbeitet da noch jmd daran?

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab da schon vergebens versucht eine email an Benedikt Sauter zu 
schreiben, da kommt aber nie eine antwort. es kümmert sich anscheinend 
niemand darum. bei anderen firmwares sieht das ähnlich aus. z.b. die 
logikanalyser firmware, da gibts noch nicht einmal einen download auf 
der embedded seite und im fimware pool ist diese auch nicht enthalten. 
von den 17 angepriesenen firmwares sind gerade einmal 8 über den 
firmwarepool erreichbar. ist schon irgendwo eine mogelpackung (und das 
für 32€).

Autor: Marco G. (stan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja mir würde eine Mischung aus der "alten" RS232 ohne FIFO und der 
neuen schon reichen.
Also mit FIFO, aber fix auf 9600 Baud. Passt nämlich zu meinem HR20 :)

Komischerweise sind RX und TX beide high, sowohl am USBprog und am HR20, 
und dadurch versorgt sich der HR20 ohne Batterien...

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn mal jemand, der den USBprogRS232 unter Windows einsetzen will einen 
USB Logger installiert und den Trace schickt, könnte ich vielleicht mehr 
sagen. Da meine Linux-Version soweit geht, wüsste ich nicht in welche 
Richtung ich testen soll.

Autor: Marco G. (stan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerne, welchen Logger soll ich installieren?

Autor: Marco G. (stan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kam raus bei SnoopyPro, Firmware ist die aus deinem post vom 
22.11.2008 19:00.

Die Formatierung ist etwas schlecht, ich hoffe du kannst erkennen was es 
bedeutet.

packet 1
1  in down  n/a  0.184  GET_DESCRIPTOR_FROM_DEVICE

URB Header (length: 80)
SequenceNumber: 1
Function: 000b (GET_DESCRIPTOR_FROM_DEVICE)
---------------------------------------------------------------

packet 2
1  in up  n/a  0.190  CONTROL_TRANSFER  12 01 10 01 02 00 00 08 
0x00000000

URB Header (length: 80)
SequenceNumber: 1
Function: 0008 (CONTROL_TRANSFER)
PipeHandle: 89aa2a40

SetupPacket:
0000: 80 06 00 01 00 00 12 00
bmRequestType: 80
  DIR: Device-To-Host
  TYPE: Standard
  RECIPIENT: Device
bRequest: 06
  GET_DESCRIPTOR
Descriptor Type: 0x0001
  DEVICE


TransferBuffer: 0x00000012 (18) length
0000: 12 01 10 01 02 00 00 08 81 17 64 0c 00 01 01 02
0010: 00 01
    bLength            : 0x12 (18)
    bDescriptorType    : 0x01 (1)
    bcdUSB             : 0x0110 (272)
    bDeviceClass       : 0x02 (2)
    bDeviceSubClass    : 0x00 (0)
    bDeviceProtocol    : 0x00 (0)
    bMaxPacketSize0    : 0x08 (8)
    idVendor           : 0x1781 (6017)
    idProduct          : 0x0c64 (3172)
    bcdDevice          : 0x0100 (256)
    iManufacturer      : 0x01 (1)
    iProduct           : 0x02 (2)
    iSerialNumber      : 0x00 (0)
    bNumConfigurations : 0x01 (1)
---------------------------------------------------------------

packet 3
2  in down  n/a  0.190  GET_DESCRIPTOR_FROM_DEVICE

URB Header (length: 80)
SequenceNumber: 2
Function: 000b (GET_DESCRIPTOR_FROM_DEVICE)
---------------------------------------------------------------

packet 4
2  in up  n/a  0.196  CONTROL_TRANSFER  09 02 43 00 02 01 00 a0 
0x00000000

URB Header (length: 80)
SequenceNumber: 2
Function: 0008 (CONTROL_TRANSFER)
PipeHandle: 89aa2a40

SetupPacket:
0000: 80 06 00 02 00 00 09 01
bmRequestType: 80
  DIR: Device-To-Host
  TYPE: Standard
  RECIPIENT: Device
bRequest: 06
  GET_DESCRIPTOR
Descriptor Type: 0x0002
  CONFIGURATION


TransferBuffer: 0x00000009 (9) length
0000: 09 02 43 00 02 01 00 a0 1a
    bLength            : 0x09 (9)
    bDescriptorType    : 0x02 (2)
    wTotalLength       : 0x0043 (67)
    bNumInterfaces     : 0x02 (2)
    bConfigurationValue: 0x01 (1)
    iConfiguration     : 0x00 (0)
    bmAttributes       : 0xa0 (160)
    MaxPower           : 0x1a (26)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.