Problemi sa prevođenjem TASM u hex

[Gromit]

Pozdrav!

Zanima me kako kompajlirati program pisan u TASM-u (Turbo Assembler), kojeg su u velikoj mjeri koristili u EPE-u oko 2000-te u validni HEX!
Evo za primjer program za PIC-funkcijski generator, kojeg je radio kolega Feko: nije bitno sada za šta je taj program, nego je g.Feko stavio u arhivu 2 hex-a - jedan "krivi" i jedan "koji valja". Usporedio sam ta dva HEX-a - razlika je samo što u onom nevaljalom ima niz nula u prvoj liniji i fali jedan redak koda na samom kraju - pogledajte prikvačene TXT-ove! Probao sam sa TK3Progom ali dobijam stalno onaj isti "krivi" HEX kako god da stavim postavke! Također sam preveo izvorni kod u MPASM, pa ga preko MPASMWin-a preveo na HEX - taj je hex skroz drukčiji, ne znam možda je i OK, dva compilera ne moraju dat isti HEX, ali ja bi rađe da mogu dobit onaj "ispravni" Fekin kod, jer mislim prčkat/prerađivat ASM, pa da na isti način budu prevedeni.

Problematični fileovi.rar

Tu su svi problematični fileovi u TXT

(7.69 KiB) Downloaded 319 times

Dakle stavio sam izvorni (T)ASM, neispravni i ispravni HEX, pa ako netko zna kako dobit najlakše ovaj ispravni nek mi javi (nisam baš preveliki stručnjak!)!

TIA!

[InTheStillOfTheNight]

Kaga gledas HEX, moras znati sto tocno gledas...

Ne ide ti citav HEX u kontroler, evo odvojio sam ti malo te redove da ti bude jasnije...

Evo iz nekog tvog reda:
:08 0008 00 3C 28 8B 01 8B 13 8B 1B BC

Prvi byte HEX-a uvijek govori o broju data byte-ova u redu:
08 znaci da ih ima 8

druga 2 byte-a govore o adresi prvog zapisa u FLASH, dakle krece od adrese:
0008

00 uvijek govori o tome da se data podatci zapisuju u FLASH

Ovo zapravo ide u FLASH
3C 28 8B 01 8B 13 8B 1B

i na kraju je checksum reda, to ne ide u FLASH
BC
---------------------------------------------
Onaj prvi red ti odmah kaze da imas 08 data byte-ova, pa prebroj:
3C 28 8B 01 8B 13 8B 1B

Dakle one nule ne bi trebale biti problem jer imalo dobar programator bi znao da u tom redu nema niti jedan data byte i jednostavno preskocio... Ono sto ti zapravo trebas usporediti u redovima HEX-a je samo ono sto ide u FLASH, dakle u ovom redu:
3C 28 8B 01 8B 13 8B 1B


Pogledas li ovako:
prvi file:
:08 0008 00 3C 28 8B 01 8B 13 8B 1B BC
:10 0010 00 06 28 3C 28 82 07 33 34 33 34 32 34 2C 34 06 34 F7
:10 0020 00 0C 34 01 34 02 34 82 07 10 34 E8 34 64 34 0A 34 66
:10 0030 00 82 07 27 34 03 34 00 34 00 34 82 07 FF 34 FD 34 50

-----------------------------------------------
drugi file:
:00 0000 00 00
:08 0008 00 3C 28 8B 01 8B 13 8B 1B BC
:10 0010 00 06 28 3C 28 82 07 33 34 33 34 32 34 2C 34 06 34 F7
:10 0020 00 0C 34 01 34 02 34 82 07 10 34 E8 34 64 34 0A 34 66
:10 0030 00 82 07 27 34 03 34 00 34 00 34 82 07 FF 34 FD 34 50

Sve je zapravo isto, a ove nule mozes sve obrisati...

[InTheStillOfTheNight]

sto se tice ovog reda na kraju, predpostavljam da na to mislis:
:02400E00393F38
Idemo njega rastaviti:
:02 400E 00 39 3F 38

broj byte-ova =
02

Adresa:
400E

