Kul med PIC församling - episod 18 (5 / 5 steg)

Steg 5: programvara

Programvaran länk nedan. Medan det är måltavlan för 16F688, är det lätt portas till andra versioner av bilden. Se bara till att du väljer en som med asynkron seriell port förmåga. Du måste också ändra raden som identifierar den PIC versionen (lista =) och INCLUDE-filen men de är intuitivt förändringar. Den __CONFIG linjen kan också behöva tweaking bara för att en eller två av de etiketter som används är stavat fel i några av inkluderade filer.

Programvaran i princip efterliknar de kommandon vi skickas manuellt från terminalprogrammet. På lämpliga punkter väntar den på de förväntade svar från ESP8266 innan utfärda ytterligare kommandon. De kommandon som skickas och svaren förväntas behöva ändra om på kommandot som uppdateras i nyare versioner av ESP8266. När du skickar ut kommandosträngarna och dummy meddelandet PIC använder indirekt adressering av RAM platser i banker 0 och 1. Koden för att initiera dessa minnesplatser är beläget i slutet av listan. Dessa äldre bilder är tyvärr begränsade deras indirekta adressering anlagen så vi inte kan bara bädda in strängarna i flashminnet som vi gjorde för LCD-grafik skärmen i avsnitt 13. Projektet använde en nyare 16F1847 PIC och det skulle vara lätt att port detta program till att nyare PIC om du så önskar.

För att använda en gemensam rutin att skicka strängar vi kunde har antingen gått en stränglängd på rutin eller helt enkelt lägga till ett "slutet-av-string" tecken i varje sträng. Det andra alternativet är vad jag valde och för att förenkla it ytterligare jag använde det numeriska värdet 0. Som gör att koden för att ladda nästa värde och kontrollerar sedan om lastning orsakade flaggan noll anges i Status registrera. String längder definieras ha utrymme för en vagnretur och en radmatning för var på kommando och slutet-av-sträng-ID för alla utgångar. Observera att data som skickas efter att skicka kommandot CIPSEND inte behöver en vagnretur och radmatning.

Är det värt att notera att ESP8266 skickar tillbaka en massa data som vi verkligen inte bryr sig om. Därför att ha följetong ta emot koden som en avbrottshanterare vore inte en bra väg att gå. Problemet är dock att bara röstningen för Svaren kommer att orsaka mottagare bufferten att svämma över. Det är därför den "Overflow" handler i koden är mycket viktigt. Det gör att PIC att bara klara upp översvämningen på sin fritid och sedan vänta på att de förväntade svar. I tidigare listor där jag inte hade förväntat svämmar över använde jag den metod som beskrivs i databladet för inaktivera/aktivera den seriella porten. Det fungerade inte korrekt i detta program och jag misstänker att det hade något att göra med det faktum att sändaren inte kan ha varit klar innan översvämningen hanterades. På grund av att jag bytt till den andra metoden med att rensa overflow flaggan där bara den seriella mottagaren är aktiveras eller inaktiveras.

Skärmdump av PIC meddelanden att terminalprogrammet och webbsidan visas ovanför. Observera att "Hello World" budskapet är på två rader. Det beror på att meddelandet har en HTML-kommandot ingår (< br >) som gör en ny rad. Det är viktigt att notera eftersom de flesta något HTML kommando kan inkluderas i vad du skickar till webbsidan. Medan meddelandet i det här exemplet är statisk, kan du göra den dynamiska som passar dina behov. Helt enkelt ringa till ditt eget budskap att skapa rutin i rutinen "Send_Data". Som nämnts i avsnittet öppning som du kunde läsa en temperaturgivare, konvertera värdet till ASCII och matar sedan ut resultatet när ESP8266 får en webbsida connect-begäran. För applikationer som att en uppdatering av webbsidan kommer att orsaka PIC att skicka nya uppgifter så du inte behöver stänga och öppna webbsidan.

Tja, är det det för Episode 18 "Kul med PIC församling". Håll ögonen öppna för ytterligare episoder.