Mischaka-USB-Bootloader für PIC18F2550

[Mischaka]

Mit diesem Bootloader können Sie USB-Schnittstelle aus dem Anwenderprogramm nutzen. Dabei müssen Sie sich nicht mit USB-Programmierung auseinander setzen. Denn Mischaka-USB-Bootloader regelt das für Sie.(Klingt wie Werbung)

Das Prinzip: Bootloader schafft eine Virtuelle serielle Schnittstelle.
Wartet 1s auf PC-Bootloader-Teil und dann geht zu Anwenderprogramm.
Dabei bleibt virtuelle serielle Schnittstelle erhalten. Wenn ein Zeichen vom Anwenderprogramm über USB gesendet werden soll dann wird eine Funktion aufgerufen die sich in bereich des Botloaders befindet. Sprich CALL 0x0F06 und ab Adresse 0x0F06 befindet sich die Funktion zum senden an USB.

Am PC schauen Sie im Geräte-Manager bei Anschlüsse unter  welchem Nummer hat der Mischka Port sich angerichtet (Bei mir war es COM4). Dann starten Sie beliebige Terminalprogramm und können sofort mit Ihrer Anwendung im PIC kommunizieren.
 
Noch ein Vorteil bei diesem System. Es ist Programmiersprache und Compiler unabhängig. Sie können im Assembler programmieren und dabei USB Funktionen des Bootloaders nutzen. Einzige Bedienung ist das Anwenderprogramm soll an richtiger stelle anfangen und reservierte RAM-Bereich nicht beschreiben.

Einschränkungen:
Es wird USB-Interrupt benutzt. Anwender darf Interrupts für nicht länger als 10mS abschalten. Sonst trennt PC das USB-Gerät ab.

Interrupts des Anwenders werden nicht unterstützt. Bitte keine Interrupts verwenden.(Ich arbeite noch daran eine Interruptumleitung zu realisieren).

Anwenderprogramm hat maximal 778 Byte RAM. RAM ist vom 0x00 bis 0xF6 für USB-Bootloader reserviert und noch 1k wird für USB-Stack verbraucht.

Bootloader kann weder EEPROM noch Konfigurationsbyts beschreiben.

Systemclock ist fest 48MHz. Quarz ist 20MHz.

Es gibt kein Treiber für Win98.

[Stampede]

Hallo,

schön, dass du uns einen USB Bootloader zur Verfügung stellst.

Leider finde ich die Einschränkungen ein wenig hart:

Anwender darf Interrupts für nicht länger als 10mS abschalten.

Interrupts des Anwenders werden nicht unterstützt.

Das ist ein gigantischer Nachteil. Vielleicht solltest du das so Ändern, dass der USB die High-Prio-Ins nutzt, und dem Anwender zumindest noch die Low-Prio-Ints zur Verfügung stehen.

Anwenderprogramm hat maximal 778 Byte RAM. RAM ist vom 0x00 bis 0xF6 für USB-Bootloader reserviert und noch 1k wird für USB-Stack verbraucht.

Ok, die knapp 255Byte RAM für den BL sind zwar viel, aber ok. Nur wozu 1kB für den USB Stack? Bei nur 2kB RAM gehen schon 62% des RAM für den BL drauf, das ist kein günstiges Verhältnis. Wenn das Anwenderprogramm gestartet wird, wird der USB Stack doch nicht mehr gebraucht. Warum kann der Anwender ihn dann nicht nutzen? Wie groß ist der BL denn selbst?

Bootloader kann weder EEPROM noch Konfigurationsbyts beschreiben.

Damit kann man leben.

Mein Fazit (was jetzt nicht böse gemeint ist, sondern eher konstruktive Kritik sein soll):
Ich Moment sehe ich keinen Sinn, diesen Bootloader zu verwenden. Denn Microchip stellt einen guten und schnellen BL zu Verfügung der in die ersten 2kB des Flash passt. Zudem gibt es kein Einschränkungen bezüglich der Interrupts, es wird auch kein RAM benötigt.


Gruß

Stefan

[Mischaka]

Hallo Stefan,

Aus deinem Fazit

Im Moment sehe ich keinen Sinn, diesen Bootloader zu verwenden. Denn Microchip stellt einen guten und schnellen BL zu Verfügung der in die ersten 2kB des Flash passt. Zudem gibt es kein Einschränkungen bezüglich der Interrupts, es wird auch kein RAM benötigt.

Du hast meine Grundidee überhaupt nicht verstanden.

Bootloader vom  Microchip kann nur das brennen des Anwenderprogramms in PIC.

Mein Bootloader regelt noch Zusätzlich USB-Kommunikation des  Anwenderprogramms.

So waren meine Überlegungen.

1. Wenn ich ein Gerät baue der mit PC über RS232 kommuniziert dann benutze ich RS232 Bootloader.

2. Wenn mein PIC über USB  mit PC kommunizieren soll dann, hat es Sinn ein USB Bootloader zu benutzen.

