współpraca AVRStudio i programatora Bascom AVR

Oba programy korzystają z formatu Intel-HEX. Zobacz czy tak masz ustawione w AVRStudio, ale jest to format domyślny. Po drugie, zapisać możesz tylko do pamięci EEPROM, wpierw musisz uaktywnić segment tej pamięci dyrektywą ".eseg".

przeczytaj sobie application notes do avr, bodajze avr102.asm

jest tam dokladnie opisane kopiowanie z pamieci ram, eeprom i flash, wlacznie z programem testujacym.

Twój problem polega że nie wiesz jak działa instrukcaj LPM. Traktuje ona pamięc pogramu o organizacji baytowej a nie jak procek i kompiloator o organizacji "word" 2*baytowej .

więc

Adres podawany przez kompilator jest adresem o połowe mniejszym od oczekiwanego więc należy powiększyć go 2 razy

czyli :

.cseg
....... ;tresc programu

ldi ZL, low(Napis1*2)
ldi ZH, high(Napis1*2)

lpm

; gdy r0 <> 0

rcall Wyswietl_Litere_Z_r0

; gdy r0 = 0 koniec wyswietlania

.org 0x100
Napis1:
.db "Napis1", 0x00
Napis2:
.db "napis2", 0x00


i już będzie działało

P.S.

Tu masz więcej : http://www.atmel.com/dyn/resources/prod_documents/DOC1233.PDF

instrukcja lpm to jedna sprawa - eagle ma racje.

natomiast kwestia dyrektywy .org to co innego zupelnie:

programator Bascom'a nie interpretuje przesuniecia danych ta dyrektywa.

Po otworzeniu pliku hex przez programator CodeVision AVR wszystko wraca do normy- dane (np. napisy) umieszczone dyrektywą .org 0x100 faktycznie sie tam znajduja, co mozna sprawdzic edytorem.

Natomiast ten sam plik hex otworzony pod bascomem wykazuje umieszczenie danych w miejscu, jakby nie uzyto .org.

Wrzuc tu ten plik hex ze zlym rozmieszczeniem...

genetix: chyba cos ci sie pomylilo, plik hex to plik hex i dyrektywa .org nie ma nic do hex'a, bo jej tam w ogole nie ma (zostala juz wczesniej zinterpretowana przy kompilacji, a dokladniej to przy linkowaniu). Byc moze uzyta jako wstwka asemblerowa w BASCOMie jest pomijana, ale to dwie rozne sytuacje (choc tez tego nie wiem czy BASCOM ja pomija, choc jest to mozliwe, w koncu to BASCOM).

chodzi mi o to, ze sam bascom źle interpretuje pliki hex powstałe w innym programie. wrzuce wkrótce i z przyjemnością.

O wrzucenie pliku prosiłem autora postu, ale jeżeli takie masz to dawj je tu. A jeżeli BASCOM żle interpretuje pliki hex to znaczy, że BASCOM jest jeszcze gorszy niż mi się zdawało. Plik hex nie ma prawa zostać źle zinterpretowany - chyba że BASCOM używa innego formatu hex np. motorola...

skompiluj sobie pod Studio4 cos takiego:

;----- CUT HERE----

.org 0x000
.DB 0
.org 0x100
.DB "tdv"

;---- CUT HERE ----

otwórz to programatorem Bascoma a potem programatorem CVAVR (opcja Edit| FLASH)
i porownaj offsety.

PS. Oba uzywaja tego samego formatu INTELa (przynajmniej w teorii)
niemniej jednak plikow hex z avrstudio nie czyta program hex2bin zamieniajacy format hex na binary

Sorry ale nie posiadam BASCOMA (na całe, jak widze coraz większe, szczęście), więc całe otwieranie traci sens, zapodaj hex'a konkretnego.

genetix twój problem wywodzi się z tąd ze pamięc uC AVR jest 16 bitowa a nie 8 bitowa. Co pociąga za sobą takie konsekwencje.


Jeśli napiszesz

.org $100

. db $12, $34

to kompilator zrozumie że chcesz wpisać następne instrukcje/ dane będą wpisywane pod adres $100 komórki pamięci 16 bitowej. Jeśli zrzucisz to teraz do pliku hex który jest zapisem danych 8 bit wszystkie adresy zostaną powiększone dwu krotnie więc plik będzie postaci

02 0200 00 12 34 xx

02 - bo dwie dane

0200 -adres wpisywania i pomimo deklaracji $100 masz tu $200 bo $100-*16 bit = $200 * 8bit

12 34 - to nasze dane

xx - suma kontrolna


jeśli w Bascom ( chyba zacznę pisać go z malutkiej literki - bo same problemy z tym ...) traktuje pamięc programu jako baytową to poprostu bascom bas-error , bas-big-error