[6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Kącik dla elektroniki retro - układy, urządzenia, podzespoły, literatura itp.
Awatar użytkownika
gaweł
Geek
Geek
Posty: 1259
Rejestracja: wtorek 24 sty 2017, 22:05
Lokalizacja: Białystok

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: gaweł » piątek 24 lis 2017, 23:10

Po prostu cudo.

Prawdziwe słowa nie są przyjemne. Przyjemne słowa nie są prawdziwe.
Lao Tse

Awatar użytkownika
dambo
Expert
Expert
Posty: 645
Rejestracja: czwartek 17 mar 2016, 17:12

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: dambo » piątek 24 lis 2017, 23:54

To ja tak dodam od siebie, że cały wątek śledzę od samego początku i jestem pod ogromnym wrażeniem :) Tak trzymać! Jestem mega ciekaw co dalej z tego wyjdzie :)
Nowy blog o tematyce embedded -> https://www.embedownik.pl/

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » niedziela 26 lis 2017, 22:03

w nawiązaniu do kabelków...

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

Oczywiście pstrokate zakończenia przewodów, aby się nie pogubić przy zapinaniu do płytki.

Obrazek

Test zadziałania całkiem ok.

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

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

Obrazek
Obrazek
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:
:arrow: https://github.com/bienata/monoboard9/b ... u20025.inc
i programik testowy, korzystający z tego (hahaha) drivera:
:arrow: 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...

Obrazek

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:
:arrow: 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...

Obrazek

Coś tam nabazgrałam i nawet działa, ale szpetne mi się wydaje, zatem tylko jako ciekawostkę wskazuje pliczek:
:arrow: 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.

Obrazek

Mysz na V640 już śpi a więc chyba wystarczy na dziś...
______________________________________________ ____ ___ __ _ _ _ _
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » wtorek 28 lis 2017, 20:59

Po krótkiej przerwie technicznej na radosne eksperymenty, zapraszam na kolejną Motkową dobranockę.

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:
:arrow: 6809 Assembly Language Programming (Lance Leventhal) (rozdział 15)
:arrow: http://www.roust-it.dk/coco/6809irq.pdf
:arrow: http://www.6502.org/tutorials/interrupts.html
:arrow: 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 :arrow: 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.

Obrazek
Ekg - czyli kolejne wywołania obsługi IRQ wraz z pobudzeniem

Obrazek
Tak przypisujemy poziomy napięć do faz wykonania.

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

Obrazek

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

Obrazek

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

Awatar użytkownika
gaweł
Geek
Geek
Posty: 1259
Rejestracja: wtorek 24 sty 2017, 22:05
Lokalizacja: Białystok

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: gaweł » środa 29 lis 2017, 17:13

tasza pisze:aaaale scerbate toto wysło...

Urocze :D

Prawdziwe słowa nie są przyjemne. Przyjemne słowa nie są prawdziwe.
Lao Tse

Awatar użytkownika
piotrek
User
User
Posty: 155
Rejestracja: niedziela 05 lis 2017, 02:46

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: piotrek » środa 29 lis 2017, 19:31

Fajny patent na podglądanie pracującego procesora. Można równie dobrze zastosować tutaj kilka rezystorów zamiast AD, żeby nie ryzykować jego uszkodzenia, a szkoda by była bo to prawdziwy rarytas.

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » środa 29 lis 2017, 23:21

Newsów z piaskownicy garść wieczorna...

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

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!
Obrazek

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:
:arrow: http://wiki.bash-hackers.org/scripting/terminalcodes
:arrow: 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

Obrazek

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

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
Obrazek
Obrazek
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ć)

Awatar użytkownika
gaweł
Geek
Geek
Posty: 1259
Rejestracja: wtorek 24 sty 2017, 22:05
Lokalizacja: Białystok

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: gaweł » czwartek 30 lis 2017, 12:47

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
IMG_6316.JPG

i w SMD
IMG_6318.JPG

Jeszcze zaplątało mi się parę kostek 6116
IMG_6317.JPG

O pamięciech 62256 to już nie będę wspominać, jest tego duuuużo.
Nie masz wymaganych uprawnień, aby zobaczyć pliki załączone do tego posta.

Prawdziwe słowa nie są przyjemne. Przyjemne słowa nie są prawdziwe.
Lao Tse

nixie
Newb
Newb
Posty: 32
Rejestracja: sobota 02 sty 2016, 20:20

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: nixie » czwartek 30 lis 2017, 15:38

Aż ślina cieknie jak się ogląda te cudeńka :)

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » czwartek 30 lis 2017, 23:44

