Svenska ElektronikForumet

Tittade lite på källkoden för en PIC18 bootloader. Går samma trick att göra på alla PIC modeller, samt AVR ..?

Sen borde det gå att göra om mottagningsrutinen på sätt så att den hämtar programmeringsdatat från ett multdrop nätverk istället. Skulle det fungera?

Skulle vara ett rätt smidigt sätt att kunna uppgradera ett helt nätverk på en gång.

Vilket "trick" ?

En bootloader kan i princip köras på alla med "self write".

> från ett multdrop nätverk istället.

Du menar med separata adresser för varje målprocessor ?

Vilka PIC familjer klarar "self write" ..? (tänkte mest på PIC10, 16 och nivån bättre än PIC18)

Separata adresser för varje målprocessor. Iofs skulle man kunna köra broadcast och programmera ett helt gäng på samma gång. Om dom noder som missar begär omsändning.

För bootloader till AVR kan du kika på min:

http://www.sk-electronics.com/sk-monito ... d-v0.2.zip

hur den funkar står närmare beskrivet här:
http://www.elektronikforumet.com//forum ... 767e4c5777

Verkar som ideén går att realisera isåf..

> Vilka PIC familjer klarar "self write" ..?

Databladen har naturligtsvis "sanningen".
Det går även att selektera fram m.h.a verktygen på www.microchip.com

> (tänkte mest på PIC10...

Ingen

>, 16...

En hel del

> och nivån bättre än PIC18

Väldigt många (alla?)

blueint skrev:Sen borde det gå att göra om mottagningsrutinen på sätt så att den hämtar programmeringsdatat från ett multdrop nätverk istället. Skulle det fungera?

Japp, jag gjorde det för det här företagets bussanslutna larmprylar: www.caretech.se

Jag la till ett busskommando som startar bootloadern (med hjälp av det väljer man alltså ut vilka enheter som man vill flasha). Sen i själva protokollet som bootloadern lyssnar på så lade jag till en siffra som identifierar produktmodell, så att man inte flashar in ett inkompatibelt program.

Sparar enormt mycket tid jämfört med den gamla metoden att skruva upp varje burk och plocka ur PICen ur sockeln, flasha om, sätta tillbaka, skruva ihop burken, konfigurera den och hoppas att inga pinnar har gått av...

Finns det någon spärr mot "obehörig" omflashning. Samt hur löste du situationen om flashningen inte var komplett ..?

Den enda spärren var att kolla att det var rätt program till rätt produkt som flashades in.

Så här gjorde jag:

1. Flashningsprogrammet skickar kommando till utvalda enheter.

2. Enheterna som valts ut skriver ett värde till EEPROM på en viss adress och startar om.

3. Bootloadern hittar värdet och, istället för att boota som vanligt, väntar den på data.

4. Första blocket som skickas innehåller antal block i hela programmet och en checksumma för hela.

5.När alla block har tagits emot kontrolleras checksumman. Om den stämmer tas EEPROM-värdet bort och enheten startas om.

6. Bootloadern ser att EEPROM-värdet är "normalt" och bootar det vanliga programmet.

7. Flashningsprogrammet kan nu kommunicera med enheten och tala om att flashningen har lyckats.

Varje block som skickas har också en checksumma och ett sekvensnummer. Om ett block blir fel eller saknas så stoppar den. Flashningsprogrammet kan då köra igenom hela sekvensen ett varv till och då tar den förhoppningsvis vid där den stannade.
I praktiken så var det ytterst sällan några problem med checksummor eller saknade block.

Lite sidospår.. men hoppas metoden fungerar för open-collector också

Tanken var att kunna byta kommunikationsprotokoll. Dock får man ha något basprotokoll att falla tillbaks på

digitaliz, Hur ser du till att nya enheter upptäcks.. ?, är det master som styr allt eller kollisons detekt modell ethernet?

I det här fallet var det ett gammalt protokoll där mastern och alla slavar måste programmeras med adress.

Men jag skrev en discovery-/kollisionsdetekteringsrutin a la Ethernet i ett annat 485-projekt. Man får lyssna innan man sänder och ha en "preamble" före meddelandena. Sen kan du ha olika fördröjning mellan tecknen i "preamblen" där fördröjningen bestäms av enhetens adress, och lyssna mellan varje tecken. Då blir kollisionsrisken mycket liten.

Men hur hittar isåf din discovery-/kollisionsdetekteringsrutin andra enheter ..?
1-Wire använder binärträds analys. Vilket verkar rätt effektivt.

I Ethernet finns inget av den sorten. Om man inte skickar broadcast ping och ligger å lyssnar.

Kollisionsundvikandet är som i Ethernet, sen så skickar alla enheter ett "discovery"-meddelande vid uppstart och en gång per minut som ett slags ping för att tala om att de fortfarande är anslutna.

Binärträdsmetoden är väldigt effektiv om du ska köra open collector, men jag tror den skulle bli vansklig att implementera på ett 485-nät...

Vad bygger du för nåt förresten?

Tänkte styra olika 230Vs apparater, samt kolla temperaturer etc..
Inte direkt för åldringar

Din metod fungerar uppenbarligen. Fast den fyller nätet i onödan.

Inte i onödan om man vill veta att allt är anslutet

Men jag skulle inte ha nåt emot att få enheter för temperaturavläsning och styrning av 220 V i mitt nät, man kan ju ta tempen på åldringarna och släcka ljuset när... nä... nu ska vi inte vara såna