wygenerować *.eep

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

Z tego co widzę w Ponyprog, to *.eep to jest zwykły HEX, więc pewnie jak będziesz miał HEX i zmienisz nazwę, to powinno być OK.

Pozdrawiam EdiM

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

Pawel "O'Pajak" snipped-for-privacy@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?

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ę.

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

Pawel "O'Pajak" snipped-for-privacy@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.

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.

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.

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

Co to za cudo to AS4?

Pozdroofka, Pawel Chorzempa

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

Pawel "O'Pajak" snipped-for-privacy@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ć.

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

No do karmienia programatora wystarczy.

I wyślesz to do programatora?

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

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