Cyfrowy tester/charakterograf lamp

[Jasiu]

Jasiu co do procka to może jakaś motorola np. z seri 68hc8xx ma w sobie przetworniki A/C , sporo portów i jest tania. Albo jakaś programowana struktura logiczna np. typu GAL cz też PLD lub FPGA troche tego popełniłem. Oczywiście kieruje się względną prostotą i taniością podzespołow.

Witam ponownie.
To co prawda nie do mnie było, ale chciałbym zwrócić uwagę na procki firmy Analog Devices. ( ADuC814,ADuC824 itd) Mają parę sympatycznych cech:
-8051 core
-programowanie przez rs232 ( nie trzeba programatora )
-porządne przetworniki (824 AD 16+24b + DA 12b)
Pozdrowienia.

Podobne cechy mają kostki robione przez Texas Instruments MSC12XX. Niestety mają małe obudowy, w warunkach amatorskich trochę uciążliwe (kostki AD) zresztą też.

IMO mikrokontrolery są jednak elastyczniejsze i przyjemniejsze w modyfikowaniu od programowanej logiki, szczególnie jeżeli zadba się o strukturalność oprogramowania.

Nie brzydził bym się składania całości z osobnych kostek procesora i przetworników, (szczególnie DIP). Wepchnięcie wszystkiego do jednej kostki w warunkach "nieprodukcyjnych" nie jest znowu tak cenną zaletą.

Pozdrawiam,
Jasiu

[Jasiu]

Mikrokontroler z RSem w ogóle będzie prostszy - są do tego gotowe kostki obsługa programowa sprowadza się do pisania i czaytania pojedyńczych bajtów danych. Z USB tak miło nie było (chyba, że coś się zmieniło - interesowałem się tym nakiś czas temu)

O USB "dżwiękowym" pisałem w kontekście układu stacjonarnego, pracującego wyłącznie z komputerem. Wtedy uC wcale nie jest potrzebny, bo z jednej strony masz gotowy driver dźwiękowy, a z drugiej wejścia i wyjścia przetworników. Prostota bezkonkurencyjna, ale brak autonomiczności.

Jasiu

[tszczesn]

Jasiu co do procka to może jakaś motorola np. z seri 68hc8xx ma w sobie przetworniki A/C , sporo portów i jest tania. Albo jakaś programowana struktura logiczna np. typu GAL cz też PLD lub FPGA troche tego popełniłem. Oczywiście kieruje się względną prostotą i taniością podzespołow.

Ja akurat myślałem o Z80, bo go bardzo lubię (a swego czasu większość kodów asemblera znałem na pamięć, mogłem robić za ręczny kompilator :). Wsadzanie tego w jakiś PLD jest IMO bezsensowne - utrudni późniejsze naprawy, a i dostępność części zamiennych będzie gorsza.
I tutaj będą potrzebne przetworniki A/C i C/A, choć A/C więcej.

[tszczesn]

IMO mikrokontrolery są jednak elastyczniejsze i przyjemniejsze w modyfikowaniu od programowanej logiki, szczególnie jeżeli zadba się o strukturalność oprogramowania.

Owszem, mam takie same zdanie :)

Nie brzydził bym się składania całości z osobnych kostek procesora i przetworników, (szczególnie DIP). Wepchnięcie wszystkiego do jednej kostki w warunkach "nieprodukcyjnych" nie jest znowu tak cenną zaletą.

Przy małej skali priodukcji też. W pracy mam okazję naprawiać bardzo profesjonalny sprzęt i te trochę starsze układy rozbione na 'normalnych' częściach są naprawialne bez większego problemu, z późniejszymi - nic już nie mogę srobić, nawet nie dołączana jest żadna dokumentacja techniczna.
Za to nam używanie typowyczh części ułatwi konstrukcję - elementy są łatwo dostępne, oraz ewentualne naprawy. Podejrzewam, że Z80 czy 8751 można będzie za dziesięć lat bez problemu kupić w odróżnieniu od 'udziwnionych wynalazków' TI czy AD.

[Jasiu]

A tam trudno. Diody i tranzystory są tanie mogą być np. trzy odczepy - 150V 300V i 500V, trzy prostowniki, trzy tranzystory wykonawcze, ale tylko jeden dostaje sterowanie. Robiłem takie układy (co prawda na niższe napięcia) i świetnie działały.

