Ultrasonic hinder att undvika Robot (8 / 16 steg)

Steg 8: PIC programmering, blinkar en LED, Bootloader

Varför behöver vi en bootloader i första hand?

Med en PicKit3 runt är nödvändigt, men att ha det liggande våra arbetsyta med utan goda skäl inte är. Inledningsvis jag inte ville komplicera mitt liv med bootloaders, men senare kom jag att inse sanningen: detta projekt är bättre utan PicKit. Att ha en enda kabel för programmering är trevligt, särskilt om det är en mycket vanlig USB mini kabel, som varje hobby har ett gäng. Fem stift ICSP sidhuvudet var kvar av designen avsiktligt använde jag min ZIF-kontakt ombord blixt bootloader till PIC.

USB-bootloader, enkel och bra

Titta på databladet för processorn jag beslutade att använda, kan man se att det finns UART och USB. Om jag plockar UART, jag fortfarande behöver en USB-UART-omvandlare och en massa sladdar - motverkar syftet. Så det bästa, enklaste, trevligaste val är USB. Mikrochip erbjuder alla slags kodexempel för bilder, bootloaders också. Om du hämtar och installerar "Mikrochip bibliotek för program", blir det en hel mapp om alla slags USB-applikationer, bootloaders, verktyg och andra nyttiga saker. I undermappen "Bootloaders" Jag plockade "USB HID Bootloader" och öppnat det i MPLAB X. Efter att ha läst igenom den ett par gånger att förstå sin logik, genomfört jag ändringar för att göra den perfekt för min RekaBot.

Några ord om bootloaders

En bootloader är en särskild del av kod som skrivs in microcontrollers en gång, och är ett sätt att ladda upp firmware utan behov av speciella (högspänning) programmerare, som PicKit3 i vårt fall. Tyvärr finns det inget sätt att helt undvika användning av PicKit, bootloader har att komma in i bilden på något sätt. Den goda delen: du kan låna en PicKit, ICD2 eller någon PIC flasher från en vän, och ge det tillbaka en gång bootloader är skriven till mikrokontroller. Efter det - beroende på vilken typ av bootloader fick blixtrade, du kan ladda upp firmware till programminne genom UART, USB, kan eller vad. Använda bootloaders är enkel, men kommer det med nackdelen att förlora dyrbar programminne. Vissa starthanterare äter upp mindre plats, vissa äter upp mer - här äter 1K minne. Vid start varje PIC befogenheter upp på adress 0 och börjar köra oavsett kod har programmeraren skrivit där. Om det är starthanteraren = den PIC går bootloader. Om det är användarkoden = den PIC går användarkoden. Ganska enkelt!

Använda dem båda, måste vi på något sätt växla mellan dessa två program. Denna övergång kan göras baserat på ett villkor, händelse eller något annat - det blir väldigt mycket som ett stort "om"-uttryck. Jag valde detta villkor vara spänningsnivån på en ingångsstift, heter USB-känsla i scheman. Detta stift var ansluten till USB-kontakten genom en resistor 5V stift. Om PIN-koden är på 5 [V] vid start, har PIC att verkställa den bootloader grenen av den enorma "om", om det är på 0 [V], användaren programkoden hade körs. Jag placerade användarkoden direkt efter bootloader koden, på adress 1000h. PIC18F4550 kontrolleras känsla pin stiftet upprepade gånger, så när USB-kabeln tas bort och 5 [V] försvinner från RD3, PIC hoppar till koden placeras på 1000h, tillämpning användarkod. Programkoden användaren kolla jag igen spänningsnivån på avkänningen klämma fast, om programmet ser 5 [V] på det, USB-kabeln har anslutits igen och PIC har att hoppa till startprogrammet. Jag gör detta hoppa till bootloader sätt med en inline församlingen "RESET" instruktion. Eftersom bilden börjar köra från adress 0, är det enklaste och vanligaste man kan göra att placera bootloader koden där, och användarkoden direkt efter startprogrammet.

Bootloader koden kan ändras för att kontrollera huruvida det finns en giltig firmware skriven i PIC. Detta görs genom att kontrollera minnet innehållet på adressen 1006h - 1007h. Efter varje lyckad programmering, bootloader skären "600D" (leet för "bra") på denna plats, vilket innebär att koden har skrivits in i PIC framgångsrikt - detta är vad det blir kontrolleras för giltighet. Vi måste ange i ansökan projektet användarinställningarna att denna plats inte bör skrivas, se bilderna för att se hur detta görs (ROM intervall anges att hoppa över denna plats när användaren programmets kod kompileras). Underlåta att göra detta kommer att resultera i fel verkligen svårt att upptäcka senare. Avsnittet där bootloader lögner måste också skyddas: detta görs genom avräkning programkoden hela användare av 1000h (kod offset parametern länkaralternativ). Bootloaders ligger vanligtvis i början eller slutet av programminnet - man måste vara försiktig att inte skriva över den! Jag ville lägga till några parametrization för den här enheten, det är därför intervallet 3000-3100 skyddas också. Du behöver det, bara den andra en!

Problem jag slog när du arbetar med bootloader

Kompilera projektet kommer att resultera i en hex-fil som genereras - detta måste flashad till PIC med en PicKit eller vad som helst. I äldre projekt jag sprang in i en främmande problem inte kunde verktyget USB bootloader upptäcka något. Jag bestämde mig att göra mätningar på den VUSB pin av PIC med min räckvidd, och nu jag rörde den PIN-kod med scope sond, välkända USB ljudet spelas och styrelsen fick erkännas! Jag trodde problemet gick bort, men så fort jag tog bort sonden, som slutat fungera igen. Jag insåg att allt fungerar när scope sond är på, även skriver, återställer - problemet skulle vara något som sonden fixar. Då tänkte jag: Vad har räckvidd sonder? Parasitiska kapacitans. Kondensatorn på VUSB stift var enorm i värde, och kunde inte filtrera bort högfrekventa ljud. En 100nF kondensator lades parallellt, och styrelsen erkändes omedelbart.

Att veta detta förskott, jag la en liten värde kondensator på originalet, USB kom på utan problem på första försöket! Lärdom!

Om din starthanterare fungerar, flash LED blinker programmet, felsöka det om det behövs och fortsätta att skriva några allvarligare saker, beskrivs i följande steg.