[6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Prawdziwe słowa nie są przyjemne. Przyjemne słowa nie są prawdziwe.
Lao Tse
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
...porządkowania stołu ciąg dalszy, tym razem taśma do wyświetlacza. Zrobiona znaną już metodą, te niby węższe żyłki na szerokości 14 nitek idealnie wpasowały się w klamerkę IDC14, jest całkiem fajnie.
Oczywiście pstrokate zakończenia przewodów, aby się nie pogubić przy zapinaniu do płytki.
Test zadziałania całkiem ok.
O, a przy okazji nie omieszkałam sprawdzić, jakby mógł z Motką moją zadziałać inny, bliźniaczy wyświetlacz VFD typu CU20029, deko większy. I wszystko zasadniczo by pasowało tylko nie pobór prądu.
Z większym koleżką i jego jasnością na połowę gwizdka cała zabawka życzyła sobie ponad 850mA, tak więc póki co bawimy się mniejszym.
Wyświetlaczyk zapięty do instalacji w cywilizowany sposób, teraz można ewentualnie coś robić dalej.
code code code
Na początku w ramach uzupełnienia - w miarę ogarnięte zagadnienie sterowania modułem VFD, nie jest to cudo jakieś wielkie i możliwe, że pokraczne odrobinę - niemniej jednak lampa steruje w miarę wygodnie. Includek dla innych programików:
https://github.com/bienata/monoboard9/b ... u20025.inc
i programik testowy, korzystający z tego (hahaha) drivera:
https://github.com/bienata/monoboard9/b ... test-1.asm
Dalsze prace to usilne me knowania w temacie systemu przerwań. Mam pomysł na demko, ale do niego trzeba przygotować kilka rzeczy i to etapami. Póki co dwa zagadnienia: konwersja do ascii-hex i funkcja, która cyklicznie wywoływana, będzie na DAC-a wystawiała kolejne próbki sinusa z tabeli i sama dbała o zawinięcie się na początek. Jak zadziała, to ją będzie można wołać z poziomu przerwań traktując jako samowystarczalny samograj. Szkic póki co następujący, fragmenty:
gen-1.asm pisze:Kod: Zaznacz cały
.sm RAM
.or $0000
; vars and temps here
samplePtr: .bs 2
;
; (...)
;
.sm CODE
.or $E000
; sin gen init
ldx #SINE_WAVE_256
stx samplePtr
;
; (...)
;
; gets next sample for D/A
getNextSample:
pshu x,a
lda [samplePtr] ; get sample at samplePtr
sta VIA1+ORA ; set voltage
ldx samplePtr ; get samplePtr itself
inx ; ++
cmpx #SINE_WAVE_256+$FF ; end?
bne getNextSampleExit ; if not skip ptr init
ldx #SINE_WAVE_256 ; reset ptr
getNextSampleExit:
stx samplePtr ; save samplePtr
pulu x,a
rts
;
; (...)
;
Z tego cudaka najfajniejsza jest sztuczka z adresowaniem typu extened indirect. W zmiennej o lokalizacji samplePtr siedzi sobie adres aktualnej próbki, instrukcja lda [samplePtr] wyciąga do aku bajt danych wskazany tymże adresem, kapitalny wynalazek. Programik powoluśku wyciąga kolejne próbki sinusa i pokazuje je na V640, aby było widać, że pętla główna pracuje to jeszcze pisze coś tam po wyświetlaczu. Na zdjęciu to nie robi specjalnie wrażenia...
Lepiej wygląda na filmiku, ponieważ widać jak pełznie powoli wskazówka multimetru, o i tu cały urok V640
https://youtu.be/Li7ctHTH1CQ
Kompletny testowy kodzik tu:
https://github.com/bienata/monoboard9/b ... /gen-1.asm
Dalsze dłubanie to proza życia - będzie mi jeszcze potrzeba procedurki do konwersji z bin na cztery cyfry hex, w ascii, łomatko...
Coś tam nabazgrałam i nawet działa, ale szpetne mi się wydaje, zatem tylko jako ciekawostkę wskazuje pliczek:
https://github.com/bienata/monoboard9/b ... /irq-1.asm
Nazwa szumna irq-1.asm, bo rzeczywiście z niego zamierzam zrobić finalne demko, póki co z przerwaniami ma wspólną tylko nazwę, programik-kadłubek działa tak:
https://youtu.be/S7fbsDWBszM
Tak ogólnie, to zauważam w tej assemblerowej pisaninie swej pewne zmanierowanie Z80-tką, a dokładnie ciągłę mimowolne używanie do transferu danych rejestrów, zamiast pamięci roboczej. Fakt, procesor Z80 ma spory komplet rejestrów i można sobie pozwalać, już nie wspominam o rejestrach shadow, jak kto ciekaw to proszę doczytać o instrukcji EXX. No ale Księżniczka Motorola dla odmiany operacje na pamięci ma super rozbudowane i furę trybów jej adresowania, trzeba się pomału zacząć przestawiać, bo wioska się robi...ot, myśl taka.
Mysz na V640 już śpi a więc chyba wystarczy na dziś...
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Przerwania IRQ w 6809 - opowieści dziwnej treści v.1
Będzie jak w temacie, a mianowicie pooglądamy sobie na oscyloskopie jak funkcjonuje system przerwań Księżniczki Motoroli i dlaczego tak śmiesznie.
Jako lekturę ogólnorozwojową polecam:
6809 Assembly Language Programming (Lance Leventhal) (rozdział 15)
http://www.roust-it.dk/coco/6809irq.pdf
http://www.6502.org/tutorials/interrupts.html
http://www.vectrex.co.uk/files/datasheets/6522AP.pdf
A ja teraz odrobinę poleję wody.
No więc mamy w 6809 przerwania niemaskowalne NMI, mamy maskowalne i szybkie FIRQ i takie zwyczajne IRQ i właśnie nimi się teraz trochę zajmiemy. Od strony sprzętowej wejście procesora /IRQ aktywowane niskim stanem logicznym jest zapięte do wyjść /IRQ różnistych układów peryferyjnych systemu w formie OR-by-wire, w mojej płytce są to dwa układy VIA 6522 oraz port szeregowy ACIA 6551. Dodatkowo sygnał /IRQ wystaje ze złącza systemowego, co jest w sumie miłe, bo łatwo się do niego dobrać i coś napsocić.
Znamy już Timer 1 z układu VIA i wiemy, że może pracować w trybie autonomicznym (free run) generując na wyjściu PB7 sygnał prostokątny o zadanej przez nas częstotliwości. Jest jeszcze dodatkowa sztuczka, a mianowicie każde przeładowanie timera może wygenerować przerwanie IRQ, zatem łatwo możemy uzyskać mechanizm cyklicznego wywoływania kawałka kodu ze ściśle określoną częstotliwością. Ale jak?
Aaaaaaaby ... odpalić przerwanie od Timer 1 w VIA
Sprawa nie jest skomplikowana, ale trzeba deczko się wczytać w pdf do UM6522 oraz dodatkowe opisy z 6502.org dla kompletności. Po skonfigurowaniu wartości dla timera należy jeszcze ustawić stosowne bity w rejestrze IER (Interrupt Enable Register) oraz odblokować przerwania maksowalne IRQ rozkazem CLI. Oczywiście tabela z wektorami przerwań musi zawierać wpis wskazujący na procedurkę obsługującą nasze irq. Sama procedura robi to co chcemy aby robiła, kończyć się musi rozkazem powrotu z przerwania RTI (tak specjalny odpowiednik zwykłego RTS). Ważne jest też, aby jednym z pierwszych rozkazów było skasowanie w urządzeniu flagi zgłaszającej przerwanie, co fizycznie uwolni linię /IRQ do stanu wysokiego. Szczerze powiedziawszy detaliczne przykłady jak przerwania od VIA okiełznać znalazłam dopiero na 6502.org, to kostka w sumie Commodorowa jest, więc najlepiej u źródła, no i mega przystępnie to napisali.
EKG Księżniczki Motoroli
Aby pooglądać sobie jak cała zabaweczka działa w rzeczywistości zrobimy tak, że linia /IRQ procesora będzie zapięta do CH1 Analog Discovery, na niej trigger zaczajony na opadające zbocze będzie nam inicjował podglądanie przebiegu. Drugi kanał CH2 zapniemy do...wyjścia przetwornika cyfrowo-analogowego AD558 znanego ze zdolności swej do generowania sinusów. Tu jednak zrobimy w programie nieco inaczej – ważne etapy wykonania kodu będziemy oznaczać odpowiednimi poziomami napięć wyjściowych, więc takie (jak łatwo zgadnąć) schodki wespół ze szpilkami od IRQ dadzą pojęcie co tam wyczynia koleżanka Motorola i w którym mniej więcej momencie.
Cały programik tu https://github.com/bienata/monoboard9/b ... test-1.asm a w formie komentarza:
w pętli głównej z maniakalnym uporem ustawiane jest na przetworniku napięcie VOUT_MAIN , nawet jeżeli jakiś zewnętrzny czynnik (np. przerwanie) wstawi do D/A coś innego, to pętla główna odzyskawszy sterowanie szybciutko ustawi sobie to co sama chce, w końcu ona niby rządzi.
via-irq-test-1.asm pisze:Kod: Zaznacz cały
lda #VOUT_MAIN
.loop
sta VIA1+ORA
bra .loop
Drugi ważny element to procedura obsługi irq, a wyglądać może tak:
via-irq-test-1.asm pisze:Kod: Zaznacz cały
irqHandler:
lda #VOUT_IRQ_ENTER
sta VIA1+ORA
lda #$C0
sta VIA1+IFR ; clear Irq flag (!!!!)
lda #VOUT_IRQ_BODY
sta VIA1+ORA
lda #10
.loop
deca
bne .loop
lda #VOUT_IRQ_EXIT
sta VIA1+ORA
rti
W procedurze obsługi przerwania irq meldujemy fakt przejęcia sterowania ustawieniem napięcia o wartości VOUT_IRQ_ENTER. Następnie kasujemy w VIA flagę zgłoszenia przerwania i ustawiamy napięcie VOUT_IRQ_BODY. One jest na tym poziomie przez klika NOP-ów w pętli, że niby to nasz `kod biznesowy`, na koniec ustawiamy napięcie VOUT_IRQ_EXIT i oddajemy sterowanie.
Na oscylogramie dostaniemy coś takiego i zaraz będziemy mieli szanse dorobić teorię do rzeczywistości.
Ekg - czyli kolejne wywołania obsługi IRQ wraz z pobudzeniem
Tak przypisujemy poziomy napięć do faz wykonania.
Tak na osi czasu wykonują się kolejne rozkazy handlera.
Już wyjaśniam co się dzieje. Motorolka czujna jak żuraw sprawdza stan linii /IRQ po zakończeniu egzekucji każdej instrukcji (o ile jest na to pozwoleństwo rozkazem CLI) i gdy wykryje konieczność obsługi przerwania IRQ wybiera wektor jego obsługi z tabeli, następnie przekazuje sterowanie tak wskazanej procedurze. No ale co z ochrona rejestrów wykorzystywanych w przerwanym programie głównym czy jak to się mawia fachowo – bieżącym stanem procesora? Ano widać na malunku, że pomiędzy opadającym zboczem sygnału /IRQ a pojawieniem się poziomu VOUT_IRQ_ENTER mija (spory) kawałek czasu. No więc właśnie wtedy, Księżniczka Motorola upycha na stos wszelkie swoje szpargały (stacking) – począwszy od rejestru PC a skończywszy na rejestrze stanu CCR. Na stos odkładane jest w sumie kilkanaście bajtów danych, to nieco trwa, czyli pakuje torebkę jak prawdziwa krzemowa kobietka. Dopiero potem sterowanie przekazywane jest do kodu procedury obsługi. Kolejne co musi się wydarzyć, to poinformowanie układu zlecającego przerwanie (tu: VIA), że zostało ono zauważone i obsługa właśnie się dzieje, więc flagę zgłoszenia trzeba skasować. Wykonujemy tę czynność stosowną operacją na urządzeniu (np. poprzez zapis do portu lub odczyt 'magicznego rejestru'), gdy gotowe ustawiamy napięcie VOUT_IRQ_BODY, co mówi światu, że wykonuje się aktualnie główny kod procedury obsługi. Na koniec (u nas: po pętelce NOP-ów), zaraz przed zwróceniem sterowania rozkazem RTI ustawiamy napięcie VOUT_IRQ_EXIT. Jak widać od chwili gdy ono się pojawi, do momentu powrotu sterowania do programu głównego (ponownie napięcie VOUT_MAIN) też mija dłuższa chwila. No właśnie wtedy Motka wypakowuje klamoty ze stosu (unstacking), a że ma ich dużo to i taktów sporo zajmują. I poganianie nic tu nie da, ona już tak ma .
Zapamiętujemy – prolog i epilog funkcji obsługi przerwania IRQ jest ukryty przez programistą, afektuje stos sprzętowy (SP) i trwa kilkanaście cykli maszynowych. Zaletą jest to, że w procedurze obsługi przerwania IRQ nie musimy już przejmować się ochroną rejestrów, co jest w sumie wygodne. Wadą jest spory narzut czasowy na tę niejawną ochronę i brak na nią jakiegokolwiek wpływu. Coś za coś.
W firmie dygresji – dla odmiany przerwanie FIRQ (Fast IRQ) zachowuje na stosie tylko adres powrotu z PC i rejestr warunku (CCR), o resztę dbamy samodzielnie. Jest to oczywiście szybsze w wykonaniu, ale wymaga więcej uwagi przy pisaniu kodu.
Co za dużo to ... przerwania w roli szkodników
A teraz troszkę poprzestawiamy koleżance Motorolce szyki i na początek zapomnimy o zameldowaniu do VIA faktu obsłużenia przerwania. Usuwamy odwołanie do rejestru VIA1+IFR i puszczamy programik. Raz wyzwolony układ VIA pozostawi linię /IRQ w stanie niskim, no skoro nie każą go zwolnić, to co się będzie wysilał.
via-irq-test-1.asm pisze:Kod: Zaznacz cały
irqHandler:
lda #VOUT_IRQ_ENTER
sta VIA1+ORA
lda #$C0
;;;;;; sta VIA1+IFR ; clear Irq flag (!!!!)
lda #VOUT_IRQ_BODY
sta VIA1+ORA
lda #10
.loop
deca
bne .loop
lda #VOUT_IRQ_EXIT
sta VIA1+ORA
rti
No i słabo jest.
Widać z oscylogramu, że obsługa przerwania (tego i kolejnych) praktycznie w 100% zaabsorbowała Motkę, program główny w ogóle nie będzie wykonywany,
Pamiętamy – ona jest czuła na STAN linii /IRQ a nie na ZBOCZE, zatem konsekwencją niezwolnienia linii do logicznej jedynki jest permanentne wywoływanie handlera irq po zakończeniu egzekucji poprzedniego. Program główny nie dojdzie do głosu w ogóle. I to chyba kliniczny przykład `zagłodzenia` programu głównego przez przerwania.
Podobny efekt, choć mniej drastyczny, uzyskamy gdy pomimo kasowania zgłoszenia przerwania, nowe IRQ będą pojawiały się zbyt często jak na możliwości (moc obliczeniową) naszej Motki, przykład: zmiana IRQFREQ na 7kHz, przy zegarze systemowym w mojej płyteczce cudnej na poziomie 1MHz. Czas spędzony w programie głównym jest sporo mniejszy od czasu z przerwań.
Jak widać, Motorolka głównie zajmuje się obsługiwaniem przerwań, taki nowy sens życia jej wskazano, choć chyba nie do końca o to jej chodziło.
Tu powstaje ciekawe zagadnienie – czy jest jakakolwiek możliwość zapobieżenia takiej sytuacji, czy da się ochronić system przez zbyt często pojawiającymi się przerwaniami, mogącymi zupełnie wygasić pracę pętli głównej i w efekcie sparaliżować całą aplikację?
Ja myślę, że pewnym rozwiązaniem byłoby wykorzystanie mechanizmu watchdog (oczywiście zewnętrzna kostka, bo Motka tego nie ma w sobie), ale nie po to aby dać jej klapsa i kompletnie zresetować, ale po to aby np. odciąć na chwilę źródło przerwań od linii /IRQ. Zagłodzony program główny nie pobudzi watchdoga przez pewien czas, seria szkodliwych irq zaniknie dopuszczając pętlę główną do głosu, to taka myśl do sprawdzenia, w wolnej chwili...
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
tasza pisze:aaaale scerbate toto wysło...
Urocze
Prawdziwe słowa nie są przyjemne. Przyjemne słowa nie są prawdziwe.
Lao Tse
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Pamięci dużo, mnóstwo
Już chyba wszystkich znajomych (z tych co mnie jeszcze nie zaczeli unikać) obsępiłam z kostek typu 6264 i doszły dodatkowe trzy: Hitachi, NEC i Hyundai.
I nie to żebym jakaś chytra była na te pamięci, no ale proszę - oto caluteńkie 56kB ciągłego obszaru, super jest!
A więc z czystym sumieniem kolejny commit monoboard09.inc, tym razem z 7*8, to już maks dla tej płytki.
https://github.com/bienata/monoboard9/b ... board9.inc
... Black Is the Color ...
Plan na dziś był inny, ale zahaczyłam okiem o kolorowanie napisów na terminalu VT100 no i zabawa teraz jest na cztery fajerki, stronki takie oto:
http://wiki.bash-hackers.org/scripting/terminalcodes
https://misc.flogisoft.com/bash/tip_col ... formatting
I w sumie to wszystko co potrzeba do szczęścia. Zarówno programik screen jak i putty spokojnie te sekwencje sterujące akceptują zatem można tak:
Kod: Zaznacz cały
screen /dev/ttyUSB0
Kod: Zaznacz cały
putty -serial /dev/ttyUSB0 -sercfg 9600,8,n,1,N > /dev/null 2>&1 &
stdout i stderr na null, bo mi jakimiś ostrzeżeniami GTK sypał po ekranie, no a po takim przekierowaniu od razu działa lepiej...
Dzierganina w SB-ASM nie jest tu zbyt sympatyczna, bo trzeba podstawianie sekwencji sterujących mieszać z napisami.
serial-3.asm pisze:Kod: Zaznacz cały
ldx #vt100green
jsr serialSendText
ldx #vt100bold
jsr serialSendText
ldx #message2a
jsr serialSendText
ldx #vt100reset
jsr serialSendText
ldx #message2b
jsr serialSendText
ldx #vt100reverse
jsr serialSendText
ldx #message2c
jsr serialSendText
ldx #vt100reset
jsr serialSendText
ldx #message2d
jsr serialSendText
;
message2a .az /Antonina/
message2b .az / has a /
message2c .az /cat/
message2d .az / :) /,#$d,#$a
vt100reset: .az #$1B,/[0m/
vt100bold: .az #$1B,/[1m/
vt100reverse: .az #$1B,/[7m/
vt100green: .az #$1B,/[32m/
vt100blue: .az #$1B,/[34m/
vt100cyan: .az #$1B,/[36m/
vt100default: .az #$1B,/[39m/
Ale tak myślę, że wypracuje sobie w końcu jakiś mechanizm, czy makr czy może tagów, co mi ułatwią robienie kolorowych czy pogrubiony czy rewersowych napisów, aby pokrakę jak tu: https://github.com/bienata/monoboard9/b ... rial-3.asm jakoś uładnić.
---
piotrek pisze:...żeby nie ryzykować jego uszkodzenia, a szkoda by była bo to prawdziwy rarytas.
No dobrze, to AD558 wróci do muzealnej gabloty, miał swoje pięć minut, wystarczy. Może i racja, po co kusić licho.
O, za to takie w pudełkach znalazłam: DAC0800 i DAC0808
tylko, że one mają wyjścia prądowe, więc jakiś WO muszę dostawić, na spokojnie zmajstruje coś, bo jednak DAC mi się tu zaczyna przydawać do różnych dziwnych rzeczy.
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
tasza pisze:Już chyba wszystkich znajomych (z tych co mnie jeszcze nie zaczeli unikać) obsępiłam z kostek typu 6264 i doszły dodatkowe trzy: Hitachi, NEC i Hyundai.
Ja nie unikam Ciebie, trochę mi zostało, mogę się podzielić. Mam w DIL
i w SMD
Jeszcze zaplątało mi się parę kostek 6116
O pamięciech 62256 to już nie będę wspominać, jest tego duuuużo.
Prawdziwe słowa nie są przyjemne. Przyjemne słowa nie są prawdziwe.
Lao Tse
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
AD558 farewell
Pozbycie się przetwornika AD558 z instalacji to nie jest wcale takie proste, zasiedział się koleżka sympatyczny, no i wygodny jest we wszelkich pracach, nie sposób zaprzeczyć. Ale tymi testami właśnie zakończymy z nim znajomość, taki life. Materiał nie zmieścił się w poprzedniej wieczorynce o przerwaniach, wspomniałam tylko o możliwości generowania przebiegu w przerwaniach IRQ. Zatem proszę, oto testowy kod, wywołujący prezentowaną już funkcję getNextSample z poziomu handlera przerwania IRQ. Cały programik taki: https://github.com/bienata/monoboard9/b ... -irq-1.asm a ja tylko o paru detalach doopowiem.
Działanie pętli głównej pokazuje filmik króciutki, ot szesnastkowe liczydełko na ekranie, aby dać oznaki życia.
https://youtu.be/9dzkchYNnfs
Na ekranie Analog Discovery też wszystko ładnie wyszło, częstotliwość w miarę taka jak chciałam, amplituda na poziomie 900 mV AC, to startowy etap zabawy.
Procedura obsługi przerwania sprowadza się teraz do potwierdzenia przyjęcia układowi VIA i zawołania wybieraczki do próbek.
sin-irq-1.asm pisze:Kod: Zaznacz cały
irqHandler:
lda #$ff
sta VIA1+IFR
jsr getNextSample
rti
A w pętli głównej liczydło z wykorzystaniem uporządkowanych procedurek pomocniczych, które teraz siedzą w convert.inc https://github.com/bienata/monoboard9/b ... onvert.inc
I teraz tak - tabelka ze wzorcem sinusa SINE_WAVE_256 zawiera 256 próbek pokrywających jedne pełny okres przebiegu. Łatwo sobie zatem obliczyć, że aby uzyskać przebieg sinusoidalny o częstotliwości 1Hz należy próbki podkładać do przetwornika 256 razy częściej (lub ogólnie N razy częściej niż wynikowa częstotliwość sygnału, gdzie N to ilość sampli jednego okresu). Automatycznie dla 25Hz próbki należy wybierać z częstotliwością 6.4kHz.
Stała divider wyliczona jest zatem tak:
sin-irq-1.asm pisze:Kod: Zaznacz cały
divider .eq CLK2FREQ/25/256
i jak pamiętamy poprzednią dobranockę - praktycznie z fIRQ doszłam do ściany. Jak dalej zwiększyć wynikową częstotliwość generowanego przebiegu? I jeszcze tak, żeby się nie narobić?
Skakanie z próbki na próbkę
Można na przykład w obsłudze przerwania zawołać getNextSample nie raz, ale dwa razy. No więc proszę, oto efekt:
No w sumie nie jest źle, częstotliwość wzrosła dwukrotnie, normalnie szykuje się studnia bez dna. Radość krótka była, dołożenie trzeciego wywołania załamało program główny, licznik na VFD zamilkł, zła droga.
No to może drobne hackowanie samej getNextSample, niech wybiera nie kolejną, nie co drugą ale np. co czwartą próbkę? O, to dopiero pomysł szatański jest. I jego wynik:
Niby ponownie lepiej, mam już 100Hz, ale na ekranie ten sinus to jakiś schodkowy się wydaje. Na dokładności odwzorowania przebiegu stracił tym przeskakiwaniem próbek ewidentnie. No nic, kombinujemy dalej - a może co 8 próbek?
Proszę, proszę, nawet 200Hz wyszło, ale po powiększeniu przebiegu - wygląda dość szpetnie, jak zepsute schody ruchome na Dworcu Centralnym w stolicy.
A zupełny smutek jest gdy obejrzy się widmo takiego sygnału. Oczywiście dominujące 200Hz widać, ale od razu zwracają uwagę wyższe harmoniczne po prawej stronie i to na dość sporym poziomie.
Wniosek z powyższej zabawy taki, że czysto programowe generowanie przebiegów okresowych to nie jest zbyt dobry pomysł, szczególnie na sprzęcie, który nie dysponuje stosowną mocą obliczeniową. Rozwiązania sprzętowe DDS są tu jak znalazł, system uP może spokojnie pełnić rolę nadzorcy takiego generatorka, a nie być jego sercem.
Reakcja wskazówki na składową stałą
Na koniec odcinka jeszcze jedno spostrzeżenie, może warto zapamiętać i w tyle głowy mieć że: zwykły klasyczny multimetr z ustrojem magnetoelektrycznym ma prawo pokazać nam dziwadła, gdy na przebieg AC nałożona jest składowa stała, a miernik nie ma układu jej eliminacji. Proszę, oto wizja wartości RMS dla sinus 25Hz / ~900mV wykonaniu trzech mierniczków:
Kolejno:
UM-111 na zakresie 3VAC pokazał 1.5V...
Cyfrowy poradził sobie doskonale.
Wojtkowy V640 z wciśniętą funkcją LF (m.cz.) - idealnie wręcz
Z UM-111 poszło gładko.
Nie miałam siły już szukać po pudełkach, zatem byle 10uF w szereg z UM aby DC przyciąć i...
... od razu lepiej.
No a skąd składowa stała? Koleżka AD558 dla $00 daje 0V, dla $FF daje jakieś 2.56V. Wirtualne 'zero' sinusoidy jest w połowie maks wartości, gdzieś poziomie 1.25...1.28V i to jest w naszym przypadku offset DC. Analog Discovery cwane jest, bo sobie RMS AC zwyczajnie wylicza z wartości próbek w czasie. A mierniki muszą kombinować, coby tu pokazać.
--- Q & A ---
rezasurmar pisze:ale w tym przypadku jak podłączany będzie oscyloskop, to wtórnik można sobie darować
Teraz jest oscyloskop, niezadługo będzie nie-oscyloskop, oczywiście dziękuje za poradę jak uprościć, ale jednak ja spróbuje w/g dokumentacji kostek coś sklecić, nie wygląda to aż tak groźnie, a póki co dla przypomnienia do poduszki mam p.Kulka/Nadachowski, A/C-C/A, Rozdział 5.
gaweł pisze:mogę się podzielić. Mam w DIL
Dziękuje, z pamięci mam wszyściutko co mi teraz potrzeba.
nixie pisze:...cudeńka
Dla jednych stare rupcie, dla innych mega wartościowe znaleziska, najważniejsze, że nie leżą tylko dają frajdę z poznawania.
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Napisanie, że trafiło się ślepej kurze ziarno chyba nie będzie tu przesadą, takie lampki spotkać na bazarze to raz na wielkie nigdy, a przynajmniej dla mnie. Podobieństwo do jednoustrojowych VFD typu IV-6 było łudzące, ale lampki owe to tak zwane numitrony, żarowe lampy wskaźnikowe. Sporo informacji wraz z sympatycznym projektem zegarka znajduje się tu: http://danyk.cz/avr_num_en.html proszę doczytać, gdy kto ciekaw.
Mój modułek zdobyczny to jak zgaduje fragment front-panelu jakiegoś wschodniego ustrojstwa, zawiera sześć plus jeden lampek, pewnie specyfika urządzenia określiła taką organizację wyświetlacza. Lampki są wlutowane w kołki przyłączeniowe, ale do laminatu mocują je takie jakby blaszane łapki, przynitowane go płytki. Całość jest w sumie bardzo solidnie zrobiona i nic się nie telepie.
Zbliżenie na jedną lampkę, widać cieniutkie żarniczki, które świecąc robią za segmenty wyświetlacza.
Odgięłam jedną lampkę dla zdjęcia i na tym koniec takich zabaw, to zbyt cenne, aby mi chrupło z nagła.
Łapki blaszane mocujące lampkę do płytki, w sumie to bardzo rozsądnie pomyślane.
Laminat od spodu, ładnie opisane tuszem kolejne wyprowadzenia, łatwo mi było robić notatki podczas identyfikacji który drucik do czego idzie.
Na sucho test zaświecenia jednego segmentu, zasilacz regulowany oczywiście. Tu nie ma żartów, przekroczenie parametrów żarniczka (20mA / ~4V) i może być pufff. I po zabawie.
Niestety specyfika urządzenia w którym te cudne lampki pracowały wykluczyła z użycia punkty dziesiętne, ich wyprowadzenia zostały ucięte około 2mm od szkła, no szkoda wielka. Taka kropka dziesiętna w formie świecącego pazurka wygląda bardzo ciekawie. Ja myślę, że docelowo to jakoś się podłącze do tych wystających resztek, lutowanie pewnie odpadnie, ale jakby drucik dodatkowy zawinąć a potem nasadzić i zacisnąć mikrotulejkę z alu. to powinno naprawić końcówkę, okaże się...
No i pomalutku rusza budowa części sterującej na ULN2804 i rejestrach CD4094.
W półmroku jarzące się lampki IV-9 wyglądają po prostu cudnie, można się na nie gapić dowolnie długo.
sterowanie - numitronowe liczydełko
Nie ma co wynajdywać kolejnej Ameryki, sterowanie zdecydowałam zrobić jak najprostsze sprzętowo, w sensie ilości drutu pomiędzy płytką Motorolkową a lampami. Stanęło na buforach mocy oraz popularnych rejestrach przesuwnych zapiętych w kaskadę, schemat ideowy poniżej:
Na płytce stykowej może nieco strasznie wygląda, ale tam tak naprawdę nic nie ma, ot - kłębek drutu.
Całość już w bezpośrednim otoczeniu Motki, V640 ponownie w roli amperomierza, ciekawam była ile prądu zajada trzypozycyjny pracujący zestaw numitronów - wyszło na poziomie dwustu-trzystu mA
No i wieczorna nastrojowa wystawka.
Efekt działania programiku https://github.com/bienata/monoboard9/b ... mple-1.asm
jest następujący:
Może tu dwa zdania o programowym sterowaniu. Funkcja konwertująca wartość binarną do szesnastkowej jest bliźniacza do tej, co kiedyś umieściłam w module convert.inc, teraz tylko zamiast zwracać do bufora kody ASCII zwraca kompozycje segmentów dla danych cyfr szesnastkowych.
Definicje cyfr:
iv-9-simple-1.asm pisze:Kod: Zaznacz cały
SEG_A .eq 1<<0
SEG_B .eq 1<<1
SEG_C .eq 1<<2
SEG_D .eq 1<<3
SEG_E .eq 1<<4
SEG_F .eq 1<<5
SEG_G .eq 1<<6
DIG_0 .eq SEG_A|SEG_B|SEG_C|SEG_D|SEG_E|SEG_F
DIG_1 .eq SEG_B|SEG_C
DIG_2 .eq SEG_A|SEG_B|SEG_D|SEG_E|SEG_G
DIG_3 .eq SEG_A|SEG_B|SEG_C|SEG_D|SEG_G
DIG_4 .eq SEG_F|SEG_G|SEG_B|SEG_C
DIG_5 .eq SEG_A|SEG_F|SEG_G|SEG_C|SEG_D
DIG_6 .eq SEG_A|SEG_C|SEG_D|SEG_E|SEG_F|SEG_G
DIG_7 .eq SEG_A|SEG_B|SEG_C
DIG_8 .eq SEG_A|SEG_B|SEG_C|SEG_D|SEG_E|SEG_F|SEG_G
DIG_9 .eq SEG_A|SEG_B|SEG_C|SEG_D|SEG_F|SEG_G
DIG_A .eq SEG_A|SEG_B|SEG_C|SEG_E|SEG_F|SEG_G
DIG_B .eq SEG_C|SEG_D|SEG_E|SEG_F|SEG_G
DIG_C .eq SEG_A|SEG_D|SEG_E|SEG_F
DIG_D .eq SEG_B|SEG_C|SEG_D|SEG_E|SEG_G
DIG_E .eq SEG_A|SEG_D|SEG_E|SEG_F|SEG_G
DIG_F .eq SEG_A|SEG_E|SEG_F|SEG_G
I konwersja w pełnej krasie:
iv-9-simple-1.asm pisze:Kod: Zaznacz cały
byte2sevenSeg:
pshu x,y,b ; uses y,b then save
pshu a
ldy #.b2sevenDat ; table of 7-seg
exg b,a ; input in b
lsrb
lsrb
lsrb
lsrb ; >> 4
andb #$0f ; first 4 bits
lda b,y ; a := ascii [ b ]
sta 0,x+ ; msb
pulu a
exg b,a ; input in b again
andb #$0f ; first 4 bits
lda b,y ; a := ascii [ b ]
sta 0,x ; lsb
pulu x,y,b ; gimme back
rts
.b2sevenDat
.db DIG_0,DIG_1,DIG_2,DIG_3,DIG_4,DIG_5,DIG_6,DIG_7
.db DIG_8,DIG_9,DIG_A,DIG_B,DIG_C,DIG_D,DIG_E,DIG_F
word2sevenSeg:
pshu d,x ; ab,x protection
jsr byte2sevenSeg ; msb as is
leax 2,x ; x += 2, next 2 chars
tfr b,a ; lsb from b
jsr byte2sevenSeg ; msb as is
pulu d,x ;
rts
Jak łatwo zauważyć, cała sztuczka polegała na podmianie tabeli stałych a ASCII na 7-seg, można sobie zatem wyobrazić bardziej chytrą funkcyjkę, która zależnie od aktualnych parametrów wywołania zwróci albo znaki albo segmenty. Teraz nie chce inwestować w to czasu, ale całkiem możliwe że taka bardziej uniwersalna powstanie.
Nieco bardziej ciekawe jest ładowanie bufora wyświetlacza do 24 bitów rejestrów 4094.
Tak wyglądają przebiegi na wejściach kaskady rejestrów - sygnały CLK, DATA i STROBE
Generuje je sekwencja wywołań funkcji postByte, która podany do akku. bajt wsuwa do rejestru począwszy od najbardziej znaczącego bitu.
iv-9-simple-1.asm pisze:Kod: Zaznacz cały
; acc - byte to set
postByte:
ldx #8
.pb:
pshu b ; save on stack
andb #%1000.0000
beq .skipIfZero
;set data pin
lda #CD4094_DATA_HI
sta VIA2+ORA
.skipIfZero:
pulu b ; restore for a moment
lslb ; >> next incoming bit
pshu b ; save back
lda #CD4094_CLK_HI
ora VIA2+ORA
sta VIA2+ORA
lda #0
sta VIA2+ORA
dex
bne .pb
pulu b ; just for stack balance
rts
Impulsik (strob) na koniec utrwalający wpis produkowany jest przez funkcję commitDisplay
iv-9-simple-1.asm pisze:Kod: Zaznacz cały
commitDisplay:
; finally strobe
lda #CD4094_STROBE_HI
ora VIA2+ORA
sta VIA2+ORA
lda #CD4094_STROBE_LO
anda VIA2+ORA
sta VIA2+ORA
rts
Tak wygląda na żywo praca liczydełka i przebiegi ładowane do rejestrów.
https://youtu.be/WPYUImK6xG0
A tu z bliska ciepłym blaskiem jarzące się cyfry sterowane przez Księżniczkę Motorolę.
https://youtu.be/FvNzoY_rs6M
https://youtu.be/7vhHI5mqAdQ
Warto zwrócić uwagę na sporą bezwładność cieplną żarników, rozświetlenie i gaśnięcie segmentów nie jest natychmiastowe i taka praca dodaje lampce swoistego uroku.
W dalszej kolejności spróbuję zaprząc do pracy kostki TLC5916, podpatrzyłam że na nich też opierają niektórzy sterowanie numitronami, no zobaczymy jak to wyjdzie. Ale to innym razem...
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Ale no masz fart, z tym że robisz wszystko aby ten fart ci się przytrafił. Super robota
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Nie wszystkie tematy są ciekawe, są też zupełnie nieciekawe, wręcz nudne niczym tytułowa breja, no ale aby cokolwiek dalej było trzeba do niech podejść i domknąć jakoś, no tak. Zatem dwa słowa o tych układach transmisyjnych, które pomiędzy ACIA 6551 a złączem Euro sobie siedzą, chwila i będzie z głowy.
Napędem logiki nadawczo-odbiorczej UART-a jest lokalny generatorek kwarcowy o częstotliwości 1.8432MHz, jego obecność i parametry wynikają bezpośrednio z noty aplikacyjnej układu UM6551.
W zamyśle Księżniczka Motorola miała gadać po RS232, zatem dobudowano układy konwersji TTL/RS232 w oparciu o kostki - odbiornik linii symetrycznej UA9637
http://www.micropik.com/PDF/UA9637.pdf
oraz UA9636 nadajnik linii:
http://pdf.datasheetcatalog.com/datashe ... 8781_1.pdf
Kostka UA9636 to w sumie ciekawy okaz przyrodniczy, nadajnik linii z ustawialnym czasem narastania/opadania transmitowanego sygnału. Służy do tego wejście W-S do którego zapina się idący do masy rezystor (Wave Shaping Resistance). U mnie oporniczek jest 100K zatem w/g fig.6 pg.5 odpowiada to czasowi 10 us, sprawdzę przy okazji czy to nie lipa. Można się zastanawiać, po jaki rympał wpakowano tam takie dziwadło...no cóż, aktualnie na swoim fabrycznym podwórku spotykam linie transmisyjne pracujące w warunkach masakrystycznych wręcz zakłóceń, tam szybkości transmisji czasem są po 300 bodów (sic!) i takie tory funkcjonują wyśmienicie. A to dzięki zastosowaniu temu podobnych cudacznych kostek do różnicowego nadawania i odbierania, gdzie dodatkowo czasem można manewrować kształtem (stromością) przebiegu i jakoś dostosować do warunków środowiskowych, coś a'la 75175...
W jednej z Motkowych płytek nadajnik UA9636 ma naklejony maleńki radiator, no ... ciekawe płytka musiała mieć życie na docelowym obiekcie skoro kaloryferek dali.
Metodą długopisowo-buzzerkową rozrysowałam sobie część nadawczo-odbiorczą
I wyszedł taki jak poniżej i mam nadzieje, że w miarę sensowny kawałek schematu.
W międzyczasie dobra dusza podrzuciła mi kawałek kabla szeregowego, płaski, bardzo fajnie zrobiony, od jakiegoś sprzętu CISCO ponoć, wtyczki DB9+RJ, no i dylemat mam - na tym kabelku się zapinać do RS232 czy na konwerterze USB, ot życiowe problemy...
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
No i nas też dopadło, a jako najbardziej o własnych siłach łażąca z całej gromadki, stałam się stałą bywalczynią lokalnej apteki. No i proszę, nawet w kichającej i prychającej kolejce do okienka można oprócz dodatkowych wiruchów-gratisów złapać coś na kształt natchnienia. Facet przede mną całą pakę fiolek na próbki kupił, aż się dziwię po jaki rympał tyle, no ale taka myśl - czy to nie byłoby dobre opakowanie dla zaokiennie uplasowanego czujnika temperatury? Jakkolwiek śmieszne wyda się obudowanie sensora pojemnikiem na eufemistycznie określając - medyczny materiał laboratoryjny o podwyższonym ryzyku skażenia bakteriologicznego - taka obudowa póki co sprawdza się znakomicie.
A zatem proszę bardzo - oto czujnik MCP9700 we fiolce na
O układzie MCP9700 dużo i dokładnie zostało napisane tu: Tania alternatywa dla LM35 , deklarowałam tam także, że zaległość nadrobię, co niniejszym się dzieje. Potrzeba - fiolkę do pobrań, połówkę magnesu z twardego dysku, troszkę taśmy izolacyjnej, trójprzewodową wiązkę kabelków, oczywiście układzik MCP9700, najlepiej w obudowie TO-92, przyda się saszetka z granulkami pochłaniającymi wilgoć, jest w niektórych lekach.
Do MCP lutujemy wiązkę, oraz pomiędzy VCC i GND niewielki kondensatorek, jakieś 10uF
Oczywiście w boku fiolki wypalamy lutownicą otworek na kabel, wkładamy pochłaniacz wilgoci i zamykamy wieczkiem. Aby MCP nie latał po obudowie - dobrze nasadzić go nóżkami na `łopatkę` w dekielku.
Deczko oblatujemy dookoła taśmą izolacyjną, co skutecznie zamyka obudowę, następnie poprzecznie przytwierdzamy fiolkę do magnesu neodymowego. Tu porada: dobrze na spodnią część magnesu położyć kilka warstw zwykłej materiałowej taśmy izolacyjnej, będzie taka jakby cieniutka poduszka amortyzująca no i będzie łatwiej oderwać całość od blaszanego parapetu.
Cała końcówka pomiarowa wygląda u mnie tak.
A tak w warunkach plenerowych, przyssana do parapetu.
Test miernikiem (Wojtkowy V640 @ 1.5VDC) pokazał jakieś 530...540mV, co po odjęciu offsetu 0.5V i podzieleniu przez 10mV dało rankiem 4`C - no i tak niefajnie właśnie wtedy miałam za oknem...A wskazanie AD2 tylko to potwierdziło:
retrokonwersja analogowo-cyfrowa
Zachwostkę przez chwilę miałam, kto ma w dzisiejszym odcinku wystąpić. Sami chętni nagle, o i ADC0804 i wypasiony AD7862 się znalazł, ale one poza szeregiem różnych zalet miały jedną drobą wadę...nic o nich nie napisano w mojej ulubionej ostatnio książce.
Strona 309
No i prosze, w kultowej `Przetworniki analogowo-cyfrowe i cyfrowo-analogowe` panów Kulka/Libura/Nadachowski na wspomnianej stronie zaczyna się opis układu kompensacyjnego przetwornika A/C typu AD574A firmy Analog Devices. Oto i on, w pełnej krasie:
Moja kostka pochodzi z początku lat dziewięćdziesiątych i jak łatwo zgadnąć została wydłubana z przemysłowego szrotu, ot poszczęściło się kiedyś. Detalicznie informacje o przetworniku oczywiście we wskazanej książce, do kompletu dokumentacja firmowa: http://www.analog.com/media/en/technica ... AD574A.pdf
Parametrycznie układ jest całkiem w porządku, posiada całkiem przyjemny interface do systemu mikroprocesorowego, wada tylko taka, że oprócz 5V skubaniec chce symetrycznego zasilania +/- 12 lub 15V. No, to mnie deczko zbiło z tropu bo na podorędziu takiego zasilacza nie mam, ale znalazła się dobra dusza, co się na kilka dni podzieliła modułkiem przetwornicy 5/±12V i zabawa trwa.
Schemat ideowy poletka doświadczalnego jak poniżej:
Przetwornik pracuje w trybie unipolarnym (0..10V) z 12 bitowym interface. Wyzwalanie konwersji i odczyt danych jest przy pomocy dodatniego impulsu na wejściu R/!C.
ewolucja piaskownicy
Skalowanie układu na podstawie data-sheet w sumie specjalnie się nie wczuwałam, przecież to zabawa jeno.
Offset na wejściu BIPOFF ustawiłam na 0V pierwszym trymerkiem, potem trymerkiem drugim, pomiędzy końcówkami REFIN-REFOUT wyłapałam moment, gdzie przy Uwe=10.0V do samych jedynek, czyli 0xFFF brakowało mi tylko jednego, tego najmłodszego bitu. Taką operację można zrobić raptem dobrym woltomierzem i sondą logiczną, to wystarczy, no i tu po raz kolejny V640 się sprawdził.
Dalej seria pomiarów - aha i zapamiętajmy jeszcze, że dalsze wyliczanki bazują na tym, że ΔV = 2.44mV/bit
Pełna skala, test:
0xFFF = 4095, 4095 * 2.44mV = 9.99V
źródełko referencyjne LT431 w podstawowym układzie 2.5V
0x400 = 1024, 1024 * 2.44mV = ~2.50V (2.498)
MCP9700 za oknem:
0xE8 = 232, 232 * 2.44mV = 0.566V, (0.566-0.500)[V] / 0.01[V/`C] = 6.6`C
Bateria płaska:
0x799 = 1945, 1945 * 2.44mV = 4.74V
Od strony oprogramowania sprawa nie jest skomplikowana, w takim układzie jak przestawiłam wystarczy na wejście R/!C podać jedynkę logiczną, wtenczas otwierają się bufory trójstanowe przetwornika i można odczytać wyniki poprzedniej konwersji. Podanie zera, a więc wygenerowanie opadającego zbocza odcina przetwornik od szyny a jednocześnie uruchamia kolejną konwersję, której zakończenie możemy na przykład wykryć opadającym zboczem sygnału STS (Status). Pokazuje to rysunek poniżej:
A fragment programu https://github.com/bienata/monoboard9/b ... d574-1.asm zbierającego półtorej bajtu z PA/PB układu VIA1 celem pokazania w hex na VFD jest następujący:
ad574-1.asm pisze:Kod: Zaznacz cały
lda #5
ldx #txtBuff
jsr memZero
; prepare to read data
lda #$04 ; PA2=1
sta VIA2+ORA
; get MSB
lda VIA1+IRB
anda #$0F
; get LSB
ldb VIA1+IRA
pshu a,b
; and start next conversion cycle
lda #$0
sta VIA2+ORA
pulu a,b
; show data
ldx #txtBuff
jsr word2hex
ldx #txtBuff
jsr vfdPrint
Sama konwersja, jak widać po czasie H na STS trwa około 25 us, całkiem żwawy koleżka z tego AD574 jak na te latka.
A tu widać ile czasu zajmuje logice przetwornika wystartowanie kolejnej konwersji po wydaniu polecenia takowej, to jakieś 340ns, i to już jest czas, który trzeba mieć na uwadze projektując na przykład dekoder adresowy lub inna logikę współpracująca bezpośrednio z magistrala systemu mikroprocesorowego.
pespektywy chłodnym okiem
No cóż, biorąc pod uwagę, że modułek przetwornicy muszę zwrócić, a zanim swój zrobię to się zejdzie - kostka AD574 kariery medialnej wielkiej nie zrobi, raptem kilka dni zabawy jeszcze. Przetwornik jest całkiem sympatyczny i z regulacją kłopotów nie było, tylko te nieszczęsne ujemne zasilanie. Tak czy inaczej warto dokładnie przeglądać stary złom przed wyrzuceniem, takie kostki dają sporo radochy, gdy po dwudziestu paru latach znowu mogą coś sobie zmierzyć.
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Wspominałam wcześniej, że aby dobrnąć do ciekawszych tematów to trzeba przejść przez flaki z olejem w postaci rozpisania co jest do czego w torze nadawczo-odbiorczym płytki MB09. Teraz nadszedł czas na pełne oswojenie sprzęgu szeregowego, a zatem i konieczność uporządkowania okablowania w lewej części płytki, tam gdzie złącze systemowe. Po dłuższym namyśle postanowiłam wykonać pionową płytkę-protezkę, tam będzie terminal zasilania, RS232 no i miejsce na ewentualnie później dodawane układziki bezpośrednio współpracujące z szyną systemową. A zatem było tak:
Żeńskie złącze DIN 64 pin ze szrotu plus kawałek uniwersalki, co mi został z breakout-board.
Złącze oczyszczone z resztek drucików.
Przymiarka na sucho, jakby to mogło wyglądać, bardzo do takich ustawek przydaje mi się druga płytka MB09, wielkie to ułatwienie.
Przytrzymywaczka złącz ARK czyli ustawianie terminala do zasilania, dwa kolory, bo to i plus i minus będzie tam leciał.
Ooooo, no nie byłabym sobą - oldschoolowe ledziki na indykatory zasilania.
Od strony widowni póki co wygląda to chyba nieźle.
Ale nie drążmy zbytnio tematu...
Gotowa że tak ujmę - ścianka systemowa.
I chyba całkiem dobrze wtapia się w tło.
Aha, no i prosty kabelek do złącza DB9, tylko GND,TxD,RxD.
No i po tych przygotowaniach zasiadłam do tytułowego gadania do obrazu, czyli spróbujmy uruchomić dwukierunkową transmisję z UM6551 ale przez obecne na płytce buforki UM9637 (odbiorczy) i UM9636 (nadawczy). No i tu pierwszy niefart - zagadnienie zasilania układu nadawczego, a do zabaw aktualnie wykorzystuje zasilaczyk-samoróbkę +/-5V.
W datasheet do kostki ( ponownie: http://www.ti.com/lit/ds/slls110b/slls110b.pdf ) napisali, że ujemne napięcie zasilające powinno być poniżej -10V. Skądinąd wiem, że RS232 mojej płyty ładnie pracuje już na +/-5V stąd myśl - a nuż załapie i zagada. A tu klops, kostka w ogóle nie chciała zmieniać stanu wyjścia! Ustawiała się wyjściem cholera na -4.9...5V (sprawdzone na AD2) i tak sobie trzymała to ujemne, bez względu na zera i jedynki z TxD układa ACIA. No i tu powstało zagadnienie pod tytułem - potrzeba do UM9636 jeszcze bardziej ujemne zasilanie. Pomysł zatem o tyle śmieszny co skuteczny - w szereg z ujemna końcówką zasilacza - bateria płaska!
Dało w sumie jakieś -9.5V co skutecznie odetkało tę szeregową niemotę i zaczęła gadać.
Wystawka z baterią wyglądała pokracznie, ale grunt że ruszyło.
Zbliżenie na V640, ponieważ przy okazji pomierzyłam prąd pobierany z ujemnego zasilania, w końcu jadę na bateryjce, trzeba poboru pilnować i jakieś -25mA mi średnio wychodziło.
Stan baterii w okolicach godziny 11 - mamy 4.2V
A tyle ubyło na wieczór, fotka jakoś z 18..19 - już 4.1V, systemik żwawo chodził cały dzień.
No i przy okazji mały eksperyment, wynikający z trudności filmowania wyświetlacza VFD - jak zrobić filtr na szkiełko?
Próba ze starą teczką z transparentnego tworzywa jest w miarę udana.
Mamy całkiem przyjemny efekt mgiełki wokół cyferek, uzyskany zupełnie analogowo - ot, teczka już wyciorana i odrobinę matowa, ale taki już jej los - odcinamy sobie po kawałku do różnych swych prac.
Wracając do gadania po szeregowemu - pierwszy naiwny programik https://github.com/bienata/monoboard9/b ... loop-1.asm i jego działanie:
Widać też fragment pętli głównej wykonującej upcase czyli odjęcie od kodu ASCII małej literki wartości 32 i odesłanie znaczka nazat na terminal, tu nie ma co pisać, bo proste jak konstrukcja mopa. Ale ciekawsze jest samo miejsce odbierania znaczków, ponieważ mamy tu przykład komunikacji blokującej, jednym okiem zerkamy w dokumencik http://www.applelogic.org/files/R6551.pdf a drugim na kod:
serial-loop-1.asm pisze:Kod: Zaznacz cały
serialGetChar:
.waitChar:
lda ACIA+STATR
; bit 3 - Register Data Receiver Full
anda #$08
beq .waitChar
lda ACIA+RDR
rts
Koncepcja jest prosta - w pętelce odpytujemy rejestr statusu układu ACIA - ACIA+STATR, sprawdzając stan bitu numer 3 - Register Data Receiver Full, obecność znaczka w buforze oznajmi nam 1 na tym bicie. Gdy wykryjemy że bit 3 jest 1 - odczytujemy znaczek do aku i zwracamy sterowanie. Z punktu widzenia programu głównego wygląda to tak, że sterowanie zostanie przekazane procedurce serialGetChar i zwrócone gdy znaczek nadejdzie linią RxD. No a jak nie nadejdzie? To będziemy sobie czekać do us...tania zasilania systemu, czyli teoretycznie bardzo długo. Czyli mamy odbiór blokujący, ponieważ w sumie nic więcej mądrego nie robimy poza czekaniem na skompletowanie bitów w rejestrze szeregowym portu. Oczywiście, można na siłę w międzyczasie coś tam próbować robić w kodzie, ale tu problem z ochroną rejestrów się pojawia i z zależnościami czasowymi, łatwo doprowadzić do sytuacji, że nowy nadchodzący znaczek przeoczymy... Tak więc synchroniczne odbieranie blokujące jest fajne do celów pokazowo-zabawowych, ale w praktyce nie ma większego zastosowania.
A przy okazji ciekawostka - zerknijmy na datasheet, strona 3, opis STATUS REGISTER. Bit 3 jak wspominałam nazywa się Register Data Receiver Full a w tabelce nawali go skrótem RDRE, to E to od Empty pewnie i to całkiem wywraca logikę postrzegania tego bitu, bo piszą o Full. Inny d-s ( https://www.cselettronica.com/datasheet/UM6551.pdf ) nie ma bitowej tabelki ze skrótami, ma tylko opis, więc tu nie ma zachwostki. Ot wniosek taki, że nawet z firmową dokumentacją uważać trzeba.
Przerwania IRQ w 6809 - opowieści dziwnej treści v.3
Rozwijamy koncepcję odbierania danych z portu szeregowego o przerwania maskowalne, a tak! Układ UM6551 jest całkiem cwaną kostką i potrafi zgłaszać przerwania maskowalne IRQ gdy w jego logice zajdą jakieś ciekawe zdarzenia, np. wysyci się bufor nadawczy, czyli zostanie nadany znaczek lub zapełni się bufor odbiorczy i mamy nowy znaczek gotowy do obróbki. Nadawanie w przerwaniach to może kiedyś, teraz skupimy się na odbieraniu.
Gadanie na raty - przerwania od układu odbiorczego ACIA
Pamiętamy z przerwań od Timer 1 VIA, ze podstawą jest zdefiniowanie wektora procedury obsługi przerwań IRQ, musimy zatem napisać funkcyjkę np. irqHandler
serial-loop-2.asm pisze:Kod: Zaznacz cały
irqHandler:
; confirm irq reading stat
lda ACIA+STATR
; get char from RX
lda ACIA+RDR
sta ACIA+RDR ; do echo
; store char in buff
ldx rxBufferPtr
sta ,x+ ; save char
stx rxBufferPtr ; save prt
clra
sta ,x+ ; save NULL after
; check against buff end
cmpx #rxBuffer+10 ; <<=== here!
bne .hasEnoughSpace
; reinit rx buff
ldx #rxBuffer
stx rxBufferPtr
.hasEnoughSpace
rti
i zainstalować ją w mapie przerwań systemu:
serial-loop-2.asm pisze:Kod: Zaznacz cały
system jump table, must be in this particular order
; .....
>DEF_SYS_JUMP IRQ_____, irqHandler
; .....
>DEF_SYS_JUMP RESET___, main
Funkcyjka irqHandler sama w sobie nie jest zbyt skomplikowana - wyciąga znak z rejestru danych ACIA+RDR i składuje w buforze odbiorczym rxBuffer, zgodnie z wartością wskaźnika rxBufferPtr. Wskaźnik jest inkrementowany po każdym znaczku, ale nie dalej niż do 10 względem początku, takie zabezpieczenie przed pomazaniem sobie po pamięci, o tym będzie dalej.
Tu dla demonstracji dorobiłam jedną rzecz - lokalne echo. Właśnie odebrany znaczek jest wstawiany nazat do bufora nadawczego ACIA+RDR i wysyłany, to na putty daje obraz pisanych literek. Niezmiernie ważne jest, aby każde przerwanie od ACIA potwierdzić, że już obsłużone, robimy to zwyczajnie odczytując rejestr statusu ACIA+STATR. Ta operacja zresetuje bit 7 (IRQ) w statusie, ACIA będzie w stanie zgłosić kolejne przerwanie gdy odbierze dane.
Oczywistym jest, że aby sztuczka nam zadziałała, trzeba zezwolić układowi ACIA na zgłaszanie przerwań od odbiornika, ustawiamy w ACIA+CMDREG bit 1 czyli Receiver Interrupt Request Disabled (IRD) na 0 (czyli enablujemy) oraz ewentualnie Data Terminal Ready (DTR, bit 0) na 1, tak dla porządku. Na koniec, po zainicjowaniu ACIA zezwalamy globalnie na przerwania maskowalne rozkazem CLI.
Programik na żywo można poobserwować tu:
https://youtu.be/zPOVrYCBhuY
Pierwsza linia wyświetlacza to 10-znakowy bufor, odświeżany na VFD zgodnie z opóźnieniem delay, w dolnej linii liczy sobie szesnastkowe liczydełko, aby mieć pojęcie o upływającym w programie czasie, druga (prawa) liczba szesnastkowa to bieżąca wartość wskaźnika bufora odbiorczego rxBufferPtr. Widać jak ładnie zawija się na początkową wartość gdy dojdziemy literkami z putty do jego końca.
Rozlana kawa
Z utratą kontroli nad zawartością pamięci, to jak w życiu... jak już się rozleje, to tylko modlić się do bożków, aby nie na nic ważnego. Efekty specjalne, jakie mogą wystąpić przy jak ja to mawiam - mazaniu sobie po pamięci - możemy zaobserwować w programiku https://github.com/bienata/monoboard9/b ... loop-3.asm Celowo został spreparowany i zawiera błędy - będzie na co popatrzeć.
Najpierw przygotujmy sobie podatną na uszkodzenia strukturę danych w pamięci RAM:
serial-loop-3.asm pisze:Kod: Zaznacz cały
.sm RAM
.or $0000
textMessage .bs 32 ; any text here
rxBuffer .bs 8 ; receive buff very small!!!
counter .bs 2 ; important var as a neighbour
rxBufferPtr .bs 2
Zmienna na napisy i konwersje textMessage nie jest jakoś specjalnie zagrożona, jest pierwsza od $0000. Potem mamy raptem osiem znaczków na bufor odbiorczy, łatwo zgadnąć, że tu sobie za bardzo nie poodbieramy. Dalej, zaraz za buforem jest arcyważna zmienna counter, która jest przecież prezentowana on-line na wyświetlaczu. A za jej dwoma bajtami jest następna dość żywotna zmienna - wskaźnik na bufor odbiorczy, takoż dwa bajty.
No i wyobraźmy sobie teraz, że w irqHandler daliśmy ciała niechcący i że źle wykrywamy koniec obszaru na bufor odbiorczy znaczków, czyli kolejno nadchodzące bajty danych, będziemy chomikować nie bacząc na to, że minęliśmy koniec bufora. O, mniej więcej tak:
serial-loop-3.asm pisze:Kod: Zaznacz cały
irqHandler
; ... blah blah blah
; check against buff end
cmpx #rxBuffer+12 ; <<=== here!
bne .hasEnoughSpace
; reinit rx buff
ldx #rxBuffer
stx rxBufferPtr
.hasEnoughSpace
rti
Wartość 12 nie jest tu przypadkowa, tak napisany kod wjedzie ze znaczkami z portu szeregowego w inny obszar danych, w tym przypadku uszkodzi nam zmienną counter. Co ciekawe, program będzie uparcie na niej pracował, na filmiku poniżej widać jakie durnoty będą pokazywały się na wyświetlaczu VFD.
https://youtu.be/FWLkp4Xs9oM
Przy odrobinie wysiłku, można by rosnącym buforem znaków wjechać we wskaźnik rxBufferPtr, która to zmienna koordynuje jego pracę. No to już jest praktycznie gwarancja niezłej kaszanki, zawartość wskaźnika będzie wynikała z tego, co odebrano z portu szeregowego, więc kolejne znaczki będą zgodnie z tym wskaźnikiem zapisywane w zupełnie przypadkowych miejscach RAM. Jeżeli trafią w obszar, gdzie w RAM jest składowany wykonywalny kod i go zabrudzą - będzie pozamiatane.
Tu ciekawostka: płyłeczka moja cudna MB09 ma na dip-switch do konfiguracji banków pamięci po jednym prztyczku `Write Protect` per sekcja (kostki A lub B). I pomimo, że w danym banku mamy RAM to możemy zabronić do niego zapisów, no tak! To na okazję włożenia tam np. NVRAM, o której zawartość bardziej niż zwykle się troskamy (np. jakaś konfiguracja, stałe, tabele, etc) a która może na skutek błędu jak opisałam powyżej pójść do dołu z wapnem w parę milisekund.
Dwa bajty i tyle krzyku
Raz to dwa bajty jakiegoś liczniczka, a innym razem do klopsu wystarczy jeden bajt, który odpowiada za stan przetwornika C/A lub załączanie styczników czy czegoś większej mocy. Jasno wynika, że dłubiąc szczególnie w assemblerze trzeba bardzo uważać na granice adresowe zmiennych, zwracać baczną uwagę, aby nie nadpisać sobie albo danych albo i kodu. Oczywiście z myślenia nic nie zwalnia, ale częstokroć narzędzia potrafią nam pomóc, SB-Assembler w sumie też.
Poniżej nieco przepisany kawałek programiku serial-loop-3.asm, ale tak aby pewne wartości powyliczały się same i były dostępne w formie stałych w kodzie, całość tu: https://github.com/bienata/monoboard9/b ... loop-4.asm
serial-loop-4.asm pisze:Kod: Zaznacz cały
textMessage .bs 10 ; any text here
MSG_TEXT_LEN .eq *-textMessage ; compute length
rxBuffer .bs 20 ; buff for incoming stuff
RX_BUFF_LEN .eq *-rxBuffer ; compute length
counter .bs 2
rxBufferPtr .bs 2
Widać, że wartości MSG_TEXT_LEN oraz RX_BUFF_LEN zostaną wyliczone podczas układania kolejnych bajtów w segmencie RAM, można ich dalej spokojnie używać, ufając że zawierają sensowne wartości.
serial-loop-4.asm pisze:Kod: Zaznacz cały
; check against buff end
cmpx #rxBuffer+RX_BUFF_LEN
bne .hasEnoughSpace
; .....
lda #RX_BUFF_LEN
ldx #rxBuffer
jsr memZero
Oczywiście, jeżeli nasze auto-wyliczanki są bardziej skomplikowane niż proste odejmowanie od bieżącej wartości wskaźnika pamięci (*) to dla weryfikacji zerkamy w wynikowy listing czy coś niechcący nie poszło w bok:
serial-loop-4.lst pisze:Kod: Zaznacz cały
0000- 7 .sm RAM
0000- 8 .or $0000
0000- 9 ; vars and temps here
0000- 10 textMessage .bs 10 ; any text here
000A- 11 MSG_TEXT_LEN .eq *-textMessage ; compute length
000A- 12 rxBuffer .bs 20 ; buff for incoming stuff
0014- 13 RX_BUFF_LEN .eq *-rxBuffer ; compute length
001E- 14 counter .bs 2
0020- 15 rxBufferPtr .bs 2
0022- 16
0022- 17 ;
0000- 18 .sm CODE
;.....
F120- 92
F120-86 14 93 ( 2) lda #RX_BUFF_LEN
F122-8E 00 0A 94 ( 3) ldx #rxBuffer
F125-BD F0 BE 95 ( 8) jsr memZero
F128- 96
Powyżej widać, że MSG_TEXT_LEN == $A, RX_BUFF_LEN == $14 , sztuczka znaczy się działa, co w sumie jest dość optymistyczne.
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
No, jak szaleć to szaleć, tym razem nieco z rozmachem będzie.
Skoro mamy taki fajny przetworniczek i pluche za oknem, to może spróbujmy i temperaturę zaokienną zebrać i może temperaturę pokojową? A fakt, że Księżniczka Motorola jest namiętnie gorąca też się przyda i jej ciepłotę także pomierzymy. Przy okazji tak zupełnie eksperymentalnie sygnały z sensorów temperatury oraz wzorcowego źródełka powzmacniamy deko, aby przetwornik A/C nie pracował na minimalnych wartościach. Całość oczywiście pójdzie na wyświetlacz VFD i pomału będziemy się z tym szklanym koleżką żegnać, ponieważ sromotnie zaprzedany został...
Schemacik nowej zabawki przedstawia rysunek:
A ja tylko kilka słów o najżywotniejszych fragmentach.
No więc, źródełko LT431 oraz kostkę MCP9700 już znamy, dokoptowane zostały dwie sztuki LM35 aby mierzyć temperaturę w pokoju oraz na plecach Księżniczki. Sygnały z czujników i źródełka wprowadzamy na multiplekser analogowy MAC24A, są one na takich około poziomach:
wejście S1A - REF - 2.5V
wejście S2A - OUTD - 0.5V w górę, 10mV/C - 500...600mV przy tej pogodzie
wejście S3A - CPU - 0.6V
wejście S4A - INDR - 0.22V
Na pokazowy multiplekser analogowy wybrałam układ Tesla MAC24A, który funkcjonalnie odpowiada układowi CD4052, ale jest deczko bardziej fikuśny ze względu na fajną ceramiczną obudowę. To automatycznie narzuciło konieczność wykorzystania LM741 w obudowie TO-99, zaczyna być vintage. No i oczywiście układziki LM35 też w metalowych obudowach TO-46.
Dokumentacja do MAC-a jest tu:
http://pdf-datasheet.datasheet.netdna-c ... /page1.png
http://pdf-datasheet.datasheet.netdna-c ... /page2.png
Wzmacniaczyk na bazie LM741 to klasyczny układ nieodwracający o wzmocnieniu napięciowym 4 V/V, które to precyzyjnie można wycyrklować potencjometrem w gałęzi sprzężenia zwrotnego. Potencjometr na nóżkach 1-5 wzmacniacza pozwala skompensować napięcie niezrównoważenia, w moich egzemplarzach było na poziomie 2..3mV stad konieczność pozbycia się szkodnika.
To, że układ wzmacnia x4 to wyszło mi z wartości Uref z LT431, pomnożone przez 4 daje mi całe 10V, tyle ile maksymalny zakres przetwornika w mojej aplikacji, więc w ten sposób mam jeden tor pomiarowy do kalibracji.
Aplikację układu AD574 znamy, żadne czary. Drobiazg tylko taki, że dwa najstarsze bity portu PB układu VIA-1 służą teraz do przełączania kanałów multipleksera (wejścia adresowe A1,A0) pracują jako OUT koegzystując zgodnie z resztą bitów ustawionych jako IN dla przetwornika.
Budowanie tego potworka-pająka nie obyło się bez przygód i pomyłek, przy tej ilości kręciołków do regulacji niestety z rozkojarzenia wyregulowałam sobie nie to co potrzeba i był stres jak poprawić, stąd pomysł na oflagowanie poletka, tak dosłownie. Szpile moje krawieckie idealnie wchodzą w płytkę stykową, a chorągiewki opisują co jest do czego.
Blaszany wzmacniaczyk LM741 już w układzie.
Potem dołożyłam multiplekser, uwaga: nieużywane wejścia analogowe - do masy!
No i ja ciągle powtarzam, LM35 w blaszanej puszce jest fajniejszy od wszelkiego plastiku. A przy okazji praktyczniejszy chyba, szczególnie gdy trzeba zapewnić dobry kontakt termiczny.
Bo tak oto przy pomocy glutka z pasty termoprzewodzącej oraz zestawu gumek do plecenia (do nas też dotarła moda na to)...
można się łacno przymocować z czujnikiem na plecach Księżniczki Motorolki.
Jeszcze kilka ujęć z piaskownicy - z lotu muchy.
LM35 do pomiaru temperatury w pokoju, wyniki nie do końca odzwierciedlają rzeczywistość - w tej okolicy i zasilacze i komputer, jest odrobinę cieplej niż w pozostałej części pokoju.
Ponownie blaszany LM741
I mux w gąszczu kabelków.
Po wymęczeniu programiku https://github.com/bienata/monoboard9/b ... -mux-1.asm w pierwszym podejściu tylko wyświetlałam wyniki pomiarów
Potem programik wzbogacony o dolną linię z opisem co jest co.
Sam program nie jest jakoś szczególnie pokręcony, jedyne co, to obsługę A/C zapakowałam w jedną funkcyjkę getADC, która jako parametr dostaje numer kanału do pomiaru. Tu przez chwilę miałam kłopot, ponieważ przełączanie kanałów nakładało mi się z konwersją i w końcu stanęło na tym, ze ustawiam na przysłowiową pałkę kanał multipleksera, wykonuję jeden odczyt z konwersją i jego wynik leci do kosza. Wynik drugiego - jest wystawiany do programu głównego. I szafa jakoś gra.
ad574-mux-1.asm pisze:Kod: Zaznacz cały
;-------------
; ACC - channel
; 0 - 431 10Vref,
; 1 - MCP9700 outdoor
; 2 - LM35 on CPU
; 3 - LM35 indoor
getADC:
; set channel on MAC24A (VIA1.PB7/PB6)
lsla
lsla
lsla
lsla
lsla
lsla << 6
anda #%11000000
; update bits
sta VIA1+ORB
; dummy read/conv first
lda #$04
sta VIA2+ORA
nop
lda #$0
sta VIA2+ORA
ldb #40
.getADCdel
decb
bne .getADCdel
;
; prepare to read real data
lda #$04
sta VIA2+ORA
; MSB (4bits)
lda VIA1+IRB
anda #$0F
; LSB (8bits)
ldb VIA1+IRA
pshu a,b
; and start next conversion cycle
lda #$0
sta VIA2+ORA
pulu a,b
rts
Mierzenie i wypisywanie czterech wartości w pierwszej linii VFD już w pętelce, na podstawie wartości currentChannel
ad574-mux-1.asm pisze:Kod: Zaznacz cały
lda #0
sta currentChannel
.doNext
lda #5
ldx #txtBuff
jsr memZero
lda currentChannel
jsr getADC
ldx #txtBuff
jsr word2hex
ldx #txtBuff
jsr vfdPrint
lda #' '
jsr vfdData
inc currentChannel
lda currentChannel
cmpa #4
bne .doNext
jsr delay
jmp .here ; while(1);
No i filmik, na którym widać tytułową szesnastkową temperaturę:
https://youtu.be/0CWSNR2Sz-s
A przeliczanie wartości na ludzką bardziej postać to już może nie dziś.....
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
tasza pisze:stąd pomysł na oflagowanie poletka, tak dosłownie. Szpile moje krawieckie idealnie wchodzą w płytkę stykową, a chorągiewki opisują co jest do czego.
Genialne w swojej prostocie. Będę musiał wyczaić, gdzie w domu są szpileczki krawieckie, a nie jest to proste zagadnienie.
Prawdziwe słowa nie są przyjemne. Przyjemne słowa nie są prawdziwe.
Lao Tse
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
W komputerowym światku przyjęło się tak, że to mały sterowniczek pełni rolę podrzędną, jako niezbyt mądry do gadania ma niewiele i raczej słucha poleceń z nadrzędnego systemu niż sam o czymś tam decyduje. Z drugiej strony w ludzkim świecie korporacyjnych zagródek za korzystną należy uznać sytuację wręcz odwrotną. To właśnie szefowi swemu trzeba podrzucać do wykonania wszelkie niewdzięczne i nudne zadania! Wymaga to odrobiny sprytu i różnych socjotechnik, ale ma się wtenczas znacznie więcej chwil dla siebie i ktoś jeszcze czuje się potrzebny, no same zalety.
Przeniesienie tego życiowego wzorca projektowego (pojadę elokwentnie: design pattern-u) na Motorolkowe me poletko doświadczalne wynikało głównie z potrzeby obliczeń zmiennoprzecinkowych. Był ostatnio termometr wielokanałowy, ale miał feler taki, że prezentował praktycznie surowe dane z przetwornika A/C i to jeszcze szesnastkowo. Wyliczenie napięcia w V i trzech temperatur w °C wymaga niezbyt wprawdzie skomplikowanych ale jednak procedurek do obsługi wielocyfrowych liczb, czy to w BCD czy choćby binarnie, a pisanie tego póki co zbytnio mi się nie uśmiecha, po prostu nie mam weny. I stąd pomysł szatański - oddelegować zadania numeryczne do PC, niech program na dużym komputerze (serwerze) wykona obliczenia na podstawie danych z żądania, a gotowe wyniki w formie napisu Księżniczka Motorola sobie weźmie i wyświetli na VFD. No i komu będą bili brawo, no komu? Pecetowi pod biurkiem? Haha....no właśnie!
Pomimo bardzo zabawowego charakteru, oprogramowania nieco powstało i było to pisane etapami, raz jeden koniec (Motka) a raz drugi (PC). Pierwsze podejście testowe to na bazie wnętrzności z heksadecymalnego termometru powstał programik https://github.com/bienata/monoboard9/b ... rial-1.asm zatem kilka ciekawszych w/g mnie detali:
ad574-mux-serial-1.asm pisze:Kod: Zaznacz cały
strcat:
; X - dest string being expaned, must be long enough and 0-ended
; Y - src string to add
.doFindEnd:
; scroll to end of dest(X) string
lda ,x+
bne .doFindEnd
; one char back!
dex
.doCopy:
lda ,y+
sta ,x+
bne .doCopy
rts
Zaczynam kompletować procedurki do prostych operacji na napisach, przydają się coraz bardziej, tu mamy strcat - czyli konkatenację (dodawanie) napisów. Naiwne podejście, bez żadnych walidacji sensu wejścia, ale jak na teraz-zaraz to jest ok. Celem zaistnienia procedurki strcat było składanie w jedną tekstowa ramkę czterech liczb szesnastkowych aby to wysłać do PC-a po łączu szeregowym. Ramka zaczyna się daszkiem, potem cztery raz czterocyfrowe dane rozdzielone dwukropkiem, LF na końcu czyli:
Kod: Zaznacz cały
^qqqq:wwww:eeee:rrrr↧
Takie coś powinno być łatwo parsowalne po stronie PC (zwykły split/explode na podstawie `:`) no i jest trywialne do budowy po stronie Motki. Tak wyglądają nadawane w próżnię ramki na terminalu putty:
W międzyczasie wyświetlałam je także na VFD, przecież terminal za chwilę zastąpi aplikacja w Pascalu, trzeba widzieć co tam Motka papla do peceta.
Na żywo wygląda to mniej więcej tak, przy okazji - jako filtr pracuje teraz czerwona pleksi
https://youtu.be/MeF45Q3g2aA
Potem nastał czas na Free Pascal czyli mój ulubiony Lazarus:
No i w południe okazało się jak cieplutko jest na dworze, oto pomiar z MCP9700
Archiwum z programem na PC jest tu: http://bienata.waw.pl/mb09/2018-01-06/a ... al_gui.zip i dwa zdania wyjaśnienia czemu tak dziwnie w środku. Otóż, to nie jest tak, że dane z RS232 są natychmiast po odebraniu parsowane, przeliczane i potem odsyłane nazat do zleceniodawcy. Odebrana z RS232 ramka danych jest odkładana na koniec kolejki Request Queue (w tej roli obiekt TListBox). Takoż wypracowane przez program odpowiedzi są pobierane z Response Queue, z jej początku, program wyliczanki odkłada oczywiście na koniec. Obsługę kolejek napędzają oczywiście dwa osobne timerki cykające kilka razy na sekundę. Może ktoś zapytać - po jasną choinkę taka komplikacja? No więc już piszę - po pierwsze dołożenie buforowania danych umożliwia ręczne symulowanie odpowiedzi i żądań - można przecież i jedno i drugie włożyć programowo do kolejki bez aktywności programu dla Motorolki, no tak. Po drugie, możliwe jest jakby wstrzykiwanie w strumień np. odpowiedzi własnych, ręcznie spreparowanych napisów, do pokazów jak znalazł no i można przetestować cześć odbiorczą na Motce. No i po trzecie - sporo się dzieje na ekranie, więc na filmikach ładnie wygląda.
Przykład wrzucenia w kolejkę z odpowiedziami (Response Queue) własnego napisu, poleci tak samo jak ten wypracowany systemowo:
Mając jakoś tam opanowane wyliczanki (o tym dalej) zaczęła się zabawa z układaniem tego na ekranie VFD:
I na koniec wyszło tak, chyba całkiem, tak myślę....
Działanie kolejkowania żądań i odpowiedzi prezentuje filmik:
https://youtu.be/cHTK-Mju800
Następny filmik to test na udawane temperatury ujemne:
https://youtu.be/F3xnHnLT7og
Za oknem jakby wiosna, a pomimo że MCP9700 obsługuje ujemne temperatury to znikąd ich nie idzie zdobyć. No ale, skoro te 500mV offsetu napięciowego występuje w równaniach, to można odpowiednio je zmieniając wypracować wynik o wartości ujemnej, co właśnie testowo uczyniłam i jestem w miarę gotowa na mrozy w kwietniu lub maju.
Tu chyba dobry moment na wzmiankę o odbieraniu ramek z RS232, od Motki oraz o wyliczankach.
Obsługą bufora odbiorczego zajmuje się handler zdarzenia OnRxData komponentu portu szeregowego, o tak:
main.pas pisze:Kod: Zaznacz cały
procedure TForm1.SdpoSerial1RxData(Sender: TObject);
var s : String;
begin
self.rxBuffer := self.rxBuffer + self.SdpoSerial1.ReadData;
if RightStr( self.rxBuffer, 1 ) = chr( 10 ) then
begin
s := Trim( self.rxBuffer );
self.RequestQueue.Items.Add ( s );
Memo1.Lines.Insert( 0 , Format('%.4d', [lineCounter]) + ' ' + s );
Inc( lineCounter );
self.rxBuffer := '';
end;
end;
Widać, że kod jest zwarty i w sumie sprowadza się do wykrycia LF-a i wstawienie tak zebranego napisu do kolejki wejściowej. Logowanie w TMemo dla ułatwienia obserwacji co się dzieje.
Dalsza akcja jest w hadlerze od timerka kolejki z żądaniami, tam uruchamiana jest metoda ProcessRemoteRequest dostająca jako parametr wywołania pierwszy od głowy element w kolejce (oczywiście o ile takowy jest obecny), ciało ProcessRemoteRequest takie:
main.pas pisze:Kod: Zaznacz cały
function TForm1.ProcessRemoteRequest ( req : String ) : String;
var parts : TStringList;
v : array [0..3] of Double;
i : integer;
begin
parts := TStringList.Create;
parts.Delimiter := ':';
parts.DelimitedText := RightStr( req, Length(req) - 1); // cut ^ at begin
for i := 0 to parts.Count - 1 do
begin
v [i] := Hex2Dec( parts.Strings[i] );
// do calc
case i of
0: v [i] := (( v [i] * 2.44 ) / 4.0 ) / 1000;
1: v [i] := ((( v [i] * 2.44 ) / 4.0 ) - 500 ) / 10;
2,3: v [i] := (( v [i] * 2.44 ) / 4.0 ) / 10;
else
v [i] := 0.0;
end;
end;
parts.Free;
// update numeric indicators
self.UrefLEDDisplay2.Value:= v [0];
if self.LEDButton1.StateOn then v [1] := v [1] * -1.0;
self.outLEDDisplay1.Value := v [1];
self.cpuLEDDisplay3.Value := v [2]; self.LEDMeter1.Position := floor( v[2] );
self.inLEDDisplay4.Value:= v [3];
// ° in CU20025 VFD is coded as $DF :) :)
ProcessRemoteRequest := Format('%1.2f', [ v[0] ] ) + 'V ' +
Format('%2.0f', [ v[1] ]) + char($DF) + 'C ' +
Format('%2.0f', [ v[2] ]) + chr($DF) + 'C ' +
Format('%2.0f', [ v[3] ]) + chr($DF) + 'C';
Caption := ProcessRemoteRequest;
end;
Z tego najważniejsze to rozebranie napisu z `:` na kolejne elementy tablicy oraz wyliczanki napięcia i trzech temperatur, dla LM35 jednakowo ale dla MCP trzeba było uwzględnić offset 500mV. Przy okazji odświeżane są kontrolki-wyświetlacze na ekranie oraz obsługiwane jest wymuszenie/symulacja ujemnej temperatury.
Tak oto powstała nowa zabawka z kolorowymi wyświetlaczami:
Oczywiście, na drugim końcu kabla Księżniczka Morotola pracowała na nowym oprogramowaniu: https://github.com/bienata/monoboard9/b ... rial-2.asm które oprócz odbierania znaczków przerwaniach i prezentacji ich na VFD zawiera także kolejną napisową funkcyjkę strcpy:
ad574-mux-serial-2.asm pisze:Kod: Zaznacz cały
strcpy:
; Y - str from
; X - str to (dest)
; copies chars until zero in src
.doCopy:
lda ,y+
sta ,x+
bne .doCopy
rts
oraz podrasowaną obsługę przerwań IRQ z wykrywaniem końca linii:
ad574-mux-serial-2.asm pisze:Kod: Zaznacz cały
irqHandler
; confirm irq reading stat
lda ACIA+STATR
; get char from RX
lda ACIA+RDR
; check if LF (end of frame) then copy buffers
cmpa #10
bne .doStoreRxChar
; play with received frame
; clear dest buffer
ldx #displayBuff
lda #displayBuffLen
jsr memZero
; copy from rx buffer to vfd
ldy #rxBuffer
ldx #displayBuff
jsr strcpy
; zero rx buffer for sure
ldx #rxBuffer
lda #rxBufferLen
jsr memZero
bra .doReinitRx ; kindly exit from here
.doStoreRxChar:
; otherwise store char in buff
ldx rxBufferPtr
sta ,x+ ; save char
stx rxBufferPtr ; save prt
clra
sta ,x+ ; save NULL after
; check against buff end
cmpx #rxBuffer+rxBufferLen
bne .hasEnoughSpace
.doReinitRx:
; reinit rx buff
ldx #rxBuffer
stx rxBufferPtr
.hasEnoughSpace
rti
W działaniu całość wygląda tak, proszę zauważyć jaka temperatura jest na CPU...prawie 60`C... byłam ciekawa ile spadnie od wachlowania kartką, ale zmiana była dopiero po odsunięciu LM35 od Motki i chwili stygnięcia...
https://youtu.be/C_3Io3ahrOI
Jakie z powyższego wnioski?
Pierwszy i oczywisty - nawet najprostszą rzecz przy odrobinie fantazji można sobie dowolnie skomplikować ale też zapewnić przy okazji sporo ciekawej aktywności i zagadek do rozwikłania. Rozwiązanie, które tu przedstawiłam można doprowadzić do granic absurdu, implementując przykładowo dalszą konwersję °C -> °F przy pomocy wywołania webservice, tak klasycznie, przez SOAP/HTTP(s) i sięgając gdzieś do Internetu. Myślę jednak, że wystarczy zakręcenie na tym poziomie jaki jest i tu dzisiejszy odcinek się kończy.
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
tasza pisze:W komputerowym światku przyjęło się tak, że to mały sterowniczek pełni rolę podrzędną, jako niezbyt mądry do gadania ma niewiele i raczej słucha poleceń z nadrzędnego systemu niż sam o czymś tam decyduje. Z drugiej strony w ludzkim świecie korporacyjnych zagródek za korzystną należy uznać sytuację wręcz odwrotną. To właśnie szefowi swemu trzeba podrzucać do wykonania wszelkie niewdzięczne i nudne zadania! Wymaga to odrobiny sprytu i różnych socjotechnik, ale ma się wtenczas znacznie więcej chwil dla siebie i ktoś jeszcze czuje się potrzebny, no same zalety.
Czyli widać, że świat jest fraktalny. Na każdym poziomie zjawiska są identyczne.
A poważnie: opisałem algorytm konwersji, który może być przydatny. Zamiast liczb zmiennoprzecinkowych można stosować liczby stałoprzecinkowe: dane wejściowe przemnożyć przykładowo przez 1000 [albo i więcej] i uzyskać większą precyzję.
Opisane wyżej rozwiązanie jest również interesujące i może być inspiracją do własnych poszukiwań.
Prawdziwe słowa nie są przyjemne. Przyjemne słowa nie są prawdziwe.
Lao Tse
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
No więc, aby nie było, że nie próbowałam samodzielnie zrobić konwersji to może w formie screen-shot takie luźne przemyślenia moje, jakby bajta przerobić na 3 cyfry na czworakach, czyli w assemblerze. Mam dystans do siebie i na szyderę w sumie jestem dość odporna więc proszę, można używać:
Koncepcja podpatrzona gdzieś w książce, ale implementacyjnie mega upierdliwa: polega na sukcesywnym odejmowaniu najpierw setek, potem dziesiątek - z tego wylicza się wartości kolejnych dekad. To co na obrazku nawet mi zadziałało (chyba przypadkiem....), ale to jeden bajt jeno...czyli 0xFF na 0255. No a całe 16-bit słowo? albo i szersze? No i tu właśnie dotarła do mnie bezsensowność brnięcia w tym kierunku, a w ramach wisielczego humoru powstał wynaturzony klient-serwer w Pascalu.
Post wskazany przez gawła bardzo pomógł, bo z tego najpierw dla testu (ja z tych nieufnych) zrobiłam sobie wyliczankę na piechotę, tak krótko, 8 bit tylko, aby zobaczyć z czym się toto je.
No i przy okazji zaczęło się to w głowie układać jak zdekomponować przesuwany kolorowy algorytm na atomowe operacje. Przede wszystkim wyszło mi na to, że korekcję cyfr (dodawane 3) najłatwiej robić ciurkiem na wszystkich elementach bufora wyjściowego, oczywiście selektywnie i wołać taką procedurkę po każdym przesunięciu w lewo, oprócz ostatniego oczywiście.
Po drugie sama funkcja do konwersji ma własne zmienne robocze, trzy bajty na BCD graniczą bezpośrednio w wejściowymi BIN, cały ten majdan łatwo mi przesuwać Motorolkowymi rozkazami operującymi na pamięci. Tego bufora-śmietnika nikt nie widzi, jest jakby prywatny, procedurka na początku wkopiowuje tam input, a jak już się naliczy, z stamtąd wybiera wyniki do zwrócenia.
Czyli, że korekcja n-bajtowego bufora (2xn cyferek) jest taka:
serial-bcd-1.asm pisze:Kod: Zaznacz cały
;-----
; bcd correction on n bytes
; b - number of bytes
; x - ptr to bcd buff
binToBcdCorrect:
.corrNext:
lda ,x
pshu a ; save for later
anda #$F0 ; high nibble
cmpa #$50 ; >= 5?
bcs .hidone ; skip if not
adda #$30 ; +30
.hidone:
sta ,x ; save hi nibble
pulu a ; get accu again
anda #$0F ; low nibble
cmpa #$05 ; >= 5?
bcs .lodone ; skip if not
adda #$03 ; +03
.lodone
ora ,x ; hi|lo
sta ,x ; save result @
inx
decb
bne .corrNext
rts
Zmienne proceurki konwertującej word na 6 cyfr BCD:
serial-bcd-1.asm pisze:Kod: Zaznacz cały
.sm RAM
.co
| BCD | HI BIN LO |
| +0 | +1 | +2 | +0 | +1 |
<--|<==
.ec
b2bcd_BCD: .bs 3
b2bcd_BIN: .bs 2
I cała procedurka, póki co taka - obsługuje sztywne rozmiary wejścia i wyjścia
serial-bcd-1.asm pisze:Kod: Zaznacz cały
;----------------
; y - addr of src bin value (two bytes)
; x - addr of dest BCD buffer (3 bytes for 65535)
binToBcd:
pshu x ; save dest BCD prt for later
;clear BCD buffer
clr b2bcd_BCD+0
clr b2bcd_BCD+1
clr b2bcd_BCD+2
; copy bin to working mem
lda 0,y
sta b2bcd_BIN ; HI byte
lda 1,y
sta b2bcd_BIN+1 ; LO byte
ldb #16 ; 16 bits to scroll
.nextBit
pshu b
; first << on bin LO
lsl b2bcd_BIN+1
; rest via C marker, do << x 4
rol b2bcd_BIN+0
rol b2bcd_BCD+2
rol b2bcd_BCD+1
rol b2bcd_BCD+0
; mem rotated, do correction if != last bit
cmpb #1
beq .skipLastCorrection
ldb #3
ldx #b2bcd_BCD
jsr binToBcdCorrect
.skipLastCorrection:
pulu b
decb
bne .nextBit
;copy result from working var
pulu x ; get original BCD bag
lda b2bcd_BCD+0
sta 0,x
lda b2bcd_BCD+1
sta 1,x
lda b2bcd_BCD+2
sta 2,x
rts
;
Cały programik mój taki teraz jest i to jest wersja rozwojowa, ale ma mocne znamiona działania: https://github.com/bienata/monoboard9/b ... -bcd-1.asm , a tu filmik:
https://youtu.be/4SfIPrHLkAE
Wizualnym efektem może nie wyrywa z majtek, ot kolejne liczydełko ale to sporo do przodu dla mnie mieć konwersję na dziesiętny system, w sumie to przełom pewien. No, a dodawanie dłuższych ciągów BCD to sobie zrobię na podstawie czegoś takiego zapewne: https://www.electrical4u.com/bcd-or-bin ... btraction/ ale to dopiero przy następnym ataku weny twórczej....
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
tasza pisze:Mam dystans do siebie i na szyderę w sumie jestem dość odporna więc proszę, można używać:
Używać będą jedynie osobniki maluczkie. Inni będą zadowoleni, tak po prostu, jeżeli ktoś czyni wysiłki, by pokonywać kolejne horyzonty.
Prawdziwe słowa nie są przyjemne. Przyjemne słowa nie są prawdziwe.
Lao Tse
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
No więc właśnie, cykliczność czynności deburdelizacyjnych w kabelkach wydaje się jednak koniecznością, porządki co jakiś czas robić trzeba, zatem poletko zostało zdemontowane i robimy nowa wystawkę.
Po pierwsze sposób mocowania LM35 na grzbiecie Księżniczki Motoroli. Gumki-plecionki jednak pokruszyły się, obstawiam, że jednak blisko 60`C im nie posłużyło. Inny patent zatem - szpilą w formie dźwigienki czujnik dociskam przez termoprzewodzący glutek do procesora, po drugiej stronie ścianki systemowej, inna grubsza już recepturka nagina szpilę dociskając czujnik. No trzeba sobie radzić.
Demolka po całości, głównie w związku z eliminacją baterii pomniejszającej -5V dla RS232 oraz wymianą przetwornika A/C.
Udało się zdobyć kilka izolowanych przetworniczek DC-DC 5V/12V, whoaa!
Taka kosteczka umieszczona gdzieś z boku złącz pozwoli uwolnić się od bateryjnych podpórek.
Finalnie ułożyłam ją obok zacisków ARK, zasilana jest z kanału -5V robiąc -12V, czyli wisi do góry nogami, po prostu nie chciałam już dociążać toru +5V, ponieważ na nim i tak wisi całość instalacji, a sporo tego jak wiadomo.
Ogarnięta grządka temperaturowa, grzebyki łączące LM35 z CPU, MCP9700 z parapetu oraz lokalny LM35. Potem w tejże okolicy pojawi się 2.5V źródełko referencyjne na LT431, ale to za chwilę.
Dużo mnóstwo kanałów, bitów jednak mniej - ADC0816
Bohaterem dzisiejszego odcinka zostaje przywleczony z ostatniej Wolumenowej wyprawy przetwornik analogowo-cyfrowy typu ADC0816.
Dokumentacja firmowa tutaj:
http://www.ti.com/lit/ds/symlink/adc0816.pdf
http://www.ti.com/lit/an/snoa596/snoa596.pdf
Detale do doczytania w wolnej chwili, a ja tylko zaznaczę, że przy Uref=5V na jeden bit zmiany wyniku przypada 5/256V czyli około ΔV=19.5mV Przez tyle mnożymy wynik z wyjść konwertera aby określić zapodane mu napięcie wejściowe. Jak widać w konfrontacji z LM35, które ma 10mV/`C tak mała rozdzielczość wprowadza dramatyczne wręcz przekłamania, ale szczerze mówiąc nie miałam już siły dziś dokładać wzmacniacza, może później. W dokumentacji piszą wprawdzie o możliwości korzystania z Uref o małych wartościach, ale to przy rezystancyjnych zadajnikach napięcia wejściowego, zapiętych pomiędzy +/-Uref, wycyrklowane na połowę zasilania, symetrycznie. A u mnie wszystko jest względem masy więc albo błędy albo wzmacniaczyk, tu się nie da zrobić na szybko fotomontażu.
Schemat nowej zabawki poniżej:
Przetwornik nasz wymaga zewnętrznego sygnału zegarowego na poziomie ~100kHz, zatem na bazie NE555 pierwszy element nowego pajęczaka - generatorek.
Tuning fosc przy pomocy AD2 i pudełka z kondensatorkami...
Potem reszta układu, zgodnie (mniej więcej) ze schematem.
No i pierwsze przymiarki do sofciku, mocno na motywach poprzednich programików, stąd koślawa zawartość wyświetlacza, póki co.
O i tu zachwostka była do czasu uporządkowania kodu:
No, który odczyt jest w którego układu? Za oknem deczko ponad 5`C więc MCP9700 daje pięćset-parę mV, czujnik na procesorze w okolicach 55`C czyli też pięćset-coś-tam - odczyty: 0x1B i 0x1F...
Drobna zmiana zawartość wyświetlacza, to moje 2.5V nazywa się teraz Uref, bo tak. No i odczyty szesnastkowe z kolejnych sensorów: 0x1A * 19.5mV - 500mV = 7mV czyli dla MCP9700 pomiędzy 0..1'C. Potem kolejno 60`C na pleckach Motki oraz jakieś 21`C w pokoju.
O, a tu z boczku wystaje LT431, z niego te testowe napięcie sobie mierzę, w sumie jedyne co mi się zgadza...
Heh, no smuteczek się pojawia od czasu do czasu właśnie taki. Pisałam przy okazji produkcji płytki-przelotki do złącza MB09, że dokładnie lutować trzeba ponieważ poprawki będą co najmniej niemiłe. No i chyba mnie patrol po lutowankach moich czeka, bo któryś z pinów grzebyka gold-pin ewidentnie nie styka. Na wyświetlaczu VFD widac to dość paskudnie, jak zniknie któryś z bicików danych - display pisze do mnie po chińsku. To muszę ogarnąć w miarę szybko, bo w sumie to nie wiadomo, czy procedurka do VFD poszła nagle w buraki, czy to problem styków, dość niemiła sprawa.
Z ukrycia wypełzł był Analog Discovery 2 i po podłączeniu wszelkich rurek i przewodów zaraz nam się bardzo przyda.
Ostatnia jeszcze fotka, to rzut okna na wyświetlacz, na którym wartości z przetwornika są już przeliczone na dziesiętnie przez wypracowaną ostatnio procedurkę konwertującą, super!
Fotka powyżej to sprawka programiku https://github.com/bienata/monoboard9/b ... -mux-1.asm z którego najciekawsza wydaje się być procedurka getADC, ale uszyta na miarę pod nowy przetwornik A/C typu ADC0816:
adc0816-mux-1.asm pisze:Kod: Zaznacz cały
getADC:
; mux: ALE = VIA1.PB4
; ADD_B = PB.1
; ADD_A = PB.0
;
; adc: D7..D0 - VIA1.PA7..PA0
; START = VIA1.PB7
; set channel
anda #%0000.0011
sta VIA1+ORB
; ALE + START
lda #%1001.0000
ora VIA1+ORB
sta VIA1+ORB
nop
lda #%0110.1111
anda VIA1+ORB
sta VIA1+ORB
; wait a moment
ldb #$80
.omg: decb
bne .omg
; read data
lda #$00
ldb VIA1+IRA
rts
I tu mamy tak: kanał pomiarowy wybieramy sterując odpowiednimi bitami adresowymi multipleksera wbudowanego w przetwornik, ja korzystam z czterech kanałów, stąd angażowane są jeno dwa bity. Adres zatrzaskiwany jest opadającym zboczem sygnału ALE. Konwersję wyzwala dla odmiany opadające zbocze sygnału START, z lektury datasheet wywnioskowałam, że można te dwie rzeczy zrobić na raz.
Tak więc po wybraniu kanału przetwornik dostaje sygnał startu, ja czekam w małej pętelce aż się wykokosi z konwersją i potem zbierany jest ośmiobitowy wynik. Dla kompatybilności z resztą dzierganiny wynik wyprowadzam z procedurki via rejstr D (para A+B), tylko z wyzerowanym starszym bajtem. Można ewentualnie obserwować sygnał EOC (end of conversion), albo najlepiej wpleść go w system przerwań IRQ, wtedy będzie jakby optymalizacja wykorzystania czasu CPU.
No, tu zadowolona jestem ponieważ obczaiłam fajną sprawę w WaveForms - przebiegi analogowe na oscylku można obserwować wespół z cyfrowymi, ale w tym samym kontekście, czyli na wspólnej osi czasu, zajeprzydatny patent moim zdaniem. Ja sobie zrobiłam tak, że kanał analogowy synchronizowany jest opadającym zboczem sygnału cyfrowego ALE, który robi wtenczas za trigger i dla oscyla i dla cyfrowych kanałów analizatora logicznego. A przy okazji bity adresowe ADD_A, ADD_B pokazuje sobie w formie numerycznej wyliczonej z wag bitów (kanał BUS), ale mega!
Niestety jak się dobrze przyjrzeć cukiereczkom (przebiegom czasowym), to nie do końca wyglądają one tak jak piszą mi w dokumentacji. No cóż, może coś jednak źle ustawiłam w AD2, a może to specyfika tej właśnie kostki, obrazek jest z dokumentacji Texas Instruments, a mój egzemplarz AD0816 jest od Intersil bodajże, ten układ robiło poresztą paru producentów, możliwe że ktoś coś usprawnił w międzyczasie, nie wiem, ale grunt że działa.
Na koniec ciekawostka - nałożone na resztę sygnałów takty przebiegu zegarowego dla przetwornika.
Zamiast liczyć owce i barany do spania, można sobie teraz policzyć ile cykli zegarowych zajmuje konwersja, czyli od zbocza do zbocza sygnału EOC...
To dobranoc.
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
[6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia
♫ ♩ ♪ Airbag ⚡ ☘ ⚡ All Rights Removed ♪ ♩ ♫
https://youtu.be/ObS_DB27Un0
Smutny los celebrytki, której nagle zgasili jupitery i zabrali mikrofon, oj jak strasznie. Gorzej, konkurencja z nagła się wylęgła. Ten CA80 jakiś, toć to kupa śmiechu i drutu, a wątpliwego pochodzenia przybłędy Meratronikowe zabrały całe show! I jak tu dalej żyć pytam, jak się ma takie parcie na szkło? Myślę, że rozwiązaniem dobrym będzie kolorowy melanż Cukierka-Rigola i Księżniczki Motoroli, będzie to także dobry pretekst do kontynuacji opowiastki. No to lecimy.
Ceramika
Za poradą drzewiej przeczytaną przetwornik AD558 powędrował do schowka skarbów, następca już nie tak egzotyczny, ale równie ciekawy DAC0808 http://www.ti.com/lit/ds/symlink/dac0808.pdf i w obudowie ceramicznej CDIP16, wiec do retorklimatów pasuje doskonale.
Kostka nie jest zbyt kłopotliwa w użyciu, aczkolwiek wystąpiła konieczność dostarczenia ujemnego napięcia. Motka aktualnie dostaje prąd z zasilacza od CA80, tam też dostępne jest -5V tak więc problem z głowy. No i na liniowo (7905) a nie jakieś ziejące szpilkami przetwornice.
Rozdwojenie jaźni
Skoro mamy dwie kostki DAC to aż wię prosi do zapięcie ich do portów VIA i poeksperymentowanie, co ciekawego można na oscyloskopie obejrzeć, poza kreską oczywiście, a najlepiej w trybie X-Y. Zatem schemat ideowy takowy powstał:
I kolejno, etapami budowa, na koniec test czy w ogóle DAC mi ruszy.
Kawalątek kodu w assemberze - ot, inkrementacja zawartości portu, czyli docelowo ma się narysować przebieg piłokształtny.
Kod: Zaznacz cały
lda #0
sta VIA1+ORA
tu:
inc VIA1+ORA
jmp tu
No i tu dała o sobie znać zła aura Motoroli zazdrośnicy - przebieg od czapki wyszedł, heh.
Ten ząbek powyżej, po którym DAC wchodzi w jakby nasycenie to wizualny efekt załączania się kluczy na najstarszych bitach DAC-a ale przy zbyt wielkim napięciu referencyjnym, po prostu zapięłam się testowo do Vcc. I klops. Szybka poprawka ze znanym i lubianym LM385 w wersji 2.5V uratowała sytuację.
Cudnie wyszczerzone zęby Cukierka, a koleżanka Motka urzeczona zadbanym zgryzem przestaje się foszyć, znaczy się - idzie ku dobremu.
Dalsze eksperymenty wymagały szybkiego przeniesienia się na większą płytkę stykową, do Motki i tak wiącha przewodów spora idzie, trzeba sobie zapewnić minimalny choć komfort w przekładankach.
Oczywiście kolorowe efekty specjalne, to sianie złapane przez luzem wiszące kabelki na aktywnych kanałach CH1 i CH2..
W miarę działające poletko z dual-DAC, zaczynamy grać w stereo.
Piłokształtna wystawka taka oto na koniec:
A taki prosty programik potrafi wygenerować dwie piły, ale przesunięte w fazie:
Kod: Zaznacz cały
lda #80
sta VIA1+ORA
sta VIA1+ORB
tu:
inc VIA1+ORA
dec VIA1+ORB
jmp tu
Potem czas na węże, czyli generujemy sinsua, skorzystałam z przydasia waves.inc https://github.com/bienata/monoboard9/b ... /waves.inc , który zawiera definicje sinusoidy poszatkowaną na 256 próbek, programik do sinusowania taki oto:
Kod: Zaznacz cały
ldx #SINE_WAVE_256
ldy #SINE_WAVE_256
tu:
lda ,x+
sta VIA1+ORA
lda ,y+
sta VIA1+ORB
cmpx #SINE_WAVE_256+$FF
bne xInRange
ldx #SINE_WAVE_256
xInRange:
cmpy #SINE_WAVE_256+$FF
bne yInRange
ldy #SINE_WAVE_256
yInRange:
jmp tu
Jak widać, wskaźniki X i Y sa inicjowane tą samą wartością, oba przebiegi będą zgodne w fazie, oczywiście z dokładnością do czasu potrzebnego na wstawienie próbki do drugiego DAC-a.
Na okazję prezentacji Mini 4 wspominałam, że oscyloskop służy głównie do zabawy w figury Lissajous, a zatem garść testów z trybem X-Y Cukierka, któremu przebiegi podkłada pracowita Motka:
Przebiegi zgodne w fazie, czyli krecha pod górę, kat nachylenia 45% przy założeniu równych podziałek V/div
The Ring
I wystarczy zmiana przesunięcia fazowego na 90° - programik prawie identyczny, tylko jeden drobiażdżek:
Kod: Zaznacz cały
ldx #SINE_WAVE_256
ldy #SINE_WAVE_256+$40
tu:
lda ,x+
sta VIA1+ORA
lda ,y+
sta VIA1+ORB
cmpx #SINE_WAVE_256+$FF
bne xInRange
ldx #SINE_WAVE_256
xInRange:
cmpy #SINE_WAVE_256+$FF
bne yInRange
ldy #SINE_WAVE_256
yInRange:
jmp tu
Widać, że wskaźnik Y jest inicjowany w 1/4 tabelki, cała definicja sinusa ($FF sampli) pokrywa 360', zatem $40 ustawi nas gdzieś na 90°. Potem inkrementacja wskaźników leci jednocześnie - mamy stałe przesunięcie i kółko, ale czad!!!
Oczywiście były tez nieudokumentowane, spontaniczne eksperymenty z wartością sample zaraz przed wstawieniem do DAC, a to logiczny shift o perę bitów, a to jakieś odejmowanie, cudować tu można autentycznie bez końca.
Kod: Zaznacz cały
lda ,x+
sta VIA1+ORA
suba #10
sta VIA1+ORA
lda ,y+
sta VIA1+ORB
suba #10
sta VIA1+ORB
Na płasko wygląda to równie oryginalnie:
Jeszcze raz kółko, ale dla różnych parametrów próbkowania, szczególnie ilości sampli do uśredniania i długości bufora
Ooooo, kursory w trybie X-Y..?! No proszę, temat rzeka znaczy się będzie.
I `O` bardziej na żywo:
https://youtu.be/MTsQIOj9ymg
Kolorowych snów
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)
Kto jest online
Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 3 gości