Emulator eprom na mikrokontrolerze

A po co w emulatorze uP? Jedyna mozliwosc, jaka przychodzi mi do glowy to do ladowania danych przez port szeregowy.

W emulatorze ktory posiadam jest chyba 4x74HCT245 + pamiec RAM + jakies inwertery na tranzystorach. Dane laduje sie przez potr LPT. Jesli chcesz koniecznie uzyc uP, to laduj dane do RAMu przez RSa (moim zdaniem wygodniejszy niz LPT) a po zaladowaniu danych przelacz magistrale ukladami 74245 (244) i powinno zadzialac. Pozdrawiam Tomek

Uzytkownik "Tomasz Sliwa" snipped-for-privacy@XXXwp.pl napisal w wiadomosci news:d42scl$67o$ snipped-for-privacy@nemesis.news.tpi.pl...

Czyli po prostu procesora uzywac tylko do zapisania danych do pamieci ?

Nie bardzo mi sie to podoba.

Docelowo chcialbym zamiast ramu sprobowac uzywac multimedia card sterowanych tym wlasnie procesorem.

U¿ytkownik "Mi³osz K³osowicz" snipped-for-privacy@miklobit.WYTNIJTO.com> napisa³ w wiadomo¶ci news:d4304l$4ml$ snipped-for-privacy@nemesis.news.tpi.pl...

Ok ok. To w zasadzie bez roznicy. W kazdym razie w dostepie do danych na pewno bedzie posredniczyl procesor a skad on je bedzie bral to juz bez znaczenie.

Andrzej napisał(a):

Jeśli chcesz serwowac dane do emulacji z MMC to chyba nie tędy droga. Wprawdzie MMC są dosyć szybkie, ale zostały wymyslone do czytania danych całymi sektorami. W przypadku dostępu swobodnego do pojedynczego bajtu , czas potrzebny na wysłanie za każdym razem wszystkich komend do MMC będzie o wiele za długi. To juz lepiej by się sprawdziła szybka karta CF podłaczona w trybie MemoryMode.

Użytkownik Andrzej napisał:

Emulator musi być przede wszystkim tak szybki jak układ scalony i musi być przeładowywalny w jednej chwili, inaczej nie ma sensu. Dlatego robienie tego przez uC albo jakieś karty pamięci też jest bez sensu

Ale wiekszosc procesorow i tak jest za wolna zeby zdazyc to obsluzyc.

Moze jakies pentium xGHz by sie wyrobilo zeby w ciagu 250ns [bardzo wooolny eprom] podac dane.

Normalnie to jednak uzywasz kostki pamieci RAM, ktora odpowiednimi buforami podlaczasz do magistrali badanego urzadzenia.

J.

U¿ytkownik "A.Grodecki" <ag.usun snipped-for-privacy@modeltronik.com napisa³ w wiadomo¶ci news:d43338$pdu$ snipped-for-privacy@nemesis.news.tpi.pl...

Tak mi sie tez wydawalo, ze to nie przejdzie.

W takim razie musze zrobic cos takiego, ze eprom zastapie jakas pamiecia flash a do tego jakis modul latwego programowania z poziomu pc.

U¿ytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news: snipped-for-privacy@4ax.com...

No chyba jakos tak bede musial zrobic.

Kolega na si³ê chce zrobiæ co¶ co ju¿ dawno jest opanowane w wielu wariantach. Flash tu specjalnie niepotrzebny, a i swoj± ¿ywotno¶æ na razie jeszcze skoñczon± ma. Jak ju¿ to proponujê zrobiæ co¶, czego jeszcze nie widzia³em. Transfer od PC do emulatora zrealizowany: a) poprzez kompresjê na PC b) transmisjê poprzez RS b) dekompresjê w procesorze i zapis do RAM, który poprzez bufory udajê EPROM

Kompresja opiera³aby siê na: a) porównaniu z danymi wys³anymi ostatnim razem i wybrania do transmisji tylko tych które siê zmieni³y. Dodatkowo nale¿a³oby okre¶liæ konieczne przesuniêcia kodu. b) zmniejszeniu transmitowanych danych metodami algorytmicznymi, podobnie jak arj, zip itp.

Inaczej mówi±c: przesy³aæ tylko modyfikowany fragment pamiêci, a mikrokontroler pe³ni³ by rolê linkera ostatnio przes³anych "bibliotek" z nowym fragmentem.

Wtedy uda³oby siê np. przes³aæ 64kB danych, wysy³aj±c faktycznie tylko np. 1kB przez powiedzmy 300 ms do 2s :-)

Mam nadziejê, ¿e pomys³ nie jest zbyt nierealny.

Zamiast takich machinacji to już lepiej zrobić emulator EPROMów podłączany do komputera przez USB. Dla USB 1.1 transfery dochodzą do

Poza tym kto jeszcze używa EPROMów?

No Andrzej :-) Wiedzia³em, ¿e kto¶ "wyleci" z tym USB. Niestety dla pocz±tkuj±cego to zbyt du¿y problem. RS232 ma ka¿dy uC. Jest te¿ du¿a baza przyk³adów.

Microchip zrobi³ Programator/DebuggerICD2. Ch³opaki poszli nawet dalej. Na p³ytce jest USB i RS232. Mo¿na sobie wybraæ rodzaj transmisji. Ale na RS232 to ju¿ tylko w zasadzie programowanie jest mo¿liwe. Uruchamianie uk³adu w trybie DBUGGERa jest utrapieniem. Komunikacja jest tak wolna, ¿e mo¿na kawê popijaæ.

Poza tym wyzwanie jest naprawdê ciekawe. W miarê proste rozwi±zanie. P³ytka te¿ nie bêdzie skomplikowana.

