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 ;>

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.
A program jest trudny, bo jako całość zawiera jeszcze stdlib i jądro ;)

do góry

Pawel "O'Pajak" <o...@g...pl> napisał(a):
> Co to za cudo to AS4?

Atmel Studio 4. Generalnie chodzi o wykorzystanie kompilatora do
wygenerowania pliku .eep. Ale to oczywiście pod warunkiem, że dane będziesz
mieć umieszczone w kodzie. Musiałbyś z CSV czy co tam masz generować plik .c
lub .h z zawartością wspomnianej sekcji .eeprom. Ewentualnie generować
fragment kodu i przeklejać.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

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.


>
> 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?


--
Janusz

do góry

On 11/05/2020 13:45, Pawel "O'Pajak" wrote:
> 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.

Ludzie liczą np. algorytmicznie używajac pythona czy innego języka
PODCZAS budowania, używają make + binutils i wstawiaja to wprost w kod
do linkowania jako .o, tam gdzie potrzebują. O ile oczywiście dane są
algorytmiczne. Ale nawet jak nie są, czasem jest to lepsze niż ręczne
pomyłki.

Ogólnie jeśli masz jakas tablicę parametrów, lepiej aby podczas
budowania była *liczona* niż pobierana z jakiegoś pliku ręcznie
wygenerowanego na zaś. W celu eliminacji białka z procesu budowania oraz
ograniczenia problemów typu "no dobra, a skąd my mamy te dane?".

do góry

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"
};

do góry