Wcale nie pisałem, że trudno, ale że upierdliwie. W końcu to i trzy razy więcej radiatorów, i trzy razy większa skrzynia... Sterowany prostownika na tyrystorach jest IMO zdecydowanie bardziej elegancki.Tyle, że pewnie bardziej skomplikowany.

Choć jak o tym piszę, to myślę sobie, że ze i tak względu na wysokie napięcie trzeba będzie połączyć tranzystory mocy szeregowo (przynajmniej bipolarne). W przeciwnym razie przy dużym napięciu, nawet gdy spadek na regulatorze szeregowym będzie niewielki, chwilowe zwarcie w lampie z dużym prawdopodobieństwem wykończy tranzystor (praktycznie bez względu na zabezpieczenia).

Może wtedy wystarczy parę diodek i automatyczne przełączanie napięcia wejściowego wyjdzie jakoś bez bólu, trzeba by pokombinować... Ej, pewnie masz rację

Tylko tu mimo wszystko bym z przyczyn bezpieczeństwa zrobił transformatorową przetwornicę impulsową - ona po uszkodzeniu na wyjściu da zawsze 0V - trudno przy awarii urządzenia spalić żarzenie lampie, co w przypadku cennych lamp (np. RE 11) jest bardzo istotne.

Przetwornica nie musi być izolować we od wy, może być zwykły stabilizator impulsowy z dławikiem (choć ten przy "zwarciu się" przełącznika da maksymalne napięcie...). Co prawda nie wiem jak pracował by przy 6.3 V na wyjściu, a ponad 100 na wejściu. Nigdy czegoś takiego nie próbowałem...

Myślałem, że w wersji stacjonarnej do żarzenia transformator z odczepami wystarczy... W końcu to bezpiecznie, bo nie ma się co zepsuć, a jak się mimo wszystko zepsuje, to napiecie też spada do zera.


Jasiu

[tszczesn]

O USB "dżwiękowym" pisałem w kontekście układu stacjonarnego, pracującego wyłącznie z komputerem. Wtedy uC wcale nie jest potrzebny, bo z jednej strony masz gotowy driver dźwiękowy, a z drugiej wejścia i wyjścia przetworników. Prostota bezkonkurencyjna, ale brak autonomiczności.

Normalny układ dźwiękowy USB ma dwa kanały w każdą stronę - to trochę mało.

[Jasiu]

Jasiu co do procka to może jakaś motorola np. z seri 68hc8xx ma w sobie przetworniki A/C , sporo portów i jest tania. Albo jakaś programowana struktura logiczna np. typu GAL cz też PLD lub FPGA troche tego popełniłem. Oczywiście kieruje się względną prostotą i taniością podzespołow.

Ja akurat myślałem o Z80, bo go bardzo lubię (a swego czasu większość kodów asemblera znałem na pamięć, mogłem robić za ręczny kompilator . Wsadzanie tego w jakiś PLD jest IMO bezsensowne - utrudni późniejsze naprawy, a i dostępność części zamiennych będzie gorsza.
I tutaj będą potrzebne przetworniki A/C i C/A, choć A/C więcej.

Jeżeli będziesz nalegał, Z80 zaakceptuję z przyjemnością. Co więcej, zrobię (praktycznie mam) do tego BIOSa na RAM i ROM dysk, puścimy sobie CP/M i będziemy mieli nie tylko Pascala Turbo, ale nawet Fortran (mogę nawt przyłączyć jakieś floppy).

Jasiu

[tszczesn]

Jeżeli będziesz nalegał, Z80 zaakceptuję z przyjemnością. Co więcej, zrobię (praktycznie mam) do tego BIOSa na RAM i ROM dysk, puścimy sobie CP/M i będziemy mieli nie tylko Pascala Turbo, ale nawet Fortran (mogę nawt przyłączyć jakieś floppy). :D

Nie upieram się przy Z80, choć go bardzo lubię, ale wolałbym jakiś typowy procesor. Tak naprawdę myślałem o 8088, bo potrafi zaadresowac do 1MB pamięci, a bazę danych punktów pracy trzeba gdzieś trzymać. A po co się bawić w bankowanie jak można użyć procesor który to sam potrafi robić?
A tak na razie skupmy się na trudniejszych elementach kosntrukcji - wykonawczych. Projektowanie cyfrówki zostawmy sobie na deser, bo to tylko sama przyjemność.

BTW. Jedynym słusznym językiem jest assembler i C (bez żadnych paskudnych plusów na końcu) ;)