Przerwania IRQ w 6809 - opowieści dziwnej treści v.2

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: :arrow: 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.
Obrazek

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 :arrow: 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:

Obrazek

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:

Obrazek

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?

Obrazek
Obrazek

Proszę, proszę, nawet 200Hz wyszło, ale po powiększeniu przebiegu - wygląda dość szpetnie, jak zepsute schody ruchome na Dworcu Centralnym w stolicy.

Obrazek

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:

Obrazek

Kolejno:

Obrazek
UM-111 na zakresie 3VAC pokazał 1.5V...

Obrazek
Cyfrowy poradził sobie doskonale.

Obrazek
Wojtkowy V640 z wciśniętą funkcją LF (m.cz.) - idealnie wręcz

Z UM-111 poszło gładko.

Obrazek
Nie miałam siły już szukać po pudełkach, zatem byle 10uF w szereg z UM aby DC przyciąć i...

Obrazek
... 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ć)

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » piątek 15 gru 2017, 22:02

digital light and magic

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: :arrow: 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.

Obrazek
Obrazek
Obrazek
Obrazek
Obrazek

Zbliżenie na jedną lampkę, widać cieniutkie żarniczki, które świecąc robią za segmenty wyświetlacza.

Obrazek
Obrazek
Obrazek

Obrazek

Odgięłam jedną lampkę dla zdjęcia i na tym koniec takich zabaw, to zbyt cenne, aby mi chrupło z nagła.

Obrazek
Łapki blaszane mocujące lampkę do płytki, w sumie to bardzo rozsądnie pomyślane.

Obrazek

Laminat od spodu, ładnie opisane tuszem kolejne wyprowadzenia, łatwo mi było robić notatki podczas identyfikacji który drucik do czego idzie.

Obrazek
Obrazek
Obrazek

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.

Obrazek
Obrazek
Obrazek

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

Obrazek
Obrazek

No i pomalutku rusza budowa części sterującej na ULN2804 i rejestrach CD4094.

Obrazek
Obrazek
Obrazek
Obrazek
Obrazek

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:

Obrazek

Obrazek
Na płytce stykowej może nieco strasznie wygląda, ale tam tak naprawdę nic nie ma, ot - kłębek drutu.

Obrazek
Obrazek

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

Obrazek
No i wieczorna nastrojowa wystawka.

Efekt działania programiku :arrow: https://github.com/bienata/monoboard9/b ... mple-1.asm
jest następujący:

Obrazek
Obrazek
Obrazek

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

Obrazek

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

Awatar użytkownika
dambo
Expert
Expert
Posty: 645
Rejestracja: czwartek 17 mar 2016, 17:12

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: dambo » piątek 15 gru 2017, 22:09

Piękne te lampy :)
Nowy blog o tematyce embedded -> https://www.embedownik.pl/

SuperGość
Uber Geek
Uber Geek
Posty: 2346
Rejestracja: piątek 04 wrz 2015, 09:03

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: SuperGość » sobota 16 gru 2017, 11:17

No właśnie bezwładność, jednym to przeszkadza ale mnie się podoba - lampki są wtedy takie jakby leniwe :D i mówią "...a niech tam mogę się zmieniać" :)
Ale no masz fart, z tym że robisz wszystko aby ten fart ci się przytrafił. Super robota :)

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » niedziela 17 gru 2017, 21:52

miska letniej owsianki

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.

Obrazek

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

:arrow: http://www.micropik.com/PDF/UA9637.pdf

oraz UA9636 nadajnik linii:

:arrow: http://pdf.datasheetcatalog.com/datashe ... 8781_1.pdf

Obrazek

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.

Obrazek
Obrazek

Metodą długopisowo-buzzerkową rozrysowałam sobie część nadawczo-odbiorczą
Obrazek

I wyszedł taki jak poniżej i mam nadzieje, że w miarę sensowny kawałek schematu.
Obrazek

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...
Obrazek
______________________________________________ ____ ___ __ _ _ _ _
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » czwartek 28 gru 2017, 15:28

zaziębieniomagedon

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 :roll:

Obrazek
O układzie MCP9700 dużo i dokładnie zostało napisane tu: :arrow: 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.

Obrazek
Do MCP lutujemy wiązkę, oraz pomiędzy VCC i GND niewielki kondensatorek, jakieś 10uF

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

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

Obrazek
Cała końcówka pomiarowa wygląda u mnie tak.

Obrazek
A tak w warunkach plenerowych, przyssana do parapetu.

Obrazek
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:
Obrazek

retrokonwersja analogowo-cyfrowa

Obrazek
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:
Obrazek
Obrazek
Obrazek
Obrazek

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: :arrow: 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:
Obrazek
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

