Home Automation Domotica Forum Europe, Bwired Forum

Na jaren prima gedaaid te hebben wilde ik eens experimenteren met de nieuwere firmware versie,
en omdat ik nog wat 16F88 heb liggen was dat de keuze,

Maar tot mijn verbazing zeurt PICkit over de HEX file dat deze te groot zou zijn...
nog eens de HEX gedownload van de website, maar de melding blijft exact hetzelfde.
Wanneer ik versie 4.3 probeer is er niks aan de hand.

Met meer dan 1000 downloads zou je toch zeggen dat iemand anders dit ook gehad zou hebben.


Verschillende PICkit versies geprobeerd maar de melding is bij allen hetzelfde...

Grtzz Mark

De firmware voor de PIC16F88 is in de loop der tijd dusdanig gegroeid dat het volledige flash geheugen nodig is om alles erin te kunnen proppen. Het probleem is alleen dat de linker nog 2 extra instructies toevoegt. Voor zover ik begrijp is dat nodig voor code die in C is geschreven. Maar dat is bij de OTGW firmware niet het geval. Omdat ik die ruimte niet kon missen heb ik de linker verteld dat hij die instructies maar buiten de fysiek aanwezige flash moet plaatsen. Nutteloze instructies hoeven geen geheugen in beslag te nemen. Dat werkt prima, alleen geeft een PIC programmer er misschien een waarschuwing over. Die kun je negeren.

De reden dat niemand anders dit ziet is dat 999 van de 1000 gebruikers de firmware niet met een PIC programmer laadt. De meeste mensen gebruiken de zelfprogrammeer functionaliteit van de firmware.

Hoi Schelte

Bedankt voor het antwoordt, ondertussen ben ik nog een beetje aan het klooien geweest om dit wat nader
te onderzoeken en daarvoor heb ik eerst maar eens een .BIN gemaakt van de .HEX
En wat direkt opvalt is dat de .BIN file van de originele .HEX 24580 bytes wordt en de .BIN van een uitgelezen .HEX
17408 bytes wordt...

Wanneer je deze twee vergelijkt zijn ze nagenoeg gelijkt (alleen een 0x00 voor een 0x3F in EEPROM) maar dat
zullen geen showstoppers zijn.
Maar als je dan helemaal aan het eind van de .BIN file kijkt staat er dit...
En dat doet mij denken aan de BANDGAP en OSCCAL calibratie bytes die normaal aan het eind van flash staan,
en als ik mij niet vergis is 0x34 RETLW in PIC mnemonic.
Bij interne oscillators deed je als start eerst een CALL naar FLASH top en kreeg je de calibratie byte(s) in W terug.
Misschien neemt de linker deze calibratie bytes alvast mee?
Al hoort dit normaal in de programmer te gebeuren...

Het programma gedeelte van beide .BIN files zijn identiek dus ik ga er vanuit dat alles gewoon gaat werken.

De reden dat niemand anders dit ziet is dat 999 van de 1000 gebruikers de firmware niet met een PIC programmer laadt. De meeste mensen gebruiken de zelfprogrammeer functionaliteit van de firmware.

Tja, dat zal een beetje hobby deformatie zijn, begin 90's ben ik begonnen met een LudiPipo en een 16c84 die toen nog EEPROM microcontroller
werd genoemd pas later ging men over op de benaming FLASH en werd het de 16f84.
Als ik nog wat met PIC doe is dat nog steeds in UltraEdit32 met een PIC ASM template, want bijna 1GB downloaden voor de MLAB X IDE om vervolgens
code te maken voor een 8kByte microcontroller gaat geheel tegen mijn bitneuk hart in...

Grtzz Mark

Ik zie die 0x00 versus 0x3F niet terug in jouw plaatje. Maar dat kunnen heel goed bits zijn van geleerde Unk data ID's of iets dergelijks.

Ik heb voor die twee overbodige woorden in het linker script adres 0x3000 beschikbaar gesteld. Dus dat klopt precies met wat je ziet in je .BIN file.

Het zou goed kunnen dat het idee achter die twee instructies is dat de programmer ze kan vervangen door de BANDGAP en OSCCAL waarden. Alleen slaat dat bij de PIC16F88 nergens op. Die heeft die gegevens niet.

Als je tegenwoordig de nieuwste MPLAB X IDE van 1GB downloadt, dan kun je nog niets want er zit helemaal geen assembler meer bij. Ik heb wel eens geprobeerd iets in C te schrijven, maar dan is het beperkte flash geheugen al half vol als je code nog bijna niets doet. Ik ben tegenwoordig overgestapt op de assembler van mputils. Gewoon de code schrijven in mijn favoriete editor en dan bouwen met een makefile.