Tip zapisa:
00, data zapis na neku visoku adresu, moze se provjeriti sto je tamo u MCU

2 Byte-a su:
39 3F

i checksum je 38...

Dakle jos neki vrag upisuje u MCU, moguce da su neke postavke, a uostalom mozes dodati samo taj red prije zadnje linije i to ti je to... mora raditi.

Svaki HEX zavrsava sa ovim :00000001FF
Adresa 0, broj biteova 0, ali tip zapisa 01, checksum FF... To oznacava kraj HEX datoteke...

Inace adresa 400E je jako visoka za compile ovog programa i vjerojatno je dio postavki za start MCU-a. To se vecinom podesava u editoru prije compile...

[Gromit]

Je, mislio sam na taj dio na kraju!
Ovo o "sastavu" HEX-a manje više znam, slično je, ako ne i isto kao i kod "malih" Atmela.

Ove nule na početku nisu problem, u pravu si, ili ih programator ignorira, ili ih jednostavno obrišeš i to je to!
Ali ovaj (pred)zadnji redak me muči, nemam pojma koje je njegovo značenje! Adresa je visoka, da nije dio PIC-ovog eproma?
Kako god, ne mogu nikako namjestit postavke da mi izbaci taj redak; mogu ga zalijepit na HEX koji dobijem, ali ne znam jel to nešta univerzalno, ili samo vrijedi za taj program (ili čak samo za taj PIC (16F877))?

Kolegi Feki je netko prije dvije godine "popravio" ovaj "krivi" file, no taj čovjek je sad nedostupan i Feko mi ne zna reč kako ga je generirao (taj predzadnji redak mislim).

Inace adresa 400E je jako visoka za compile ovog programa i vjerojatno je dio postavki za start MCU-a. To se vecinom podesava u editoru prije compile...

Možda se radi o config.wordu, ali to su samo 2 bytea, ne vjerujem (iako, zašto ne, kad bolje razmislim!)?

Budem to proučio,
hvala u svakom slučaju InTheStillOfTheNight !

[Gromit]

Je, izgleda da se radi o konfiguracijskoj riječi!
Jedino mi ne štimaju adrese - ovo je iz datasheeta za 16F877:
"The configuration bits can be programmed (read as '0'), or left unprogrammed (read as '1'), to select various device configurations. The erased, or unprogrammed value of the configuration word is 3FFFh. These bits are mapped in program memory location 2007h. It is important to note that address 2007h is beyond the user program memory space, which can be accessed only during programming."

Ne znam, dakle, otkud ova adresa 400E?
Ali našo sam u HEX-ovima za PIC16f690 istu tu adresu(400E), drukčija 2 bytea, a taj PIC isto ima rezerviranu lokaciju za config.word na 2007h !? Možda kava druga vrsta notacije (mali/veliki endian ili sl)?

[InTheStillOfTheNight]

Ajme kretena, da se na ovo vec nisam potepao par puta ne bi nista rekao...

Tvoja adresa hex-a 400E je zapravo:
0x400E/2 = 0x2007
E to je sad vec configuration bits
Zaborabih napomenuti tu malu sitnicu
Stvarni FLASH je u WORD-u dakle 2 byte-a, zato u HEX-u djeliš adresu jednog byte-a da dobiješ ono što ide na stvarnu adresu FLASH-a.

Da bi dobio isti HEX, u compileru moraš podesiti postavke za configuration bits, i tek tada ce ti compiler dodati ovu liniju na kraju.

[InTheStillOfTheNight]

Config trebas podesiti na 39 3F, mozes pogledati sto to tocno znaci za PIC u datasheet-u, a sad kako se to podesiti u tom tvom necemu, pojma nemam, ne znam ni PIC, tako da ti tu vise ne mogu pomoci...
Eventualno netko tko radi s PIC-em ti moze objasniti kako postaviti config bits u tom tvom necemu...
Na kraju krajeva, barem znas sto trebas napraviti, a to kako napraviti je jednostavniji dio posla

[InTheStillOfTheNight]

Ovo o "sastavu" HEX-a manje više znam, slično je, ako ne i isto kao i kod "malih" Atmela.