3. Auch wenn ich  USB Bootloader vom Microchip nutze, muss ich in meinem Programm komplette USB Kommunikation  programmieren. Das bedeutet das ich mich mit USB –Programmierung auseinandersetzen muss. Letztendlich habe ich im FLASH-ROM  zwei mal Deskriptoren und Routinen zum USB–Kommunikation. Einmal vom Bootloader und einmal vom meinem Programm.(nicht gerade sparsame Umgang mit dem Speicher).

Daraus ist Idee entstanden ein Bootloader zu schreiben dessen Routinen zum USB–Kommunikation gemeinsam vom Anwenderprogramm und Bootloader genutzt werden.

Wenn das Anwenderprogramm gestartet wird, wird der USB Stack doch nicht mehr gebraucht.

Natürlich wenn Bootloader nur zum Flashen benuzt wird. Und es gibt keine weitere USB-Kommunikation kannst du gesamten RAM benutzen. (Dann ist auch Bootloader vom Microchip besser)

Wenn aber dein Programm zum Beispiel AD-Wandler ausliest und die Daten über USB an eine Anwehdung im PC sendet. Dann muss  USB Stack unberührt bleiben sonst bricht die Kommunikation ab.

Nur wozu 1kB für den USB Stack?

Keine Ahnung  steht so im Datenblatt des PICs. Wenn USB benutzt wird dann braucht PIC 1k speicher für USB.

Noch mal. Viele Hobby-Elektroniker wollen in ihren Projekten USB nutzen . Im Foren wird empfohlen ein FDTI-Chip zu benutzen. Denn das ist der einfachste Weg .

Mein Bootloader + PIC18F2550 ist praktisch das gleiche wie ein  FDTI-Chip + PIC.

So sieht Anwenderprogramm

Code:

#include <18F2550.h>

#reserve 0x5:0xF6           // Dieses RAM-Bereich wird vom Bootloader und USB genuzt
#reserve 0x400:0x7FF        // Dieses RAM-Bereich ist USB-Stack

#bit Terminal=0x7A.1        // Ist ein Empfangsprogramm am PC gestartet? Wenn ja wird 1

#ORG 0x0F06, 0x0F08         // An dieser stelle befindet sich Unterprogramm zum senden eines Zeichens ьber USB
void USB_Char_send(char k)  // So heiЯt diese Unterprogramm in unserem Programm
{
    #locate k=0x0CE
}

#ORG 0x0F28, 0x0F2A         //Dummy Empfangen eines Zeichens
char USB_Char_empf()
{
}

#build(reset=0x1500)        // Resetvektor verbiegen
#ORG 0x1508, 0x4000 default // Benutzerprogramm liegt im Speicher ab 1508h

#use delay(clock=48000000)
#use rs232(baud=115200,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8)

void main()
{
    char a;

    printf("Testprogramm\n\r");                 // Sende an USART
    while(1)
    {
        a=USB_Char_empf(); //Empfange ein Zeichen ьber USB
        USB_Char_send(a);  // Sende ein Zeichen ьber USB
        putc(a);           // Sende an USART

    }
}

[theborg]

Hm wenn ich das jetzt richtig verstanden habe brauche ich nur 8bit in ein Speicherbereich schreiben und die sub für die Übertragung aufrufen und schon wird das ganze per RS232 Emulation gesendet ?

Wenn ja wehre des Genial.

[Stampede]

Hallo Mischaka,

jetzt habe ich verstanden, was dein BL bezwecken soll.

Aber trotzdem habe ich paar Anmerkungen:

Mein Bootloader regelt noch Zusätzlich USB-Kommunikation des  Anwenderprogramms.

Genau diese Idee hatte ich auch, dass der Anwender auch die USB Routinen benutzt. Leider handelt man sich dabei fast nur Probleme ein, v.a. wegen den Interrupts, aber das hatte ich in meinem vorherigen Post ja schon angesprochen.

Letztendlich habe ich im FLASH-ROM  zwei mal Deskriptoren und Routinen zum USB–Kommunikation. Einmal vom Bootloader und einmal vom meinem Programm.(nicht gerade sparsame Umgang mit dem Speicher).

Es ist richtig, dass die USB Routinen doppelt sind. Da sie aber im Normalfall kleiner als 2kB sind, passt der BL in den dafür vorgesehenen Bereich, der sich per Config gegen Überschreiben sichern lässt. Daher noch mal die Frage: Wie groß ist dein BL und ist er gegen ein eigenes Überschreiben geschützt?
2kB sind im Vergleich zu 32kB ein ziemlich kleiner Teil (6,25%), die man doch wirklich opfern kann. Bei einem 18FxxJ50 entspricht das bei 128kB Flash gerade mal 1,5%.

Keine Ahnung  steht so im Datenblatt des PICs. Wenn USB benutzt wird dann braucht PIC 1k speicher für USB.