U¿ytkownik "Sylwester £azar" snipped-for-privacy@alpro.pl napisa³ w wiadomo¶ci news:d43o40$7kb$ snipped-for-privacy@nemesis.news.tpi.pl...

W 1988r namiastkê tego rozwi±zania zastosowali¶my w programatorze/emulatorze Piccolo/Picco-512. Gdy program na PC napotyka³ sekwencjê jednakowych bajtów (typowa rzecz przy wype³nianiu EPROMu), przesy³a³ tylko informacjê od jakiego adresu, ile i jakich bajtów (podobnie przy odczycie). To proste rozwi±zanie (nie wiedzia³em nic o zip czy arj) znacznie redukowa³o czasy. Prêdko¶æ transmisji mieli¶my tylko 57600 (8748 nie mia³ UARTa i tylko tyle uda³o siê zrobiæ programowo). P.G.

U¿ytkownik "Sylwester £azar" snipped-for-privacy@alpro.pl napisa³ w wiadomo¶ci news:d43o40$7kb$ snipped-for-privacy@nemesis.news.tpi.pl...

Potrzebny wlasnie. To ma dzialac w konkretnym urzadzeniu i nie bedzie raczej programowane miliard razy a nie moze danych zapomniec.

RAM + bateria raczej odpada.

Hm .. w owym czasie zaprogramowanie jednego bajtu chyba wymagalo co najmniej kilka ms - zysk mogl byc tylko na FF.

A 64KB .. to jakies 15s powinno trwac, wiec gdzie tu duza oszczednosc ? :-)

J.

U¿ytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news: snipped-for-privacy@4ax.com...

Standard - 50ms, Intelligent - kilka ms, Quick-pulse - poni¿ej ms FF-y czêsto stanowi³y znaczn± czê¶æ zawarto¶ci EPROMu.

oszczednosc

Przyjmuj±c 15s, za³ó¿my, ¿e dane to 10%, a reszta FF (ale na koñcu 2 bajty - jaki¶ wektor przerwania). Programowanie 1,5s (FF-ów nie programuje tylko sprawdza) + transmisja

Ale przy odczycie to ju¿ nie ma dyskusji - trzeba odczytaæ ca³o¶æ. Tu efekt pakowania takich samych bajtów (FF w EPROMach, 00 w niektórych procesorach) daje jeszcze wiêkszy zysk. Zak³adaj±c ¿e odczyt trwa 0, przy poprzednich danych bêdzie skrócenie czasu odczytu z 15s do 1,5s

Jak procesor obs³ugiwa³ transmisjê (bit przy 57600 ma 17us - zaledwie kilka rozkazów) to ju¿ nie móg³ robiæ nic innego - czas transmisji siê dodawa³ do czasu programowania. P.G.

Quick pulse juz wtedy bylo ?

Przy programowaniu ? Zadna. Kostke trzeba jeszcze wyciagnac, w uklad wsadzic. No i moze jeszcze zastanowmy sie na sensownoscia zalozenia ze tylko 10% stanowia dane uzyteczne .. ktos tu znacznie przesadzil z rozmiarem epromu :-)

Natomiast przy emulacji juz dosc istotne..

Tym bardziej ze w pliku HEX ich w ogole nie bedzie wymienionych ..

I to mnie wlasnie ciekawi - bo dziala tez w druga strone - jak procesor programuje, to nie moze odbierac. Trzeba jakis protokol z potwierdzeniami wymyslec ..

J.

U¿ytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news: snipped-for-privacy@4ax.com...

Mo¿e jeszcze nie by³o, ale przewidywali¶my pojawienie siê coraz szybszych algorytmów. Dlatego algorytm w Piccolo by³ parametryzowany (czas impulsów programuj±cych, ich liczba, ile jeszcze jak ju¿ OK, na której nodze, itd.) Nie ¿±dali¶my (jak inni w tym czasie) dostarczenia nam programatora w celu upgrade'u oprogramowania.

Przy wk³adaniu cz³owiek nie czuje, ¿e czas ucieka, a jak czeka to tak.

Bywa³o (trochê pó¼niej), ¿e 27256 by³ tañszy od 2732, 2764, 27128

No i o to chodzi³o (by³a przystawka - emulator).

zaledwie

PC wiedz±c ile roboty zada³ programatorowi ustawia³ sobie time-out, a programator, po wykonaniu potwierdza³. Time-outy mog³y byæ nawet 30s (wype³nianie du¿ego obszaru nie FF-ami). Ustawiane dynamicznie - aby w innych sytuacjach reakcja na b³êdy (ponowna synchronizacja i wio dalej) by³a szybka. P.G.

Bez urazy, ale Pan Piotr wyra¼nie pisa³, ¿e Micromade to zrobi³. Je¶li zrobi³ - to znaczy, ¿e dzia³a³o i wcze¶niej musieli siê zastanowiæ nad sensowno¶ci±. Trochê wiêcej Wiary. Zw³aszcza w lepszych od nas ludzi.

Swoj± drog± mo¿na by ju¿ tylko polepszyæ t± transmisjê dodaj±c kompresjê. W opcji EMULATORA by³by to doskona³y atut. Sprawdzi³em kompresjê pliku 8kB *.bin dla 8051 z ok. 30% kodu. ZIP zrobi³ z tego 1484 bajty

On Wed, 20 Apr 2005 00:18:38 +0200, Adam Dybkowski snipped-for-privacy@amwaw.edu.pl> wrote: [.....]

Producenci urzadzeń fiskalnych. I nie chodzi tu tylko o moduły fiskalne, ale również o pamięć programu uC sterującego urządzeniem.

Regards, /J.D.