[silicon]

Ja akurat myślałem o Z80, bo go bardzo lubię (a swego czasu większość kodów asemblera znałem na pamięć, mogłem robić za ręczny kompilator . Wsadzanie tego w jakiś PLD jest IMO bezsensowne - utrudni późniejsze naprawy, a i dostępność części zamiennych będzie gorsza.
I tutaj będą potrzebne przetworniki A/C i C/A, choć A/C więcej.

Tu się mylisz.
Dlaczego PLD jest bezsensowne i dlaczego ma utrudnić późniejsze naprawy ? .Z dostępnością niejest problem.A naprawa? nierozumiem...
Jest to układ programowalny podobnie jak Eprom który musisz podłączyć do Z80 a swoją drogą Z80 to relikt i niepotrzebnie skomlikuje to układ.Już bardziej proponuje serie 68hc ze swoimi przetwornikami,portami,epromem ,eepromem a nawet fleszem w środku taki "łosz end goł" motoroli , chyba że chcemy robić z tego doktorat to możemy zrobić to na bramkach ale to przerost formy nad wyobraźnią.
Wydaje mi się że o prostotę układu tu chodzi nonie?

[tszczesn]

Ja akurat myślałem o Z80, bo go bardzo lubię (a swego czasu większość kodów asemblera znałem na pamięć, mogłem robić za ręczny kompilator :). Wsadzanie tego w jakiś PLD jest IMO bezsensowne - utrudni późniejsze naprawy, a i dostępność części zamiennych będzie gorsza.
I tutaj będą potrzebne przetworniki A/C i C/A, choć A/C więcej.

Tu się mylisz.
Dlaczego PLD jest bezsensowne i dlaczego ma utrudnić późniejsze naprawy ? .Z dostępnością niejest problem.A naprawa? nierozumiem...
Jest to układ programowalny podobnie jak Eprom który musisz podłączyć do Z80 a swoją drogą Z80 to relikt i niepotrzebnie skomlikuje to układ.Już bardziej proponuje serie 68hc ze swoimi przetwornikami,portami,epromem ,eepromem a nawet fleszem w środku taki "łosz end goł" motoroli , chyba że chcemy robić z tego doktorat to możemy zrobić to na bramkach ale to przerost formy nad wyobraźnią.

Utrudni ewentualne późniejsze naprawy (z naciskiem na ewetualne!!!), bo nie jest to układ typowy, czyli trudniej zdiagnozować błąd, ponadta każdy PLD pomijając typowe GALe jest znacznie mniej popularny od typowego procesora. Po prostu tego jest tak dużo, że za kilka lat jak nie daj Boże będzie konieczność wymiany może być poważny problem z zakupem. Do tego Srodowiska projektowe/uruchomieniowe nie są chyba za darmo? Eprom czy 8751 również jest znacznie łatwiej zaprogramować. Pamiętaj, że nie jest to wielkoseryjna produkcja przemysłowa, ale domowy układ, który musi być wykonany z prostych i dostępnych części. To wszystko oczywiście IMO.

A co do Z80 - nie upieram się przy tym, to był tylko przykład. Po prostu ja preferuję typowy układ (może być Mototroli), nawet jak oznacza to dołożenie jeszcze jednego typowego układu.

Wydaje mi się że o prostotę układu tu chodzi nonie?

Owszem, oraz o prostotę wykonania i ewentualnego serwisu. Ja jako osoba również naprawiająca elektronikę i o tym staram się myśleć. Po prostu 'supernowoczesność' nie jest wartością samą w sobie.

[silicon]

Nie o super nowoczesność mi chodzi tylko o stopień skomplikowania układu ale nie będę się upierał w końcu czy to ważne czy na PLD czy na jakimś procku to się zrobi .Tylko jak już używać procesora to zważ że bez przetworników A/D się raczej nie obędzie .A ja tylko chcę je wykorzystać wewnątrz procesora no bo po co kupować procesor do którego trzeba dokupić pamięć i w/w przetworniki a na koniec i tak trzeba go oprogramować prawda.
Czy źle rozumuje.

[Jasiu]

Czołem.

Tu się mylisz.
Dlaczego PLD jest bezsensowne i dlaczego ma utrudnić późniejsze naprawy ?

Też myślę, że jest bezsensowne. Bazy danych na nim nie zrobisz, nawet malutkiej. Do programowania potrzebujesz hardware'u, a uC zrobimy pewnie w ten sposób, że zaprogramuje się z komputra prostym kabelkiem. Program napisany w C (a nawet assemblerze) można napisać tak, by można go było sobie przystosować do potrzeb.
Programowanie PLD jest duzo mniej popularne od pisania w C, mniej ludzi z tego skorzysta.Program uruchamiać można na emulatorach za parę złotych. Czy są takie do PLD? Komunikacja z PC-tem powinna odbywać się jakimś porządnym protokołem, czytelnym dla człowieka. To znakomicie ułatwia życie. Zrobisz na PLD rozpoznawanie komend z RSa typu S2=102.3? Warto, by kontroler miał możliwość wpisania stałych kalibracyjnych "dopalacza", jakieś limity mocy i co jeszcze przyjdzie do głowy w jakiegoś eeroma.

Jest to układ programowalny podobnie jak Eprom który musisz podłączyć do Z80 a swoją drogą Z80 to relikt i niepotrzebnie skomlikuje to układ.

Wziąłeś tak zupełnie serio tego Z80 Propozycję postawienia systemu operacyjnego CP/M też

BTW, jeżeli Z80 drażni Cię patyną, to może jakiś 64180 Toshiby? Trochę nowszy, adresuje megabajty, a ma architekturę Z80 i wbudowaną kupę różnego śmiecia. CP/M też na nim pójdzie...

Wydaje mi się że o prostotę układu tu chodzi nonie?

O prostotę, ale przy dosyć dużej funkcjonalności. IMO PLT tego nie daje.

Proponuję na przykład tak:

- AT89LS8252 (chyba ma flasha, ISP i eeprom) + klawiatura numeryczna 16 klawiszy, LCD 2*16

- A/D w zasadzie wystarcza 14 bitów (bo by większa rozdzielczość miała sens trzeba by zrobić niepotrzebnie drogą i precyzyjną część analogową, a do pomiarów charakterystyk lamp rozdzielczość 10uA wystarczy). Dwa kanały do pomiaru prądów separowane wzmacniaczami ISO122., zasilane na przykład DCP021212 (czy jak to się nazywa - taki mały przetwornik DC/DC Texasa), dwa kanały bez separacji. Poszukam jakiejś podchodzącej i nie za drogiej kostki przetwornika (DIP )

-D/A cztery kanały z wyjściem napięciowym. W zasadzie chyba wystarcza 12 bitów, ale na wszelki wypadek może lepiej 14.

To jak robić? Na przekór Tomkowi nie uważam, by były tu jakiekolwiek poważne trudności, ani w części analogowej, ani cyfrowej. Po prostu robota do zrobienia, całkiem niestety duża.

Czy może macie inne sugestie?

Jasiu

[tek-no-logical]

Czołem.
...
Proponuję na przykład tak:

- AT89LS8252 (chyba ma flasha, ISP i eeprom) + klawiatura numeryczna 16 klawiszy, LCD 2*16

- A/D w zasadzie wystarcza 14 bitów (bo by większa rozdzielczość miała sens trzeba by zrobić niepotrzebnie drogą i precyzyjną część analogową, a do pomiarów charakterystyk lamp rozdzielczość 10uA wystarczy). Dwa kanały do pomiaru prądów separowane wzmacniaczami ISO122., zasilane na przykład DCP021212 (czy jak to się nazywa - taki mały przetwornik DC/DC Texasa), dwa kanały bez separacji. Poszukam jakiejś podchodzącej i nie za drogiej kostki przetwornika (DIP :-) )