Da hast du was nicht verstanden.  :angel1: Die USB-Engine braucht nur 1kB, wenn alle Endpoints (inklusive PingPong-Buffering) benutzt werden. Pro verwendetem Endpunkt sind das 8Byte (je 4byte für In und Out, das dopplete bei Odd und Even Buffern, vgl Datasheet S.177, Fig 17-7) . Da ich davon ausgehe, dass deine Schnittstelle Interrupt Transfers benutzt, kommst mit 8Byte für die Endpoints und 8Byte für die Nutzdaten pro Übertragung aus. Den Rest kannst du frei verwenden.

Mein Bootloader + PIC18F2550 ist praktisch das gleiche wie ein  FDTI-Chip + PIC.

Das erreichst du auch, wenn du den MC BL nutzt, und sich die Anwendung zB als HID am PC anmeldet (sozusagen 2 "Geräte" in einem). Dann kannst du doch auch ganz easy deine Daten übertragen, notfalls auch über die emulierte RS232 Schnittstelle wie du es tust. Und die Problematik mit den Interrupts besteht dann nicht mehr. Hast du dir denn da schon was überlegt, wie du das verbessern möchtest? Wie schnell ist der Loader eigentlich?

Auch nach deiner Erklärung möchte ich an meinem Fazit aus dem obigen Post festhalten: Die von dir erstelle Funktionalität lässt sich mit getrennten USB Routinen eleganter und mit weniger Einschränkungen erreichen.
Nichtsdestotrotz möchte ich deine Arbeit loben, da ich weiß, wie aufwendig und schwierig ist, eine ordentlich funkionierende USB Schnittstelle zu programmieren.

Gruß Stefan

[Mischaka]

Hallo theborg,

Hm wenn ich das jetzt richtig verstanden habe brauche ich nur 8bit in ein Speicherbereich schreiben und die sub für die Übertragung aufrufen und schon wird das ganze per RS232 Emulation gesendet ?

Ja. Genau das war mein Ziel.

Wenn ja wehre des Genial.

Danke! Wenigstens eine Anerkennung. 

Hallo Stampede,

Du bis wirklich hart.

Das erreichst du auch, wenn du den MC BL nutzt, und sich die Anwendung zB als HID am PC anmeldet (sozusagen 2 "Geräte" in einem). Dann kannst du doch auch ganz easy deine Daten übertragen, notfalls auch über die emulierte RS232 Schnittstelle wie du es tust.

Leute die sich schon mit USB auskennen brauchen mein Programm nicht. Die programmieren eigene USB Anwendung.

Bestimmt, ich und du kommen auch prima ohne Mischaka-USB-Bootloader wo möglich mit eleganteren Lösungen.

Mein Programm ist für die Leute die sich mit USB nicht auskennen , aber trotzdem USB nutzen wollen.

Wie schnell ist der Loader eigentlich?

Eigentlich so schnell wie möglich. USB-Übertragung erfolgt in fullspeed-Modus. Es werden 115200 Bit/s emuliert. Natürlich wird noch Zeit für Löschen ind Schreiben benötigt etwa 8ms für das 64 Byte Block.

Da hast du was nicht verstanden.  Die USB-Engine braucht nur 1kB, wenn alle Endpoints (inklusive PingPong-Buffering) benutzt werden. Pro verwendetem Endpunkt sind das 8Byte (je 4byte für In und Out, das dopplete bei Odd und Even Buffern, vgl Datasheet S.177, Fig 17-7) . Da ich davon ausgehe, dass deine Schnittstelle Interrupt Transfers benutzt, kommst mit 8Byte für die Endpoints und 8Byte für die Nutzdaten pro Übertragung aus. Den Rest kannst du frei verwenden.

Du hast recht ab 5C8h sind noch 569Byte frei.

Wie groß ist dein BL und ist er gegen ein eigenes Überschreiben geschützt?

BL ist sehr groß 5,3 k. BL ist gegen ein Überschreiben geschützt zwei mal. Ein mal im PIC-Bootloder –Teil und ein mal im PC-Teil. Daten die unter Adresse 1500h  liegen werden nicht übertragen bzw. nicht geschrieben. Sonst währe das hier nicht möglich.

Code:

#ORG 0x0F28, 0x0F2A     //An dieser stelle hat Bootloader Routine zum
char USB_Char_empf()    //empfangen eines Zeichens über USB
{          //Dummy Empfangen eines Zeichens
}     // Wir brauchen nur den Programmsprung zu Adresse 0F28h

   

[Stampede]

Hallo Mischaka,

Du bis wirklich hart.

Das mag ja sein.  :angel1:

Deshalb schrieb ich aber auch oben:

Nichtsdestotrotz möchte ich deine Arbeit loben, da ich weiß, wie aufwendig und schwierig ist, eine ordentlich funkionierende USB Schnittstelle zu programmieren.

Gruß Stefan