Program do konwersji danych na pliki *.eep dla EEPROM w ATMedze - co polecacie?

Mon May 11, 2020 12:20 am   

Powitanko,

Widawało mi się, że Google powita mnie z kwiatami, gdy zadam mu pytanie
o jakiś program, który przekonwertuje zbiór danych na format eep do
nakarmienia nimi EEPROMa w ATMedze. Zbiór danych w dowolnym formacie
mogę zrobić, nawet txt, albo csv. Jest coś gotowego, czy trzeba się
doktoryzować z budowy plików eep?

Pozdroofka,
Pawel Chorzempa
--
"-Tato, po czym poznać małą szkodliwość społeczną?
-Po wielkiej szkodzie prywatnej" (kopyrajt: S. Mrożek)
******* >>> !!! UWAGA: ODPOWIADAM TYLKO NA MAILE:
moje imie.(kropka)nazwisko, ten_smieszny_znaczek, gmail.com

Mon May 11, 2020 6:00 am   

W dniu 11.05.2020 o 02:20, Pawel "O'Pajak" pisze:

będziesz miał HEX i zmienisz nazwę, to powinno być OK.

Pozdrawiam
EdiM

Mon May 11, 2020 10:02 am   

W dniu 2020-05-11 o 08:00, EM pisze:

Wiem, ale do hexa też gotowca nie znalazłem Wierzyć mi się nie chce, że
nikt nie miał do zapisania w EEPROMie szeregu danych.

Pozdroofka,
Pawel Chorzempa
--
"-Tato, po czym poznać małą szkodliwość społeczną?
-Po wielkiej szkodzie prywatnej" (kopyrajt: S. Mrożek)
******* >>> !!! UWAGA: ODPOWIADAM TYLKO NA MAILE:
moje imie.(kropka)nazwisko, ten_smieszny_znaczek, gmail.com

Mon May 11, 2020 10:29 am   

Pawel "O'Pajak" <opajak1@gazeta.pl> napisał(a):

Wierzyć mi się nie chce, że Google nie przywitał Cię z kwiatami. Narzędzi do
obsługi plików Intel HEX jest mnóstwo. W jakim formacie masz dane wejściowe?

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

Mon May 11, 2020 11:45 am   

W dniu 2020-05-11 o 12:29, Grzegorz Niemirowski pisze:

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.

Pozdroofka,
Pawel Chorzempa
--
"-Tato, po czym poznać małą szkodliwość społeczną?
-Po wielkiej szkodzie prywatnej" (kopyrajt: S. Mrożek)
******* >>> !!! UWAGA: ODPOWIADAM TYLKO NA MAILE:
moje imie.(kropka)nazwisko, ten_smieszny_znaczek, gmail.com

Mon May 11, 2020 11:55 am   

Pawel "O'Pajak" <opajak1@gazeta.pl> napisał(a):

Bo po prostu mało komu z użytkowników tego Notepada++ jest to potrzebne.


Ależ robią to. Zapiszą sobie w którymś hex-edytorze do pliku binarnego a
potem przekonwertują na intel hex, choćby sposobem podanym obok przez
Dawida.

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

Mon May 11, 2020 1:04 pm   

W dniu poniedziałek, 11 maja 2020 02:20:30 UTC+2 użytkownik Pawel "O'Pajak" napisał:

Nono, jak chcesz w csv to rzeczywiście trzeba się doktoryzować w zakresie sztucznej inteligencji, która zgadnie, gdzie w EEPROM chcesz którą z danych umieścić. Takiej SI nie ma jeszcze nawet google na swoim komputerze kwantowym.

Jak już dojdziesz do tego, że trzeba zrobić plik binarny, odpowiadający swoją zawartością upragnionej zawartości pamięci EEPROM, to wystarczy:
avr-objcopy -Ibin plik.binary -Oihex plik.eep
a jeśli chcesz te dane umieścić nie od 0, tylko od innego adresu w EEPROM:
avr-objcopy -Ibin plik.binary -Oihex plik.eep --change-addresses=adres

Zaś budowy pliku hex naprawdę warto się nauczyć, nie jest trudna, wikipedia ma o tym dobrą stronę.

Mon May 11, 2020 2:13 pm   

W dniu 2020-05-11 o 13:45, Pawel "O'Pajak" pisze:

Jak w 1988 zrobiliśmy programator Piccolo to program do niego między
innymi nadawał się do konwersji HEX<->BIN.
Pamiętam, że walczyłem z czymś takim, żeby potrafić wczytać ileś plików
i na mapie Epromu pokazać (cyferkami) który plik zajmuje który obszar.
To chyba było właśnie rozwiązanie do łączenia programu (jeden plik) z
danymi (drugi plik), ale jak już robiłem to chyba zrobiłem do 16 plików
(czyli oznaczenia od 0 do F), a może 10. Już nie pamiętam.
O ile pamiętam to ostrzegałem o tym, że któryś plik nadpisuje jakiś
poprzedni. Ale po tylu latach to już się szczegółów nie pamięta.
Na pewno gdzieś mam ten program, ale czy pod Windows 64 bity to jeszcze
zadziała?
P.G.

Mon May 11, 2020 3:23 pm   

W dniu 2020-05-11 o 13:45, Pawel "O'Pajak" pisze:

Oczywiscie że robią, daja sekcję eeprom i tam dane, i tyle
W AS4
Sekcja __attribute_((section(".eeprom")))
lub
zmienna typu EEMEM.

--
Janusz

Mon May 11, 2020 5:53 pm   

W dniu 2020-05-11 o 17:23, Janusz pisze:

Co to za cudo to AS4?


Pozdroofka,
Pawel Chorzempa
--
"-Tato, po czym poznać małą szkodliwość społeczną?
-Po wielkiej szkodzie prywatnej" (kopyrajt: S. Mrożek)
******* >>> !!! UWAGA: ODPOWIADAM TYLKO NA MAILE:
moje imie.(kropka)nazwisko, ten_smieszny_znaczek, gmail.com

Mon May 11, 2020 6:05 pm   

Pawel "O'Pajak" <opajak1@gazeta.pl> napisał(a):

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/

Mon May 11, 2020 7:30 pm   

W dniu 2020-05-11 o 20:03, Dawid Rutkowski pisze:






--
Janusz

Mon May 11, 2020 8:03 pm   

On 11/05/2020 13:45, Pawel "O'Pajak" wrote:

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

Mon May 11, 2020 8:03 pm   

W dniu poniedziałek, 11 maja 2020 17:23:54 UTC+2 użytkownik Janusz napisał:

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

Tue May 12, 2020 11:31 am   

W dniu poniedziałek, 11 maja 2020 21:30:25 UTC+2 użytkownik Janusz napisał:

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.


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