Jasiu

A gdyby do pomiarów prądu użyć przetworników z I2C,SPI czy innym tego typu interfejsem?
Plusy (moim zdaniem )
- można dobrać przetworniki o bardzo małym poborze mocy(łatwo zapewnić dobre pływające zasilanie).
- jakość wzmacniaczy izolacyjnych nie wpływa ( nie ma ich )
- izolacja magistrali na transoptorach ( chyba dość tanie rozwiązanie )
Co do przetwornic może te z kart sieciowych by się nadały? Uszkodzone/stare karty kosztują grosze) stosowane są tam przetwornice 5/9V - dla małomocowych przetworników i paru transoptorów wystarczy.
Dokładniej mam na myśli coś w rodzaju AD7782.
Można go podpiąć bezpośrednio do rezystora - czujnika prądu plus niezła dynamika.
I jeszcze o małych obudowach - są kłopotliwe, ale dla 16 końcówkowych obudów idzie jeszcze narysować płytkę cienkim pisakiem.(rysowałem pod ADuC824, za drugim razem prawie wyszła:)

[silicon]

Bazy danych na nim nie zrobisz, nawet malutkiej. Do programowania potrzebujesz hardware'u, a uC zrobimy pewnie w ten sposób, że zaprogramuje się z komputra prostym
kabelkiem.

