W dniu poniedziałek, 11 maja 2020 21:30:25 UTC+2 użytkownik Janusz napisał:
> W dniu 2020-05-11 o 20:03, Dawid Rutkowski pisze:
> > W dniu poniedziałek, 11 maja 2020 17:23:54 UTC+2 użytkownik Janusz napisał:
> >> W dniu 2020-05-11 o 13:45, Pawel "O'Pajak" pisze:
> >>> W dniu 2020-05-11 o 12:29, Grzegorz Niemirowski pisze:
> >>>> W jakim formacie masz dane wejściowe?
> >>>
> >>> Mogę skonwertować dowolnie. Np. 0A,17,F0,30,00,6C itd. Mają wypełnić
> >>> EEPROMa po kolei. Może być od addr 0. Po prostu dziwne mi się wydaje, że
> >>> taki Notepad++, czy inne edytory hex nie maja opcji "zapisz jako", albo
> >>> "eksportuj" do hex/eep.
> >>> Wierzyć mi się nie chce, że ludzie nie liczą czegoś w arkuszu
> >>> kalkulacyjnym (bo tak szybciej) i nie zapisują tego do EEPROMu, żeby
> >>> procek nie musiał się męczyć z obliczeniami.
> >>
> >> Oczywiscie że robią, daja sekcję eeprom i tam dane, i tyle :)
> >> W AS4
> >> Sekcja __attribute_((section(".eeprom")))
> >> lub
> >> zmienna typu EEMEM.
> >
> > I co, po kompilacji dostajesz *.hex i *.eep?
> > Ale mundre ;>

> No do karmienia programatora wystarczy.

Ale tak to wymyślili, że tworzą się dwa pliki?
W sumie najprostsze, nie trzeba wymyślać sztucznych konwencji.
A jak ktoś chce jeden plik, to będzie miał w ELFie.

> > Można też napisać bardzo trudny program:
> > #include <unistd.h>
> > int main(void)
> > {
> > unsigned char dane={0x.., ...};
> > write(1, dane, sizeof(dane));
> > }
> > i dostajemy na standardowym wyjściu plik binarny odpowiadający zawartości tablicy
dane.
> > Dalej avr-objcopy.

> I wyślesz to do programatora?

Bezpośrednio tego, co wyjdzie z powyższego programu, to akurat do mojego uisp wrzucić
nie można - ale skonwertowane avr-objcopy (masz to zapewne też w avr studio - OIDP
jest to gcc, binutils, avr-libc + jeszcze jakieś IDE - więc możesz sobie avr-objcopy
w wierszu poleceń windows odpalić) na intel hex albo motorola srec już można -
oczywiście trzeba kazać programatorowi wrzucić to do EEPROM, a nie flash, sam nie
zgadnie.

uisp jest fajny, jako dostępny w postaci źródłowej, więc mogę sobie do niego
dopisywać obsługę nowszych mikrokontrolerów. Najbardziej jestem dumny z dodania
ATmega2560/1 - jako posiadającego więcej niż 128kB (64k słów 2-bajtowych) flash. Jako
że kompilator już nie tak łatwo przerobić, drugie 128kB póki co mogę wykorzystywać
jedynie na dane (akurat tu jest sporo sampli mowy), kod wciąż ograniczony do
pierwszych 64kB. Trzeba było też pouczyć się linkera, bo "normalnie" dane umieszczane
są na początku flasha, zaraz za wektorami przerwań.

To i tak lepsze niż numer, jaki zrobił projektant poprzedniej wersji tego urządzenia
- podłączył 128kB pamięci kodu do 8051 w tej sposób, że A16 było podłączone do
dodatkowego wyjścia, a w tablicy z adresami sampli było dodatkowo miejsce na
informację, jak tą nogę ustawić przy odgrywaniu.
Żeby jednak jednocześnie nadal mógł się wykonywać kod, był on umieszczony w tych
128kB w dwóch kopiach - od adresu 0 i od adresu 65536 - a na sample pozostawało
128kB-2*wielkośćKodu miejsca.

Drugą ciekawą możliwością, jaką daje dostęp do źródeł, jest możliwość zmiany pinów
portu równoległego, do których podłączony jest "programator" DAPA - w sytuacji
sukcesywanego przepalania się tych pinów ;>

Aha, i jeszcze co do danych.
Do EEPROM warto wrzucać tylko dane, które rozróżniają poszczególne urządzenia z tym
samym programem - np. adresy.
Jeśli są to dane statyczne, to bez sensu wrzucać je w EEPROM.
Jak danych jest mało i zmieszczą się w wolnym SRAMie (a SRAMu AVRy zwykle mają więcej
niż EEPROMu), to po prostu robimy statyczną tablicę.
Jak danych jest więcej, to robimy tablicę
unsigned char dane[] __attribute__((progmem)) = { 0x.., ...};
i odwołujemy się do niej zamiast:
n=dane[x];
to:
n=__LPM(dane+x);
Troszkę to wygodniejsze niż:
n=eeprom_load(x);
i do tego można w dość wygodny/automatyczny sposób korzystać z kilku tablic, zamiast
samemu pamiętać, od którego miejsce w EEPROM zaczyna się dana tablica.

Aha, i dane mogą być nawet w csv:
unsigned char dane[] __attribute__((progmem)) = {
#include "dane.csv"
};