Obrazek
Obrazek
Obrazek
Obrazek
Obrazek

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:
Obrazek
0xFFF = 4095, 4095 * 2.44mV = 9.99V

źródełko referencyjne LT431 w podstawowym układzie 2.5V
Obrazek
0x400 = 1024, 1024 * 2.44mV = ~2.50V (2.498)

MCP9700 za oknem:
Obrazek
0xE8 = 232, 232 * 2.44mV = 0.566V, (0.566-0.500)[V] / 0.01[V/`C] = 6.6`C

Bateria płaska:
Obrazek
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:

Obrazek

A fragment programu :arrow: 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.

Obrazek

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

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

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » poniedziałek 01 sty 2018, 22:37

gadała baba do obrazu

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:

Obrazek
Żeńskie złącze DIN 64 pin ze szrotu plus kawałek uniwersalki, co mi został z breakout-board.

Obrazek
Złącze oczyszczone z resztek drucików.

Obrazek
Przymiarka na sucho, jakby to mogło wyglądać, bardzo do takich ustawek przydaje mi się druga płytka MB09, wielkie to ułatwienie.

Obrazek
Przytrzymywaczka złącz ARK czyli ustawianie terminala do zasilania, dwa kolory, bo to i plus i minus będzie tam leciał.

Obrazek
Ooooo, no nie byłabym sobą - oldschoolowe ledziki na indykatory zasilania.

Od strony widowni póki co wygląda to chyba nieźle.
Obrazek
Obrazek
Obrazek
Obrazek

Ale nie drążmy zbytnio tematu...
Obrazek

Gotowa że tak ujmę - ścianka systemowa.
Obrazek
Obrazek

I chyba całkiem dobrze wtapia się w tło.
Obrazek

Aha, no i prosty kabelek do złącza DB9, tylko GND,TxD,RxD.

Obrazek

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!

Obrazek

Dało w sumie jakieś -9.5V co skutecznie odetkało tę szeregową niemotę i zaczęła gadać.

Obrazek
Wystawka z baterią wyglądała pokracznie, ale grunt że ruszyło.

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

Obrazek
Stan baterii w okolicach godziny 11 - mamy 4.2V

Obrazek
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?
Obrazek
Próba ze starą teczką z transparentnego tworzywa jest w miarę udana.

Obrazek
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:

Obrazek

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 :arrow: 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ć)

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » środa 03 sty 2018, 23:46

multitermometr heksadecymalny

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:
Obrazek

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

Obrazek
Obrazek
Obrazek

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.

Obrazek
Obrazek

Blaszany wzmacniaczyk LM741 już w układzie.
Obrazek

Potem dołożyłam multiplekser, uwaga: nieużywane wejścia analogowe - do masy!
Obrazek


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

Bo tak oto przy pomocy glutka z pasty termoprzewodzącej oraz zestawu gumek do plecenia (do nas też dotarła moda na to)...
Obrazek

można się łacno przymocować z czujnikiem na plecach Księżniczki Motorolki.
Obrazek
Obrazek

Jeszcze kilka ujęć z piaskownicy - z lotu muchy.
Obrazek

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

Ponownie blaszany LM741
Obrazek

I mux w gąszczu kabelków.
Obrazek

Po wymęczeniu programiku https://github.com/bienata/monoboard9/b ... -mux-1.asm w pierwszym podejściu tylko wyświetlałam wyniki pomiarów

Obrazek

Potem programik wzbogacony o dolną linię z opisem co jest co.
Obrazek

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

Awatar użytkownika
gaweł
Geek
Geek
Posty: 1259
Rejestracja: wtorek 24 sty 2017, 22:05
Lokalizacja: Białystok

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: gaweł » czwartek 04 sty 2018, 12:11

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

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » sobota 06 sty 2018, 20:27

architektura klient-serwer w krzywym zwierciadle

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 :arrow: 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:

Obrazek

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.

Obrazek

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:

Obrazek

No i w południe okazało się jak cieplutko jest na dworze, oto pomiar z MCP9700

Obrazek

Archiwum z programem na PC jest tu: :arrow: 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:

Obrazek

Mając jakoś tam opanowane wyliczanki (o tym dalej) zaczęła się zabawa z układaniem tego na ekranie VFD:

Obrazek

I na koniec wyszło tak, chyba całkiem, tak myślę....

Obrazek

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:

Obrazek
Obrazek

Oczywiście, na drugim końcu kabla Księżniczka Morotola pracowała na nowym oprogramowaniu: :arrow: 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

Obrazek

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