Jasiu

Powiadasz bazy danych się nie da a to ciekawe .
Do programowania PLD używa się nie tylko hardware , zdaje się że o iterface JTAG pewnie zapomniałeś?
i programuje się go z komputera równie prostym kabelkiem.

Programowanie PLD jest duzo mniej popularne od pisania w C, mniej ludzi z tego skorzysta.Program uruchamiać można na emulatorach za parę złotych. Czy są takie do PLD?

Jasiu

Niekoniecznie programowanie PLD jest duzo mniej popularne od pisania w C , zależy w jakim gronie u mnie jest dość popularne.
Zaś co do emulacji i ewentualnie testu to kłania się znów JTAG .

Komunikacja z PC-tem powinna odbywać się jakimś porządnym protokołem, czytelnym dla człowieka. Zrobisz na PLD rozpoznawanie komend z RSa typu S2=102.3? Warto, by kontroler miał możliwość wpisania stałych kalibracyjnych "dopalacza", jakieś limity mocy i co jeszcze przyjdzie do głowy w jakiegoś eeroma.

Jasiu

A przepraszam norma IEEE1149.1 to nie porządny protokół ? dziś co mądrzejszy procek go ma.
Zaś jego funkcjonalność jest przeogromna i zależy tylko od mocy rzeczonego PLD i ... wyobraźni.
Na PLD w zasadzie to chyba nie można tylko otworzyć parasola w ...

No cóż rozumiem Pld odpada , pozostają chyba tylko programowane procesory (chyba)

Pozdrawiam

[Jasiu]

Powiadasz bazy danych się nie da a to ciekawe .

Co prawda przyglądełem im się ostatni raz parę lat temu, ale komórek miały bardziej setki niż miliony... Aż tak się zmieniło? Czyżbym musiał uzupełnić wykształcenie?

Do programowania PLD używa się nie tylko hardware , zdaje się że o iterface JTAG pewnie zapomniałeś?
i programuje się go z komputera równie prostym kabelkiem.

Ano zapomniałem
Na ambitniejszych PLD w życiu niczego nie budowałem, czyli doświadczeń prawie żadnych, wiedza jak widzę pewnie stara, raptem trochę podsłuchanych wrażeń z sąsiedztwa. Jeżeli uważasz, że PLD jet tu optymalnym rozwiązaniem, to broń tej koncepcji jak lew.

A przepraszam norma IEEE1149.1 to nie porządny protokół ? dziś co mądrzejszy procek go ma.

Mówię o protokole, którym gada kontroler z aplikacją na komputrze, a nie o protokole mięchraniu drutami. Mam wrażenie, zę interpreter z analizatorem składni co najmniej kilkunastu koment dla PLD jest dużym zadaniem, a dla procesora to raptem parę kilobajtów kodu. Jako się rzekło, mogę się mylić

No cóż rozumiem Pld odpada , pozostają chyba tylko programowane procesory (chyba)

Dlaczego się tak szybko poddajesz? Na razie jest tylko 2:1 dla uC

Jasiu