DOSYĆ POWSZECHNYM STANDARDEM DLA FORMY ZBIORU WYNIKOWEGO ASEMBLERA JEST TZW. HEXFILE, CZASEM ZWANY IBM HEX-File WIELE KOMPILATORÓW, ZWŁASZCZA C i C++ POTRAFI RÓWNIEŻ DOSTARCZAĆ WYNIKU KOMPILACJI I KONSOLIDACJI W FORMACIE.hex N.B. UŻYTKOWNICY MIKROKONTROLERÓW (M. IN. AVR i ARM), A RÓWNOCZEŚNIE ZWOLENNICY LINUXA SĄ OBDAROWANI WIELOMA PREZENTAMI, KTÓRE WARTO POZNAĆ! WEŹMY PRZYKŁAD DYSTRYBUCJI FEDORA (F14) ORAZ ARM: BEZ WIĘKSZEGO WYSIŁKU MOŻNA ZAUWAŻYĆ GRUPĘ PAKIETÓW, Z KTÓRYCH WYBIERAMY NP.: - arm-gp2x-linux-binutils - arm-gp2x-linux-gcc - arm-gp2x-linux-glibc - arm-gp2x-linux-kernel-headers BINUTILS TO MOŻE NAJWIĘKSZE ZASKOCZENIE: OBECNIE CROSS KOMPILATORY C I C++ ZWYKLE SĄ ZDOLNE DO ASEMBLACJI WSTAWEK LUB WRĘCZ AUTONOMICZNYCH PROGRAMÓW W JĘZYKU WEWNĘTRZNYM. OTOŻ BINUTILS POZWALAJĄ OBEJŚĆ SIĘ BEZ TYCH WIELKICH NARZĘDZI 1/9
WEŹMY PRZYKŁAD PROGRAMU, KTÓRY JEST TRYWIALNY, BO NIE O PROGRAM TU CHODZI:.globl _start _start: mov r0,#1 mov r1,r0 str r1,[r2] arm-gp2x-linux-as -o hello.o hello.s arm-gp2x-linux-ld -o hello.elf hello.o arm-gp2x-linux-objdump -D hello.elf > hello.lst hello.elf: file format elf32-littlearm Disassembly of section.text: 00008074 <_start>: 8074: e3a00001 mov r0, #1 ; 0x1 8078: e1a01000 mov r1, r0 807c: e5821000 str r1, [r2] 2/9
MAMY TEŻ I TAKĄ FUNKCJĘ (ALE TO PEWNIE WAŻNE DLA BILL'A) : arm-gp2x-linux-objcopy -O binary hello.elf hello.bin ZAŚ SUPER PREZENT DLA NAS, TO: arm-gp2x-linux-objcopy -O ihex hello.elf hello.hex NASZ PRZYKŁAD POKAŻE SIĘ W FORMIE: :0C8074000100A0E30010A0E1001082E574 :040000030000807405 :00000001FF 3/9
JESZCZE RAZ, BARDZIEJ KOMPLETNIE O.hex : :llaaaatt[dd...]cc * : is the colon that starts every Intel HEX record. * ll is the record-length field that represents the number of data bytes (dd) in the record. * aaaa is the address field that represents the starting address for subsequent data in the record. * tt is the field that represents the HEX record type, which may be one of the following: 00 - data record 01 - end-of-file record 02 - extended segment address record 04 - extended linear address record * dd is a data field that represents one byte of data. A record may have multiple data bytes. The number of data bytes in the record must match the number specified by the ll field. * cc is the checksum field that represents the checksum of the record. The checksum is calculated by summing the values of all hexadecimal digit pairs in the record modulo 256 and taking the two's complement. 4/9
NIBY ZGODA, ALE....hex JEST ISTOTNIE POWSZECHNYM STANDARDEM ALE POŚREDNIM KIEDY PRZYCHODZI DO DIALOGU Z BOOT LOADER'AMI TO PRAWIE KAŻDY PRODUCENT MA SWOJE WŁASNE POMYSŁY. ZWYKLE ZAKAMUFLOWANE W FIRMOWYCH NARZĘDZIACH ŁADUJĄCYCH KODY DO PAMIĘCI MIKROKONTROLERÓW. GDY JEDNAK POTRZEBUJEMY ZROZUMIEĆ DIALOG ZASZYTEGO W MIKROKONTROLERZE BOOT-LOADER'A, MINILOADER'A, BOOTSTRAP LOADER'A..., BO JESTEŚMY OSZCZĘDNI, LUB DOCIEKLIWI, LUB MAMY INNE WAŻNE POWODY, TO OKAZUJE SIĘ, ŻE POMYSŁOWOŚĆ LUDZKA NIE MA GRANIC TEN TON JEST ISTOTNIE KRYTYCZNY, BO WYSTARCZY ZDAĆ SOBIE SPRAWĘ Z TEGO, ŻE JAKKOLWIEK UPIĘKSZONY JEST DIALOG, TO NIE WNOSI ON ABSOLUTNIE NICZEGO, CZEGO NIE MA JUŻ W FORMACIE.hex! JEST TO TŁUMACZENIE.hex W LOCIE, ZWYKLE LINIA W LINIĘ. NAJPIERW PRZYKŁAD DLA 8051 OD ANALOG DEVICES ======>./812/Uc004_v30.pdf 5/9
A JAK TO ROBIĄ DLA ARM? ARM MA WIELU PRODUCENTÓW, A KAŻDY MOŻE PRODUKOWAĆ SZEREG TYPÓW ARM... WEŹMY PRZYKŁAD PHILIPS LPC2114 / 2124 / 2212 / 2214 CHIP MA FABRYCZNIE WGRANY OK 8k BOOT LOADER, KTÓRY REZYDUJE W REGIONIE 0x0001 E000 : 0x0001 FFFF. PRZY KAŻDYM RESET JEST ODWZOROWYWANY PONADTO W NAJWYŻSZYCH ADRESACH CZYLI OD 0x7FFF E000. BOOT LOADER SŁUŻY PROGRAMOWANIU CZY REPROGRAMOWANIU MIKROKONTROLERA, (FUNKCJA IN_SYSTEM_PROGRAMMING ), A TAKŻE WYMAZYWANIU I ZAPISYWANIU FLASH MEMORY PRZEZ APLIKACJE UŻYTKOWNI- KA (FUNKCJA IN APPLICATION PROGRAMMING ). TU ZAJMIEMY SIĘ ISP KAŻDE WŁĄCZENIE ZASILANIA LUB RESET LOADER MOŻE PRZEJŚĆ DO FUNKCJI ISP. DLA TEGO MUSZĄ BYĆ SPEŁNIONE WARUNKI: - TECHNICZNO-CZASOWE : PO ODPOWIEDNIO DŁUGIM OKRESIE LOW, PIN RESET P0.14, NASTĘPNIE PRÓBKOWANE ZEGAREM (X1). PO OK. 3 ms JEŚLI P0.14 JEST HIGH TO OZNACZA, ŻE NIE MA ZAPOTRZEBOWANIA NA ISP. - ZATEM, TRZEBA SPRAWDZIĆ, CZY JEST WGRANA POPRAWNA POPRAWNA APLIKACJA - I CZY JEST UAKTYWNIONY WATCHDOG. 6/9
7/9
KRYTERIUM POPRAWNA APLIKACJA MA SWOJĄ LITURGIĘ: JAK ZWYKLE W PROCESORACH CYFROWYCH PRZESTRZEŃ NAJNIŻSZYCH ADRESÓW (W ZASADZIE PAMIĘCI KODU, ALE TU MAMY ARCHITEKTURĘ VON NEUMANN'A...) ZAJMUJĄ WEKTORY PRZERWAŃ. W NASZYM PRZYPADKU WŚRÓD NICH, W LOKACJI 0x000 0014 MA ZNAJDOWAĆ SIĘ SUMA KONTROLNA ( RACZEJ JEJ 2'S COMPLEMENT) WSZYSTKICH WEKTORÓW. WŚRÓD NICH POD ADRSEM 0x0000 0000 POWINIEN BYĆ SKOK DO STARTU APLIKACJI (TO JEST JAK PRZERWANIE OD RESET CZYLI PRZERWANIE O NAJWYŻSZYM PRIORYTECIE). JEŚLI KRYTERIU TO NIE JEST SPEŁNIONE, PROCESOR ROZPOCZYNA PROCEDURĘ AUTO-BAUD JEST TO SPECJALNY DIALOG HOST'A Z MIKROKONTROLEREM. PROWADZONY PRZEZ PORT SZEREGOWY (COM0, 8 BITÓW DANYCH, 1 STOP, NO PARITY) HOST WYSYŁA?. DOBRY ZNAK DLA SYNCHRONIZACJI: 0x3F. A MIKROKONTROLER PRÓBKUJE CZAS SWOIM ZEGAREM I UCZY SIĘ ILE ZAJMUJE JEDEN BIT. NASTĘPNIE WYSYŁA ŁAŃCUCH Synchronized<CR><LF>. TAKIM TEŻ ŁAŃCUCHEM ODPOWIADA PC. PO CZYM NASTĘPUJE REALIZACJA ISP COMMUNICATION PROTOCOL =====> 8/9
ISP COMMUNICATION PROTOCOL KAŻDA KOMENDA TO POJEDYNCZY CIĄG ZNAKÓW ASCII ZAKOŃCZONY <CR> <LF> DANE SĄ PRZESYŁANE I ODBIERANE W UU-ENCODED FORMAT (3 BAJTY DANYCH KONWEROWANE SĄ W 4 BAJTY ZNAKÓW ASCII, KTÓRE MAJĄ REPREZENTACJĘ DRUKARSKĄ) ISP COMMAND FORMAT: COMMAND PARAMETER_0, PARAMETER_1... PARAMETER_N<CR>>LF> DATA - JEŚLI SĄ ISP RESPONSE FORMAT: RETURN_CODE<CR><LF>RESPONSE_0<CR><LF>RESPONSE_1<CR><LF>... - - REPERTUAR KOMEND: UNLOCK U READ PART ID J SET BAUD RATE B READ BOOT CODE VER. K ECHO A COMPARE M WRITE TO RAM W READ MEMORY R PREPARE SECTOR P COPY RAM C GO G ERASE SECTOR E BLANK CHECK I 9/9