Awatar użytkownika
gaweł
Geek
Geek
Posty: 1259
Rejestracja: wtorek 24 sty 2017, 22:05
Lokalizacja: Białystok

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: gaweł » niedziela 07 sty 2018, 11:12

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

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » poniedziałek 08 sty 2018, 22:36

bajty, bity, nibble i tetrady

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ć:

Obrazek

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.

Obrazek

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: :arrow: 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ć)

Awatar użytkownika
gaweł
Geek
Geek
Posty: 1259
Rejestracja: wtorek 24 sty 2017, 22:05
Lokalizacja: Białystok

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: gaweł » wtorek 09 sty 2018, 14:31

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

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » piątek 12 sty 2018, 22:30

przebudowa piaskownicy

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

Obrazek
Obrazek

Demolka po całości, głównie w związku z eliminacją baterii pomniejszającej -5V dla RS232 oraz wymianą przetwornika A/C.

Obrazek

Udało się zdobyć kilka izolowanych przetworniczek DC-DC 5V/12V, whoaa!

Obrazek

Taka kosteczka umieszczona gdzieś z boku złącz pozwoli uwolnić się od bateryjnych podpórek.

Obrazek

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.

Obrazek
Obrazek

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.

Obrazek

Dokumentacja firmowa tutaj:
:arrow: http://www.ti.com/lit/ds/symlink/adc0816.pdf
:arrow: 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:

Obrazek

Przetwornik nasz wymaga zewnętrznego sygnału zegarowego na poziomie ~100kHz, zatem na bazie NE555 pierwszy element nowego pajęczaka - generatorek.

Obrazek

Tuning fosc przy pomocy AD2 i pudełka z kondensatorkami...
Obrazek

Potem reszta układu, zgodnie (mniej więcej) ze schematem.
Obrazek
Obrazek

No i pierwsze przymiarki do sofciku, mocno na motywach poprzednich programików, stąd koślawa zawartość wyświetlacza, póki co.
Obrazek

O i tu zachwostka była do czasu uporządkowania kodu:
Obrazek
Obrazek
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...

Obrazek

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.

Obrazek
O, a tu z boczku wystaje LT431, z niego te testowe napięcie sobie mierzę, w sumie jedyne co mi się zgadza...

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

Obrazek
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!
Obrazek

Fotka powyżej to sprawka programiku :arrow: 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.

Obrazek
Obrazek

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!

Obrazek
Obrazek
Obrazek

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.

Obrazek

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

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » niedziela 14 sty 2018, 14:02

Dygresja okolicznościowa w tak zwanym międzyczasie.

Obrazek
Obrazek
______________________________________________ ____ ___ __ _ _ _ _
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

[6809] "10099-MBC9 MONOBOARDCOMPUTER 6809" - wiedźmy dłubanie nad uruchomieniem starocia

Postautor: tasza » niedziela 04 mar 2018, 23:30

♬ ☘ Moja muzyka do kodowania ♬ ♬ ♬ ☘
♫ ♩ ♪ 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 :arrow: http://www.ti.com/lit/ds/symlink/dac0808.pdf i w obudowie ceramicznej CDIP16, wiec do retorklimatów pasuje doskonale.

Obrazek

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ł:

Obrazek

I kolejno, etapami budowa, na koniec test czy w ogóle DAC mi ruszy.

Obrazek
Obrazek

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.

Obrazek
Obrazek

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

Obrazek
Obrazek

Cudnie wyszczerzone zęby Cukierka, a koleżanka Motka urzeczona zadbanym zgryzem przestaje się foszyć, znaczy się - idzie ku dobremu.

Obrazek
Obrazek

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.

Obrazek
Obrazek

Oczywiście kolorowe efekty specjalne, to sianie złapane przez luzem wiszące kabelki na aktywnych kanałach CH1 i CH2..

Obrazek

W miarę działające poletko z dual-DAC, zaczynamy grać w stereo.
Obrazek

Piłokształtna wystawka taka oto na koniec:
Obrazek
Obrazek

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


Obrazek

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.

Obrazek
Obrazek

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

Obrazek
Obrazek

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!!!

Obrazek
Obrazek

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


Obrazek
Obrazek

Na płasko wygląda to równie oryginalnie:

Obrazek
Obrazek

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

Obrazek
Obrazek
Obrazek

Ooooo, kursory w trybie X-Y..?! No proszę, temat rzeka znaczy się będzie.

Obrazek

I `O` bardziej na żywo:
https://youtu.be/MTsQIOj9ymg

Kolorowych snów

Obrazek
Obrazek
______________________________________________ ____ ___ __ _ _ _ _
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)


Wróć do „Retro”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 15 gości