18.02.2005 02:05
[#1]
opóźnienie <110us
Jak takie cuś zrobić?
Konkretniej to chodzi o to, że potrzebuję na porcie parallel impuls o czasie trwania mniejszym niż 110 mikrosekund i musi mieć "gwarancję poxipolu", że tak będzie. Czy wywołanie opóźnienia za pomocą timer.device pomiędzy Forbid() i Permit() nie przeciągnie mi tego ponad ustalony czas? Dodam że powinno działać z prockiem 68000, opóźnienie musi mieć długość powyżej 1 mikrosekundy
Konkretniej to chodzi o to, że potrzebuję na porcie parallel impuls o czasie trwania mniejszym niż 110 mikrosekund i musi mieć "gwarancję poxipolu", że tak będzie. Czy wywołanie opóźnienia za pomocą timer.device pomiędzy Forbid() i Permit() nie przeciągnie mi tego ponad ustalony czas? Dodam że powinno działać z prockiem 68000, opóźnienie musi mieć długość powyżej 1 mikrosekundy
18.02.2005 22:56
[#3]
Re: opóźnienie
@MinisterQ, post #2
No tak, zapomniałem o przerwaniach. Zobaczymy jak to będzie, może jeszcze dzisiaj programator przetestuję. Tylko martwi mnie właśnie ten overhead (programowania się po angielsku uczyłem :P ), który wprowadzi samo odwołanie do timer.device.
Mogę to w zasadzie zrobić też na timerach CIA, ale jakoś mi się nie widzi, bo to ciut bardziej skomplikowane.
Jeszcze pozostaje kwestia, czy timer.device nie będzie przeszkadzało wyłączenie przerwań, bo UNIT_MICROHZ wykorzystuje timer CIA, a ten z kolei wywołuje pewnie jakieś przerwanie.
Mogę to w zasadzie zrobić też na timerach CIA, ale jakoś mi się nie widzi, bo to ciut bardziej skomplikowane.
Jeszcze pozostaje kwestia, czy timer.device nie będzie przeszkadzało wyłączenie przerwań, bo UNIT_MICROHZ wykorzystuje timer CIA, a ten z kolei wywołuje pewnie jakieś przerwanie.
19.02.2005 20:23
[#6]
Re: opóźnienie
@shg, post #5
Wyobraż sobie że od kilku dni siedzć nad tym samym tzn.
mam programator SPI i równoległy z kursu bascoma
próbuje podłączyć je do amigi. GUI napisałem teraz siedzć nad procedurami zapisu i odczytu i tu mam problem (wrćcz magiczny) z resetem (programator SPI). Pod PC chodzi bez zarzutu ale pod amigą puszczam reset sprawdzam oscyloskopem na mikrosterowniku jest 0
ale sić nie resetuje. Sprawdzam teraz programator.
mam programator SPI i równoległy z kursu bascoma
próbuje podłączyć je do amigi. GUI napisałem teraz siedzć nad procedurami zapisu i odczytu i tu mam problem (wrćcz magiczny) z resetem (programator SPI). Pod PC chodzi bez zarzutu ale pod amigą puszczam reset sprawdzam oscyloskopem na mikrosterowniku jest 0
ale sić nie resetuje. Sprawdzam teraz programator.
20.02.2005 14:38
[#8]
Re: opóźnienie
@shg, post #1
Programator zrobiony 
Na razie mam opóźnienie na NOP-ach w pętli między Disable() i Enable(), ale to tylko tymczasowo. Chyba jednak CIA użyję.
Też mam akcje różne dziwne z zakłóceniami, zwykłe radio mi nic poza lokalną stacją nie odbiera dobrze, jak jest ami włączona, a co najciekawsze - poziom zakłóceń jest zależny od obciążenia procesora i tego, co się na monitorze wyświetla :D . Już kiedyś to obadałem i wychodzi na to, że przy pewnym ułożeniu kabli zakłócenia da się zlikwidować
Na razie mam opóźnienie na NOP-ach w pętli między Disable() i Enable(), ale to tylko tymczasowo. Chyba jednak CIA użyję.
Też mam akcje różne dziwne z zakłóceniami, zwykłe radio mi nic poza lokalną stacją nie odbiera dobrze, jak jest ami włączona, a co najciekawsze - poziom zakłóceń jest zależny od obciążenia procesora i tego, co się na monitorze wyświetla :D . Już kiedyś to obadałem i wychodzi na to, że przy pewnym ułożeniu kabli zakłócenia da się zlikwidować
20.02.2005 17:03
[#9]
Re: opóźnienie
@shg, post #8
Kiedyś w CB dobrze słyszałem jak amiga (CPU) walczy z problemami.
Dołożyłem przedłużacz odsunołem płytkć testową i gra.
Nie mam problemu z opóżnieniem ponieważ AVR są dosyć szybkie a
port w amidze taki jak wiadomo wićc wszystko leci pełną parą.
Mam inny problem odpowiedz z programatora przychodzi na pin ACK
w jedynym znanym mi rejestrze ($bfed01) mogć tylko dowiedzieć sić tylko o tym że zaszła zmiana jego stanu ale jaki on jest tego już nie. Mogć przyjąć że jego wartość wynosi 1 i po przerwaniu wiem że teraz jest 0. No ale muszć do tego mieszać przerwania. (zobaczć czy w parallel.device czegoś tam niema) (problem na póżniej).
Chwilowo połączyłem sobie ten pin z pinem D0 nie używanym przez programator tak aby sprawdzić czy to działa. Działa bez zarzutu.
Przeglądam materiały AVR (różnice mićdzy nimi) aby rozpoznawał je programator zobaczć jak radzi sobie z tym bascom.
Zamknć to w device i zajmć sić nastćpnym (równoległym).
Tak wogóle to muszć rozpracować kilka programatorów aby wymyślić jakieś sensowne rozwiązanie dla device.
Dołożyłem przedłużacz odsunołem płytkć testową i gra.
Nie mam problemu z opóżnieniem ponieważ AVR są dosyć szybkie a
port w amidze taki jak wiadomo wićc wszystko leci pełną parą.
Mam inny problem odpowiedz z programatora przychodzi na pin ACK
w jedynym znanym mi rejestrze ($bfed01) mogć tylko dowiedzieć sić tylko o tym że zaszła zmiana jego stanu ale jaki on jest tego już nie. Mogć przyjąć że jego wartość wynosi 1 i po przerwaniu wiem że teraz jest 0. No ale muszć do tego mieszać przerwania. (zobaczć czy w parallel.device czegoś tam niema) (problem na póżniej).
Chwilowo połączyłem sobie ten pin z pinem D0 nie używanym przez programator tak aby sprawdzić czy to działa. Działa bez zarzutu.
Przeglądam materiały AVR (różnice mićdzy nimi) aby rozpoznawał je programator zobaczć jak radzi sobie z tym bascom.
Zamknć to w device i zajmć sić nastćpnym (równoległym).
Tak wogóle to muszć rozpracować kilka programatorów aby wymyślić jakieś sensowne rozwiązanie dla device.
20.02.2005 19:25
[#10]
Re: opóźnienie
@HSCX, post #9
Ja tam nie zabardzo kojarzę, czy /ACK da się w ogóle odczytać, ale na pewno w momencie gdy stan na /ACK zmienia się z wysokiego na niski jest generowane przerwanie (o ile jest włączone :) )
To opóźnienie jest w 'x051 potrzebne podczas programowania - impuls na wejściu /PROG musi mieć długość pomiędzy 1 a 110 mikrosekund, jak będzie dłuższy to można Flasha sfajczyć
, ale mój pierwszy programator miał opóźnienie 20ms na Delay(1) i działało :D
A teraz to miałem rebus niesamowity, bo mam z lekka port nadpalony - nie działa linia D0, na /STROBE pojawiają się impulsy nawet jak zapisuję coś na linie POUT, /BUSY, czy SEL :D
Musiałem zrobić odczyt szeregowo, a jedyne co się do tego nadawało to 74151 i w dodatku tylko w standardowej wersji TTL, to jeszcze musiałem do wyjść 4094 podpiąć bufor na 74373 (albo '245, ale '373 się szybciej znalazł :) )
Też mam zamiar się AVR-ami zająć, ale to później i od razu z grubej rury - ATmega :)
Moje cudo(?):
http://shogoonn.w.interia.pl/programator.jpg
hardcore rządzi
Nie wiem nawet, czy opłaca się do tego płytkę robić :D chyba sobie zrobie na procku programator taki bardziej uniwersalny i na łączu szeregowym.
W parallel.device masz taki "mechanizm", że sterownik będzie automatycznie odczytywał dane z D0-D7 na opadającym zboczu na /ACK i potem wygeneruje ujemny impuls na /STROBE
Albo odwrotnie - zapisuje dane z bufora na port, CIA generuje ujemny impuls na /STROBE i czeka na opadające zbocze na /ACK.
Jest jeszcze jakaś wersja komunikacji bez handshaking'u, przy otwieraniu parallel.device trzeba jakąś flagę z FAST w nazwie podać. Działa chyba jakoś tak, że komputer wysyła dane dopóki na linii BUSY jest stan niski, albo wysoki (nie pamiętam) i w momencie zmiany stanu przestaje, ale odbiorca musi być w stanie zmienić stan linii w ciągu 3mikrosekund o odebrania ostatniej danej, nie wiem, czy to działaaa teżdrugą stronę.
Ale do komunikacji z prgramtorem parallel.device jest raczej mało przydatny, łatwiej chyba hardware'owo.
Się tak zastanawiam, bo na ami brakuje jakiegoś fajnego języka wysokiego poziomu dla mikrokontrolerów, aż czasem mam ochotę to zmienić.
Myślałem nad jakimś BASICiem, ale bardziej zbliżonym do C :D tak, żeby się wszystko dało zrobić bez paprania jak w BASCOMie
To opóźnienie jest w 'x051 potrzebne podczas programowania - impuls na wejściu /PROG musi mieć długość pomiędzy 1 a 110 mikrosekund, jak będzie dłuższy to można Flasha sfajczyć
, ale mój pierwszy programator miał opóźnienie 20ms na Delay(1) i działało :DA teraz to miałem rebus niesamowity, bo mam z lekka port nadpalony - nie działa linia D0, na /STROBE pojawiają się impulsy nawet jak zapisuję coś na linie POUT, /BUSY, czy SEL :D
Musiałem zrobić odczyt szeregowo, a jedyne co się do tego nadawało to 74151 i w dodatku tylko w standardowej wersji TTL, to jeszcze musiałem do wyjść 4094 podpiąć bufor na 74373 (albo '245, ale '373 się szybciej znalazł :) )
Też mam zamiar się AVR-ami zająć, ale to później i od razu z grubej rury - ATmega :)
Moje cudo(?):
http://shogoonn.w.interia.pl/programator.jpg
hardcore rządzi
Nie wiem nawet, czy opłaca się do tego płytkę robić :D chyba sobie zrobie na procku programator taki bardziej uniwersalny i na łączu szeregowym.
W parallel.device masz taki "mechanizm", że sterownik będzie automatycznie odczytywał dane z D0-D7 na opadającym zboczu na /ACK i potem wygeneruje ujemny impuls na /STROBE
Albo odwrotnie - zapisuje dane z bufora na port, CIA generuje ujemny impuls na /STROBE i czeka na opadające zbocze na /ACK.
Jest jeszcze jakaś wersja komunikacji bez handshaking'u, przy otwieraniu parallel.device trzeba jakąś flagę z FAST w nazwie podać. Działa chyba jakoś tak, że komputer wysyła dane dopóki na linii BUSY jest stan niski, albo wysoki (nie pamiętam) i w momencie zmiany stanu przestaje, ale odbiorca musi być w stanie zmienić stan linii w ciągu 3mikrosekund o odebrania ostatniej danej, nie wiem, czy to działaaa teżdrugą stronę.
Ale do komunikacji z prgramtorem parallel.device jest raczej mało przydatny, łatwiej chyba hardware'owo.
Się tak zastanawiam, bo na ami brakuje jakiegoś fajnego języka wysokiego poziomu dla mikrokontrolerów, aż czasem mam ochotę to zmienić.
Myślałem nad jakimś BASICiem, ale bardziej zbliżonym do C :D tak, żeby się wszystko dało zrobić bez paprania jak w BASCOMie
20.02.2005 22:16
[#11]
Re: opóźnienie
@shg, post #10
Jeśli chodzi o ACK i ten programator to jest tam podpićte MISO z mikrokontrolera no i jest wykożystywane do szeregowej transmisji.
Flesza nie da rady spalić ale dzićki za ostrzeżenie. Normalnie bym z tym nie walczył tylko ideą było napisanie oprogramowania do obsługi tego typu programatorów dla PC (jest ich multum i chyba wszystkie wykożystują ACK)a parallel.device zamieżam wykorzystać do pełnej zgodności z systemem.
Jeśli chodzi o jakiś kompilator wysokiego poziomu też sić na tym zastanawiałem z tym że jestem bardziej skłony do E właściwie mnie bardziej odpowiadało by rozwiązanie w stylu PoweD. Do tej pory nie wyszedłem jeszcze z rozważań teoretycznych jakie należało by przyjąć standardy. obsługi tak bardzo różniących sić mikrokontrolerów wystarczy przyjrzeć sić kompilatorom C dla PC też borykają sić z tym problemem.
Flesza nie da rady spalić ale dzićki za ostrzeżenie. Normalnie bym z tym nie walczył tylko ideą było napisanie oprogramowania do obsługi tego typu programatorów dla PC (jest ich multum i chyba wszystkie wykożystują ACK)a parallel.device zamieżam wykorzystać do pełnej zgodności z systemem.
Jeśli chodzi o jakiś kompilator wysokiego poziomu też sić na tym zastanawiałem z tym że jestem bardziej skłony do E właściwie mnie bardziej odpowiadało by rozwiązanie w stylu PoweD. Do tej pory nie wyszedłem jeszcze z rozważań teoretycznych jakie należało by przyjąć standardy. obsługi tak bardzo różniących sić mikrokontrolerów wystarczy przyjrzeć sić kompilatorom C dla PC też borykają sić z tym problemem.