Hex file, onaj nama znam nije niti atmelov niti PIC-ov, baš je intelov i koristi se još od 70 godina. Koliko sam ja upoznat postoje samo 3 tipa intelovog HEX-a: 8, 16 ili 32 bitni intelov HEX zapis... Intelov Hex samo je zapis nečega što mora negdje ići.

Zapis HEX-a identičan je za sve mikrokontrolere koji zapisuju stojne instukcije u ovom obliku. Zato znam pronaći u HEX-u sve što tražim, ali ne znam napamet kako u nekom pic, techno-basicu natjerati compiler da mi u HEX zapiše ono što želim.

Ovo napisah da ne razdvajamo HEX atmela od HEX-a PIC-a jer naprosto oba HEX filea samo govore na koju adresu što upisati... Principijalno HEX je isti za obe porodice, samo se druge stvari upisuju na druge adrese

[Gromit]

OK, sad je sve jasno! Točno ti HEX-ovi su Intelov izum, zajednički za sve MCU-e Atmele i PIC-ove. Ovaj za PIC-ove je 32-bitni (ne znam jel za sve, al za 16F877 je).

Dakle fino generiram onaj "krivi" HEX, izbrišem onaj prvi redak sa nulama, a predzadnji redak koji nedostaje ne treba ni bit i HEX-u - kad upisujem program sa PICKit-om ručno si podesim config.word kak mi paše i to je to!

Hvala lijepa InTheStillOfTheNight !!!

[InTheStillOfTheNight]

Približno točno kolega... Ako mijenjaš 2 data byte-a to znači da ti je i checkum drugačiji.
Izračunati ću ti ga za tvoj red, čisto da skužiš princip reda:

Ovo je hex red:
:02400E00393F38

Znaš da je na kraju checkum byte, a on je 0x38, njega brisem da ga mogu ponovno izracunati:

Dakle ovo je bez njega:
:02400E00393F

Checkum HEX-a racunas ovako:
od zbroja svih byteova uzmeš onaj niže važeći te računaš XOR sa 0xFF i uvećaš rezultat za 1.

Ajmo probati:
Zbroj 02+40+0E+00+39+3F = C8

C8 je onaj niže važeći, jer da je rezultat bio recimo B54C onda bi 4C bio niže važeći.

Napravis C8 XOR FF i dobijes 37

Tome 37 dodas 1 i evo ti onaj gore 38
-----

U slucaju da mjenjas postavke config bitova, moras pravilno napisati ovaj proracun u HEX datoteci, inace ce te programator odjebati...

Za svaki red HEX datoteke mozes pokusati napraviti isti proracun i checksum mora biti tocan, inace HEX datoteka nije dobro zapisana.

[InTheStillOfTheNight]

Inace, bolje ti je nauciti kako to u tvome compileru podesiti... Dobro je znati što postoji u HEX datoteci, ali ne smiješ ne uciti mjenjati stvari tamo... Compiler je taj koji se treba brinuti o onome o cemu ti uopce ne zelis razmisljati...

[Gromit]

Ove upute o checksumi sam "učio" 100 puta do sad, uvijek ili zaboravim, ili ne skužim do kraja! Sad ću ove tvoje upute (a ne mogu bit jasnije) fino copy/paste u neki txt da ih uvijek imam blizu !

Kod ovih Atmela, recimo 89C2051, sam baš ono, secirao byte po byte hex-koda, točno sam znao gdje šta treba bit, to bi svi koji imalo rade s programiranjem trebali znat (ne mislim pod "programiranje" samo ono kad skineš odnekud HEX, pa ga samo bez razmišljanja prebaciš s kakvim programatorom u MCU)!

Buduči da radim s PICKitom2 (Sure-ov klon, radi ko švicarski sat, čak i "logic analyser", prog-to-go itd.) samo u posebnom prozoru klliknem na kućice od 1 (ili 0) do 13 - i eto config.riječi, pa ne moram računat hex-vrijednost posebno! Čak se može dodat svoja signatura (malo ljudi zna da se to može preko PICKitovog sučelja (tzv."mem-test"))!

THX!