Skocz do zawartości

marek1707

Użytkownicy
  • Zawartość

    5879
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    503

Wszystko napisane przez marek1707

  1. Ogólnie dobrze myślisz, dobrze liczysz oporniki, prądy itd, ale zapomniałeś o mocach traconych na ciepło. O tym zwykle się zapomina robiąc pierwsze w życiu podejścia do projektowania i będąc zapatrzonym w prądy i (osobno) napięcia. Wybrane przez Ciebie tranzystory rzeczywiście potrafią przepuścić 1A przez kolektor i to jest pułapka w którą wpadłeś mając klapki na oczach. To małe, plastikowe pypcie, które nie są przeznaczone do grzania się. Ich rezystancja termiczna 200°C/W (typowa dla tego typu obudów) oznacza, że każdy Wat mocy wydzielony w strukturze krzemowej spowoduje jej podgrzanie o 200°C. No, to jakby zamknąć się w termosie i rozpalić ognisko. Ponieważ na pewno nie chcesz by tranzystorek miał w środku więcej jak 80°C (przy temperaturze w pokoju załóżmy 20°C) to prosty wniosek, że nie możesz dopuścić do strat większych niż jakieś 0.3W. Dla przypomnienia: moc ta bierze się z sumy iloczynów wszystkich porądów i napięć na tranzystorze. A teraz wróć do wykresów i zacznij od początku. Wzmocnienie dla prądu 800mA firma gwarantuje ok. 30. Są tam co prawda trzy linie i jedna obiecująco szybuje na wysokości ok. 80, ale jeśli dobrze rozumiem dotyczy ona tranzystorów z najwyższej grupy (przyrostek "-16") a o takich nie piszesz. Co gorsza, cały wykres został zrobiony dla Vce=2V a to oznacza, że tranzystor jest w zasadzie jeszcze w obszarze pracy liniowej. Proste obliczenie i 2V*800mA=1.6W co powoduje szybkie stopienie struktury i nieodwracalne uszkodzenie elementu. Ponieważ bardzo tego nie chcesz, musisz go przesterować znacznie bardziej co wiąże się ze znacznym wzrostem prądu bazy względem przypadku pracy jako wzmacniacz liniowy. Wykresy pokazujące napięcie nasycenia (czyli to czego tygrysy potrzebują najbardziej gdy robią klucze tranzystorowe) bazują już na wzmocnieniu.. 10. Wtedy masz Uce(sat) rzędu 250mV, co dla przy prądzie 800mA daje rokujące 0.2W. Niestety, prąd bazy też nie jest "niewidzialny". Przy wzmocnieniu 10 musisz do bazy wepchnąć 80mA podnoszące Ube na pewno powyżej 1V, co daje nam dodatkowe 0.08A*1V=80mW dodające się do ogólnej mocy strat. Jesteś już zatem na poziomie niebezpiecznie bliskim (0.28W) wyznaczonego limitu 0.3W i Twoje biedne BC639 będą parzyć w palce nawet przy założeniu, że będziesz umiał je dobrze wysterować. A niestety, prądu 80mA nie uzyskasz z pinów Arduino, zatem - kolejny stopień, tym razem na jakimś mniejszym pnp? Zabawa powoli traci sens.. Nauka z tego jest taka, że biorąc pod uwagę osobno parametry wyczytane z karty katalogowej czasem sprawy wyglądają dobrze, ale gdy zauważysz, że to wszystko skupia się w danym elemencie jednocześnie, to zwykle wychodzisz gdzieś poza krótką kołderkę (poczytaj o tzw. SOA - Safe Operating Area tranzystorów, nie jest ograniczone jedynie maksymalnym napięciem i prądem, ale bardzo poważnie mocą). Ogólny wniosek jest prosty: elementy dobierasz z bardzo dużymi marginesami. Jeżeli potrzebujesz tranzystora pracującego z 800mA prądu stałego, to bierzesz taki umiejący 3-5A. Obudowa jego będzie już przystosowana do oddawania ciepła i masz pewność, że nie będziesz zbliżał się do jego katalogowych ograniczeń, gdzie zwykle większość parametrów leci na łeb. Po drugie sprawdzasz warunki pracy i wymagane sterowanie w tych warunkach. Ze swojej strony proponuję jakieś MOSFETy. Nawet te zupełnie małe nie potrzebują w takiej aplikacji żadnego prądu z pinu więc problem dodatkowego drivera bazy znika. 5V otrzymywane z typowego Arduino wystarcza także do dobrego otwarcia w miarę nowego MOSFETa więc nawet z napięciem sterującym nie musisz podjeżdżać do góry. Wybierz coś ze sklepu i pokaż swój typ, w miarę możliwości skrytykujemy dokumentnie Albo znajdź jakieś bipolarne (jeżeli jesteś do nich naprawdę przywiązany), dla których te 0.8A to będzie kaszka z mleczkiem (20-30% tego co mogą?) i gdzie umieją zachować jeszcze jakieś sensowne wzmocnienie (100?). Wtedy policz prądy baz i jeśli wyjdzie 10mA lub mniej, procek będzie bezpieczny i możesz zaczynać budowę. --------------------------------------------------- EDIT: Schemat, mimo że urąga wszelkim regułom rysowania tego typu dokumentacji, jest topologicznie poprawny. Następnym razem postaraj się przynajmniej zrobić to tak, by sygnały płynęły z lewej na prawą, masa zasilania była na dole a plus na górze. Fotorezystor ma swój symbol (i nie jest to kółko), Arduino, taśmę LED i odbiornik podczerwieni powinieneś narysować w formie prostokątów z sygnałami po lewej i/lub prawej stronie i zasilaniami ew. na górze (plus) i na dole (masa). Obecny twór wygląda jakbyś próbował mówić do nas po czesku - da się zrozumieć, ale zabawy (a co gorsza nieporozumień) przy tym sporo..
  2. Impulsy WN wytwarzane sa przez odpalenie tyrystora a jego obwód bramki składa się z diaka (elementu spustowego o ujemnej rezystancji) tutaj wykonanego z oszczędności z tranzystorów T3/T4 i z układu czasowego R3+R4/C3. To prędkość ładowania C3 przez oporniki R3+R4 wyznacza czas osiągnięcia progu wyzwalania diaka (ustawianego dzielnikiem R5/R6 - ale tego raczej nie ruszaj) i zapłon tyrystora. Powinieneś zatem móc zmieniać tę prędkość (a więc i okres powtarzania impulsów WN) poprzez kręcenie R4 a jeśli to nie wystarcza, zmniejszenie pojemności C3 (np. dwukrotne) powinno około dwukrotnie zwiększyć częstotliwość.
  3. Jest OK. Już o tym wspominałem: termopara generuje napięcie z różnicy temperatur i to tę różnicę masz podaną w tabeli. Jeżeli woltomierzem zdejmujesz 4.1mV to znaczy, że między zimnym a gorącym końcem jest ok. 100°C a nie że termopara ma w jakimś miejscu 100°C. Natomiast kompensacja wbudowana w MAXa zakłada, że zimny koniec termopary ma temperaturę otoczenia w jakim pracuje sam scalak. On to sobie mierzy wewnętrznie i dodaje do wyniku przeliczonego z napięcia wejściowego. Jeżeli w pokoju masz 20°C to te 4.1mV zobaczysz jako 120°C i to zaczyna się zgadzać z tym co masz. Te brakujące (do 140) 20°C zrzuciłbym na pomiar miliwoltów multimetrem, bo przecież mówimy o napięciu 0.8mV a tyle to możesz dostać podgrzewając w rękach zwarte sondy. Moim zdaniem to działa.
  4. To wygląda całkiem dobrze. MAX działa, poprawnie kompensuje zimny koniec a i termopara wydaje się OK. Różnica między pomiarem "wzorcowym" a tym z problematycznej termopary wewnętrznej może brać się zwyczajnie z różnicy miejsca pomiaru i odzwierciedlać rzeczywiste różnice. W środku tuż przy grzałce jest zwyczajnie sporo cieplej niż na zewnętrznej powierzchni lutownicy i stąd coraz większy rozdźwięk między wynikami w miarę wzrostu temperatury (bo zewnętrze jest coraz lepiej chłodzone). Na pewno jest też opóźnienie między temperaturą grzałki/grota a płaszczem zewnętrznym. Czy np. po 30 sekundach grzania, wyłączeniu prądu i kolejnych 30 sekundach (na stabilizację warunków) też widzisz takie różnice? Zewnętrzny czujnik nie może zwyczajnie dotykać do lutownicy, bo wtedy mierzy jakby "średnią" między gorącą blachą, otaczającym powietrzem i swoimi drutami. Musi być dobrze związany z lutownicą np. umieszczony pod metalową opaską nałożoną na kolbę lub włożony do środka grzałki, np. w miejsce grota. Pomiar porównawczy musi być dokonywany w warunkach statycznych, gdy możliwie wszystkie przepływy energii się zatrzymały. Możesz np. owinąć kolbę warstwą tektury falistej lub jakimiś szmatami (nawet ciepłą skarpetą), pod to włożyć (i dobrze przymocować drutem) czujnik zewnętrzny i podgrzać do 50 stopni, nie więcej, bo dym się zrobi. Po odczekaniu 15-30 sekund bez prądu zaczynasz mieć stabilny obiekt - i wtedy mierzysz.
  5. Bardzo mało prawdopodobne by użyto innej termopary niż K, bo to najtańsza i najbardziej rozpowszechniona wersja. Takie coś samo z siebie ma rezystancję rzędu miliomów więc jeśli mierzysz ok. 1Ω to wskazuje na problemy z samym pomiarem: rezystancja sond miernika, przejścia na złącze, kabla lutownicy itd. Gdyby to był termistor, miałby co najmniej setki omów. Może spróbuj zmierzyć różnicę między zwartymi na krótko sondami a obwodem z wpiętą termoparą? To powinno trochę przybliżyć odczyt do rzeczywistości. No ale to nie zmienia faktu, że słabo działa z front-endem MAXIMa. Po pierwsze wyjaśnij nam co oznacza "bardzo przekłamane wartości". Czy dostajesz stałe zero, wynik wskazujący na niepodłączenie termopary (jest taka flaga w scalaku, o ile pamiętam) jakiś stały offset (przesunięcie), wynik rosnący z temperaturą, ale z inną prędkością (zła skala przetwarzania) czy zwyczajnie losowy szum? Obwód termopary jest praktycznie zwarciem (o ile jest poprawnie zrobiony) więc zakłócenia się go nie imają. Skoro dostajesz napięcie, zmierz je zwyczajnie multimetrem (zakres 200mV) w temperaturze pokojowej i po nagrzaniu kolby do temperatury kilkudziesięciu stopni (gdy już nie będziesz mógł jej utrzymać w dłoni) i sprawdź dla pewności, czy oba wyniki pasują do typu K. Przecież tabele tych wielkości są ogólnodostępne. Potem to samo z podłączonym scalakiem, mierząc napięcia na jego pinach. Pamiętaj, że termopara nie mierzy temperatury bezwzględnej tylko różnicę między jej "gorącym" a "zimnym" końcem. Ile drutów ma ta lutownica? Może obwód termopary ma któryś wspólny kabelek z grzałką i nie możesz jednocześnie mierzyć i grzać? Może uszkodzona jest wtyczka albo gniazdo i raz styka a raz nie? Czy kiedy zewrzesz zwykłym drutem wejścia MAXa, to dostajesz stabilne okolice 20-25°C (MAX ma na pewno kompensację zimnego końca i zakłada, że jest to jego własna temperatura więc dla Uin=0mV pokaże tyle ile mierzy swoim wewnętrznym termometrem)? Czy dla wejść niepodłączonych dostajesz bit awarii obwodu termopary?
  6. Nie wypada nie znać tego Klasyka. Mam nadzieję, że jesteś wystarczająco dorosły by wiedzieć czyje to słowa. Wywalony język w tym kontekście jest raczej niestosowny. Tak, też o takim zastosowaniu przez chwilę pomyślałem, ale martwi mnie, że Kolega @Maniekdron zdążył już zadać kilka pytań w sprawie lataczy i że dryfuje w tym kierunku płynąc przez gęstą mglę mieszanki niewiedzy i entuzjazmu...
  7. Tak, można, z pewnymi ograniczeniami. To się da zrobić i rzeczywiście pojemność wzrośnie jak napisałeś. Pytanie tylko po co budować tak wielki i tak niskonapięciowy akumulator. Robisz stację pogodową na Arktykę czy boję nawigacyjną? Lepiej dla kogo? Dla ogniwa, dla Twojego zdrowia, budżetu czy dla reszty elektroniki? Nie ma prostej odpowiedzi, bo jak zwykle sa plusy dodatnie i plusy ujemne takego rozwiązania..
  8. Może spróbuj inaczej: opisz prawdziwy problem a nie dziwne próby jego rozwiązania. Czy masz kłopot w tym, że chcesz zrobić timeout dla jakiejś operacji wykonywanej w funkcji? Co ma się wtedy stać, gdy czas oczekiwania się przeciągnie i coś się nie wykona? Jak chcesz (jak mógłbyś) informować program o niepowodzeniu funkcji? Czy chcesz zatrzymywać program na jakiś czas tak po prostu? Czy chcesz robić kilka rzeczy (wątków) na raz, ale nie wiesz jak? Na razie zapomnij o timerach i ich przerwaniach i zwyczajnie w kilku zdaniach opowiedz co chcesz zrobić. Być może próbujesz w dziwny sposób (zapętlanie pinów do wejść procesora - bez sensu) zrobić coś co jest proste i dawno zrobione.
  9. Z pewnością było i jest ich wiele. Na odpowiednio niskim poziomie trudno wskazać jednoznaczne źródło. To jakbyś pytał dorosłą osobę skąd wie jak wygląda stacja kolejowa. Takie rzeczy po prostu są w głowie i tyle.
  10. Pytanie jest dziwne, bo zawiera tezę, że czujniki serii MQ są jonizujące - a tak nie jest. Odpowiedź zatem nie może być jednoznaczna. Czujnik jonizujący - jak sama nazwa wskazuje musi umieć jonizować powietrze. Można to zrobić jakąś metodą elektryczną (wysokie napięcie np.), ale rzeczywiście najprościej jest wstawić źródełko promieniowania i badać powstały w wygenerowanym polu elektrycznym prąd (płynący "przez powietrze"), na którego wielkość mają wpływ stojące na drodze duże cząstki dymu. Za to czujniki MQ to zupełnie inna zasada pracy. W środku mają elementy wykonane z materiałów czułych chemicznie, gdzie rezystancja zmienia w się w zależności od stężenia danego rodzaju gazu przy powierzchni detektora. Niektóre z tych materiałów lepiej/stabilniej pracują w wyższych temperaturach i dlatego niektóre (a może wszystkie? - nie robiłem przeglądu) czujniki MQ mają wewnętrzne piecyki i choćby z tego powodu moim zdaniem kompletnie nie nadają się do czujników zasilanych z baterii. Przy okazji: ich dokładności i powtarzalności są rzadne więc to bardziej są wskaźniki dobrze-źle niż elementy pomiarowe.
  11. Dzięki, nie sprawdzałem ani swoich ani Twoich obliczeń, ale najwyraźniej widocznie "proste obliczenia" nie są moją mocną stroną
  12. To dwie różne rzeczy. 1. Zabezpieczenie stabilizatora przed napięciem wejściowym niższym niż wejściowe. 2. Zabezpieczenie przed pojawieniem się na wyjściu napięcia o odwrotnej polaryzacji. W pierwszym przypadku a) masz za duże kondensatory wyjściowe i to ich energia niszczy strukturę dużym prądem płynącym długi czas (czasem widzę, że ludzie dają jakieś absurdalne setki lub nawet tysiące uF, które w niczym nie pomagają a wręcz przykrywają problemy ze złym projektem ), b) zrobiłeś coś dziwnego na wejściu. Bo za duży prąd nie popłynie wstecz (bo niby dokąd?) gdy na wejściu zwyczajnie odłączysz zasilanie tylko gdy zewrzesz wejście do masy - to zawsze jest groźne i jeśli coś takiego jest możliwe, dioda musi być ogromna. Na to drugie rada jest prosta: dajesz od wyjścia do masy diodę normalnie nieprzewodzącą. To szczególnie ważne w systemach z zasilaniem bipolarnym, gdzie część napięć jest dodatnich a część ujemnych i z oczywistych powodów nie wstają razem. Gdy pewne obciążenie korzysta z obu gałęzi (np. wzmacniacz operacyjny) to może zaistnieć stan przejściowy w którym na szynie dodatniego zasilania pokaże się napięcie ujemne i odwrotnie. W obu przypadkach dioda Schottky równolegle do kondensatorów wyjściowych załatwia sprawę. W obu przypadkach elementy zabezpieczające muszą być duże i zajmowałyby sporą cześć struktury a i tak nie byłoby pewności, że spełnią swoją powinność. Dlatego nie dostajesz ich w standardzie.
  13. Problem jest w tym, że transmisja danych do diodek nie odbywa się w zerowym czasie. Typowo na jeden bit potrzebujesz ok. 1.2us. To mało, fakt, ale do jednej diodki wysyłasz 24 bity, czyli potrzebujesz 28.8us. To wciąż wydaje mało, ale wysyłka wszystkiego do 1 metra (60 LEDów) zajmuje już 1.73ms. To oznacza, że nowy obraz tego metra możesz aktualizować ok. 580 razy/s. W Twoim przypadku oznacza to przejazd (przepłynięcie) jednej diodki przez 1 metr wykona się ok. 580/60=10 razy/s. No ale Ty próbujesz to samo z robić na 11 metrach a taka kupa diodek wymaga 11 razy dłuższej transmisji. Proste obliczenia wskazują, że przesunięcie pojedynczo świecącej diodki przez taką taśmę zajmie ok.1 sekundę bo każdy nowy obraz stanu 600 diodek potrzebuje aż ok. 19ms na przesłanie go do taśmy. Masz zatem tylko 20 "klatek"" na sekundę. A przecież nie liczymy tu jeszcze czasu przygotowania nowego obrazka przez procesor...
  14. 1. Już główna teza tego wątku jest fałszywa więc dalsza dyskusja trochę nie ma sensu. Otóż są stabilizatory równoległe (poszukaj hasła "shunt regulators"), choć częstość ich występowania oraz wachlarz dostępnych układów są o wiele mniejsze. 2. Zastanów się proszę w jaki spsób taki regulator musi działać. Żeby zmienić napięcie w obwodzie jak na dolnym rysunku źródło zasilania musi mieć niezerową impedancję wyjściową - to po pierwsze, bo to na niej odłoży się dodatkowy spadek i druga równie ważna rzecz to to, że ten spadek napięcia okupiony jest większym poborem prądu który zwyczajnie grzeje wszystko po drodze więc sprawność spada na łeb. Rozwiązania takie stosuje się w pewnych wyjątkowych przypadkach, np. ograniczników napięcia. Masz dla przykładu źródło z ograniczeniem prądu i napięcia CI/CV - jak np. ładowarka do akumulatorów i chcesz zrobić zabezpieczenie przed przeładowaniem lub zwyczajnie prymitywny balancer ogniw. Robisz wtedy shunt regulator na 4.3V i czekasz. Gdy napięcie na ogniwie wzrośnie do tej (już za wysokiej) wartości, regulator zaczyna pobierać coraz większy prąd przejmując na siebie coraz większą jego część płynącą z ładowarki. Niczemu to nie grozi, bo źródło ma ograniczoną i kontrolowaną wydajność więc w szczególnym przypadku regulator może wziąć 100% prądu. To samo rozwiązanie nie zadziała (albo co najmniej nie ma sensu) gdy źródło jest wydajne, np. akumulator, dobry zasilacz czy sieć 230V. Zabezpieczających przed czym? Przed głupotą projektantów? Taki element szeregowo z definicji pogarsza sprawność i - jak napisał Harnaś - podwyższa dropout. W przypadku gdy istnieje szansa, że na wyjściu stabilizatora pojawi się napięcie z obcego źródła, stosuje się inne rozwiązania: specjalne konstrukcje odporne na takie warunki lub p[rawie bezstratne sumowanie źródeł zasilania na tranzystorach (tzw. ideal diode - sa do tego kontrolery). A diodę - poor men protection - zawsze możesz wstawić gdy nie masz lepszego pomysłu. Gdy popatrzysz na strukturę krzemową stabilizatora, to tranzystor regulacyjny stanowi 90% powierzchni tekiego układu. Musi być duży bo tylko on przenosi cały prąd obciążenia i to na nim wydziela się moc. Wszystko inne jest lekkim dodatkiem. A Ty proponujesz, by producent dołożył sobie drugie tyle kosztów na wielką szeregową diodę celem pogorszenia parameterów konstrukcji, dziwne..
  15. To możesz kupić w ciemno. Są do tego biblioteki, poradniki jak podłączyć itp. Ponieważ jest to stosunkowo tanie a paczka idzie z daleka, weź tego więcej żebyś nie zmarnował dwóch tygodni na kolejną sztukę. Zawsze podczas montażu lub uruchamiania może zadrżeć ręka, omsknąć się wkrętak lub zasilacz "podłączy się" odwrotnie i skucha gotowa.
  16. Aby ożywić ten panel musiałbyś znać znaczenie sygnałów na tym 10-pinowym złączu na kabelku. A może to być zrobione zupełnie dowolnie. Być może jest jakiś standard wśród urządzeń tego typu (albo płytek tego producenta), ale nie wiadomo czy gdzieś opublikowany. Może wyślij zapytanie do sklepu? Inna możliwość jaka mi się rysuje to zakup sterownika/panelu do tego wyświetlacza i wyczajenie (oscyloskop + trochę wiedzy) protokołu szeregowego, ale to by się opłacało gdybyś miał kupić skrzynkę tych płytek - wtedy koszt sterownika i poświęcony czas zginąłby w masie. Same wyświetlacze są nic nie warte, takie pasywne szkiełko LCD z kilkoma cyframi możesz kupić za grosze. Te akurat mają mało pinów więc do zwykłych wyjść cyfrowych procesora ich nie podłączysz bo - jak napisał Kolega @atMegaTona - mają multipleksowanie z conajmniej 4 poziomami napięć. Być może coś warte są podświetlania do nich no i cała płytka jako kompletny podzespół, ale 40 złotych to bym za to nie dał. Nie wiem co to za atrakcja i to już po obniżce.. Także owszem, mógłbyś ten panel podłączyć wprost do Arduino (być może w wersji 3V) gdyby było wiadomo co i jak do niego przesyłać. Może napisz co chciałeś na tym zrobić?
  17. Nie wspominając już o tym, że: Źródło zasilania musi być sporo większe i mocniejsze a więc rzeczywisty przyrost osiągów (a pewnie o to chodzi) będzie znikomy. Na tych silniczkach wiele nie uzyskasz. To szczotkowe chuchra policzone na przewatowanie i krótką pracę już z założenia. W samym lataczu pracują w meganiesprzyjających warunkach (direct drive) tylko dzięki dobremu chłodzeniu strumieniem zaśmigłowym. Zbudowałem na nich kilka mikrosamolotów i sam się dziwię, że to zrobiłem. Dochodzą do 70° podczas normalnej pracy a jedyną ich zaletą jest trywialny driver (jeden tranzystor). Jeśli chcesz zbudować coś większego, po prostu to zbuduj od zera. Dziś wszystkie graty dostaniesz w jednym sklepie modelarskim a będziesz dysponował kopterkiem który wyrywa z butów, będzie dowolnie rozbudowywalny (diody LED, kamera FPV z OSD, kilka trybów latania) i gdzie wszystko ustawisz z poziomu aplikacji na PC. Jakakolwiek inwestycja w jednorazowe zabawki to strata czasu i pieniędzy. To nie lata samo z siebie tak jak np. samolot. Procesor pokładowy ma skomplikowany program ze sporą dawką matematyki i wbudowane pewne ustawienia regulatorów reagujące na dynamikę tej konkretnej ramy: wielkość, rozłożenie mas, momenty bezwładności i tylko dlatego jest to stabilne w locie. Dodanie kolejnych silników i zmiana akumulatora zaburzy ten rozkład i kopterek przestanie latać stabilnie. Driverkami silników są tu wyżyłowane tranzystorki w SOT23 (te małe czarne w rogach) już pracujące na oparach - tak jak same silniki..
  18. Tak szczerze mówiąc to bez jakiegokolwiek wsparcia trudno mówić o zabawie we własny procesor. No bo ile można dłubać na kartce papieru kody szesnastkowe? No dobra, trochę można, ale żaden większy program w ten sposób nie powstanie. Liczenie adresów skoków - szczególnie po zmianach w kodzie - to najbardziej głupia i żmudna robota. Język mnemoniczny jest jednak na tyle prosty, że już dziesiątki lat temu powstały asemblery uniwersalne, tzw. meta--asemblery, sterowane tablicami umieszczanymi w plikach konfiguracyjnych. Swego czasu używałem namiętnie czegoś co nazywało się CROSS-16, pracowało pod DOS-em i miało "w pakiecie" tablice dla większości 8-bitowych procesorków (a na pewno 8080, 6502, 8048, 8051, Z80 itp). Stworzenie swojej własnej dla nowego procka w FPGA, mając podręcznik albo nawet patrząc jak zrobione są te już gotowe nie powinno stanowić problemu. Wierzę, że jest to gdzieś do znalezienia w sieci. A propos. Skoro mówimy o pisaniu programów, to dobrze jest - tworząc taki procesor - przewidzieć możliwości ładowania kodu i debugowania. Jakiś interfejs ze świata zewnętrznego (SPI? USB? cokolwiek) umożliwiający przeładowanie nowego programu bez konieczności rekompilacji FPGA jest koniecznością, którą trzeba tworzyć razem (a może raczej wokół lub obok) ze strukturą procesora. To samo z uruchamianiem: mając prawie nieograniczone możliwości logiki bez poblemu można wbudować w jądro jakieś wsparcie w tym zakresie: wymuszanie startu, stopu, pracy krokowej, podgląd rejestrów i pamięci, pułapki na adresach programu czy pamięci danych itd itp. BTW: Zapomniałem o TMS9900 - ciekawym, bezakumulatorowym 16-bitowcu od Texasa, oraz o 6100 czyli o 12-bitowym CPU z PDP-8 na jedym chipie od Intersila
  19. 1. Wiesz, z tym kompilatorem to nie mozna przesądzać. Wszystko zależy od zainteresowań i umiejętności samego twórcy. Dziś (niestety?) bardzo się specjalizujemy i to jest normalne, bo nie spsób wiedzieć wszystkiego o wszystkim. Dlatego kiedyś (np. czasach np. "lampowych") będąc elektronikiem w zasadzie mogłeś policzyć i zbudować wszystko co było. Miałeś wybór między wzmacniaczem audio, odbiornikiem radiowym, jakimś przyrządzem pomiarowym czy nadajnikiem. Znano kilka sposobów modulacji i wszystkie były do zrozumienia i opanowania w godzinę. Dzisiaj jeśli elektronik zna się dobrze na jakiejś rodzinie przetwornic impulsowych to jest fachowcem w tym temacie, inny wie dużo o pewnej klasie wzmacniaczy operacyjnych a inny ma w małym palcu układy RF. I oczywiście każdy z nich zbuduje ultradźwiękowy wykrywacz nietoperzy, ale żaden z nich osobno nie stworzy kompletnego hydrofonu dla okrętu podwodnego. Nawet nie myślę czy projektant FPGA to jest jeszcze elektornik czy już programista a już ktoś kto bierze udzaiał w przedsięwzięciu pt. GCC programistą musi być z definicji. Natomiast wracając do zabaw amatorskich, to na pewnym poziomie da się posiadać wiedzę rozległą. I wtedy jeden człowiek może zaprojektować i płytkę do FPGA i sprzętowe otoczenie układu (zasilanie, interfejsy) i zrobić projekt wnętrza i napisać asebmbler a w końcu stworzyć kompilator C, Pascala czy Ady. Wszystko z takiego samego powodu z jakiego Ty bawisz się w AVR na FPGA - dla czystego fanu, bo przecież nie ma szans by wymyślony w domowym zaciszu procesorek znalazł dziś jakieś komercyjne zastosowanie. Daleko szukać: ze mnie jest programista jak z koziej dupy trąba, a napisałem od zera i asemblery kilku procesorów i interpreter BASCIa dla swojego komputerka, bo to było fajne Także: nigdy nie wiadomo. 3. Z gustami sie nie dyskutuje. Ja generalnie lubię konstrukcje z tamtych lat, mogę dyskutować o ich wadach i zaletach względem pozostałych, ale nie wyróżniam jakoś istotnie któregoś. To był czas bardzo szybkiego rozwoju i każda następna generacja chipów mogła mieć więcej tranzystorów co od razu było widać w architekturze i liście instrukcji. 8080 miał sporo rejestrów i dużo instrukcji co było miłe, a brakujące tryby adresowania można było emulować dzięki kilku instrukcjom arytmetyki 16-bitowej (dodawanie, inkremetacja, dekrementacja całych par rejestrów). Miał fajnie przemyślane wsparcie przekazywania parametrów przez stos lub przez umieszczanie argumentów za wywołaniem i to była spora zaleta. 6502 płacił za rozbudowane tryby adresowania czasem wykonania i ubogą listą instrukcji. Liczba rejestrów także była minimalna bo jak zwykle.. kołderka była za krótka. Jeśli rozbudowałeś sterowanie/sekwencer to brakowało powierzchni na jednostkę obliczania adresów czy rejestry. Przecież 6502 liczył 16-bitowe adresy za pomocą 8-bitowego sumatora co w przypadku przekroczenia 256-bajtowej strony wymuszało wydłużenie czasu o 1-2 cykle maszynowe - dziś to się wydaje śmieszne. Za to skromne wyposażenie w rejestry kompensował krótkimi instrukcjami adresującymi stronę zerową, ale już tylko 256 bajtów na stos na stronie 1 było poważnym ograniczeniem. To co prawda były czasy gdy 1Kbajt RAMu to już było coś więc tak bardzo nie bolało, ale RAMy rosły chyba wtedy szybciej niż procesory.. Tak samo można pisać o każdej innej konstrukcji z tamtego okresu. Coś wymyślili lepiej, ale zabrakło tranzystorów na coś innego i Centralny Wyrównywacz w postaci ograniczeń technologicznych obowiązującyh wszystkich bez wyjątku działał niezwykle sprawnie. Dzisiaj mamy ten komfort, że możemy na te projekty spojrzeć zimnym okiem i bez emocji porównywać a przede wszystkim na nich się uczyć. Dostępne są przecież dokumentacje chyba do wszystkich istotnych maszyn z tamtego okresu. Proponuję zatem zagłębić się w temat, czytać i.. podziwiać Moje typy: PDP-8, PDP-11, AGC, 6800, 65xx, 4004, 4040, 8008, 8080, Z80, 8048, 8051, PIC16, Z8... Każdy z nich miał coś wyjątkowego,, co zwykle było jakimś kamieniem milowym w rozwoju procesorów albo przynajmniej był wzorcowym przykładem optymalzacji projektu w obecności poważnych ograniczeń i wielu sprzecznych wymagań. Trywialny przykład: przecież 4004 nie był tak mały (fizycznie) dlatego, że to było wygodne (bo nie było) tylko dlatego, że nie było sprawdzonych większych obudów do scalaków. DIP24 czy DIP40 to dopiero przyszłość..
  20. Moim zdaniem, niezależnie od tego jak zostanie zrobione samo sterowanie silnikiem/stycznikami, kluczowy jest tutaj odczyt położenia. Musimy mieć informację o bezwzględnym położeniu strzałki, bo jej pozycja będzie "celem" kontrolera. Rzeczywiście, wydaje się, że najmniej zmian (w mechanice) pociągnie za sobą enkoder, ale te typowe obrotowo-impulsowe mają okropną wadę: oddają impulsy gdy oś się obraca i co prawda możemy je sobie zliczać, ale to daje wiedzę jedynie o tym o ile (stopni, obrotów a tak naprawdę kroków enkodera) obrócił się wał. Po włączeniu urządzenia nie wiadomo gdzie jest strzałka i kontroler musiałby podjechać do jakiejś znanej pozycji "na ślepo", np. zawsze na sam dół gdzie na strzałkę czekałby jakiś wyłącznik krańcowy. Dopiero po uzyskaniu tego sygnału sterownik zerowałby pozycję i zaczynał normalną pracę, np. począwszy od dojechania do ostatnio ustawionej przyciskami i zapamiętanej pozycji. Jeżeli takie zachowanie jest akceptowalne, OK, można kupić nawet jakiś enkoder o wystarczającej rozdzielczości kątowej, wmontoeać i zacząć myśleć o sterowaniu. Wadą tego rozwiązania jest także to, że w warunkach przemysłowych czasem procesory głupieją (problemy z zasilaniem, z zakłóceniami itp) i gdyby nagle coś mu odbiło i popsuł sobie licznik aktualnego położenia, to potem całe działanie byłoby błędne. Dopiero ingerencja operatora na ewidentną awarię (inne położenie wstrzałki względem tego co ustawiliśmy na wyświetlaczu) spowodowałoby restart, przejazd "zerujący" i powrót do normalnej pracy. Dużo lepszym rozwiązaniem jest enkder bezwzględny,m oddający na kilku bitach kątowe położenie wału. Tutaj jednak całkowita droga wynosząca ponad 1m wymuszałaby duże, dodatkowe koło enkdera sprzęgnięte z pasem napędowym, bo przecież urządzenia tego typu poddają położenie w ramach jednego obrotu. A 1.1m drogi linoiowej to koło pasowe o średnicy min. 35cm - trochę sporo. Jeżeli jednak to nie stanowi problemu mechanicznego, to kupujesz enkoder tzw. absolutny przynajmniej 10-bitowy i montujesz. Z jego1024 kroków dla bezpieczeństwa można wykorzystac może z 900 a wtedy rozdzielczość wyniesie 1100mm/900=1.22mm. Jeżeli to słabo, to są enkodery 11- i więcej bitowe, ale ich cena rośnie szybko.. Tu masz dwa enkodery absolutne, jeden "cyfrowy" i jeden "analogowy": https://www.eldar.biz/sklep/enkodery/enkodery-obrotowe?rodzaj_enkodera=124 a tu dla porównania cen masz przemysłowe enkodery inkrementalne o rozdzielczości 256 imp.obrót. Ta może być mniejsza niż absolutnego, bo enkoder tego typu mógłby obracać się wiele razy na pełnej drodze strzałki: https://www.eldar.biz/sklep/enkodery/enkodery-obrotowe?rozdzielczosc=7 Innym rozwiązaniem, być może mechanicznie lepszym niż 35cm kółko pasowe jest enkoder liniowy. Te cacka jeżdżą poa specjalnych, sztywnych taśmach magnetycznych i znów: są tanie inkrementalne pokazujące tylko o ile przesunęła się głowica i te droższe, absolutne, gdzie po prostu dostajesz informację "gdzie jestem": https://www.eldar.biz/sklep/enkodery/enkodery-liniowe?rodzaj_enkodera=124 W zależności od rozdzielczości, typu wyjścia itp cena się zmienia, ale i tak ekonomicznie chyba wychodzi lepiej niż te obrotowe. No i trzeba pamiętać, że musisz do niego dokupić specjalnie kodowaną taśmę o odpowiedniej długości. Np. w tym sklepie z linku mają tylko do 600mm Mozna próbować jakichś metod chałupniczych typu pomiar odległości strzałkii od jakiejś bazy,, ale te tanie czujniki nie zapewnią odpowiedniej rozdzielczości i dokładności a te droższe, np. laserowe przekraczają cenowo enkodery. Także podsumowując: musisz rozejrzeć się co by Ci pasowało jako czujnik. Reszta będzie konskwencją tego wyboru i tym się na razie nie przejmuj. Prędzej czy póxniej skończysz na jakimś Arduino, chyba że znajdziesz gotowca specjalnie do tego. Teoretycznie można by wykorzystać nawet jakieś.. termostaty , gdzie zamaiast czujnika temperatiry podłaczysz napięcie z enkodera absolutengo (z wyjściem napięciowym), ale to chyba nie zapewni ani pozycjownowania do 1/1000 zakresu ani też liczby na wyświetlaczu nie będą odpowiadały milimetrom. Tu masz przykładowy czujnik laserowy z wyjściem liniowym (prądowym). Mają one zwykle jakąś odległość minimalną więc nie można wziąć takiego co mierzy tylko do 1m, bo do zabawy zostanie Ci z 80cm. Ten ma wystarczający zakres, ale za to powtarzalność rzędu 6-8mm a liniowość 30mm. Musiałbyś go zamontować w pobliżu któregoś koła napędowego i musiałby patrzeć na małe lusterko (kawałek blaszki) gdzieś na strzałce. Gdyby się okazało, że jego błedy są w miarę stałe i powtarzalne, to elektoronika mogłaby je korygować tak, że może dostałbyś ten 1mm dokładności pozycjonowania, ale tego z góry nie można zapewnić. W sumie 0.1% to dość wygórowane wymaganie. https://www.conrad.pl/p/optyczny-czujnik-odlegosci-ifm-electronic-o1d102-zakres-02-35-m-18-30-vdc-507204 Każdy czujnik tego typu w zasadzie da się jakoś podłączyć do Arduino,, ale jeśłi nie jesteś elektronikiem, nie masz warsztatu ani smykałki do tego (na razie?) to musiałbyś szukać gotowych modułów interfejsu. Na pewno też są do znalezienia, ale - jak już napisałem - podstawa to wybór czujnika.
  21. W żadnym razie nie chodziło mi o niszczenie zaangażowania Kolegi @rafal2808 a raczej o pokazanie, a) że jest mnóstwo dobrych przykładów, b) że nawet prosty procesor jest o wiele bardziej skomplikowanym projektem niż się wydaje na pierwszy rzut oka. Siadając do komputera mamy zwykle ogromną ochotę od razu zacząć pisać program albo tworzyć kod VHDL a nie tędy droga. Bez przemyślenia na pewno też coś powstanie, ale bez żartów - trudno będzie nazwać procesorem coś wykonującego kilka przypadkowo zmyślonych instrukcji składających się na mruganie LEDem. OK, to pewnie spełnia wymogi formalne definicji słowa procesor, ale spełnia je także maszynka do drylowania wiśni. I dlatego chętniej zobaczyłbym projekt architektury (ten z punktu widzenia programisty) i listę instrukcji - bo to daje już posmak tego co można będzie zrobić pisząc pierwsze programy - niż obrazek z licznikami, pamięciami i strzałkami a co gorsza od razu kod VHDL. Rozumiem, że to nie wyścig na Księżyc i jako amatorzy musimy zaczynać od prostych rzeczy, ale nawet robiąc coś 4- czy nawet 1-bitowego dobrze jest mieć jakiś plan. Nie polegający na zwykłym "zrobię sobie procesor", tylko jakiś bardziej precyzyjny w szerszym kontekście. Inaczej nauka języka i konkretnego środowiska (bo jak rozumiem głównie o to tu chodzi) nie będzie efektywna. A jedynym sprawdzianem Twoich umiejętności jest przecież porównanie. Możesz całą zimę spędzić na siłowni i basenie, od marca przesiąść się na rower i z kopyta ostro jeździć ale cały ten trening będzie nic nie wart dopóki nie porównasz swoich wyników z osiągnięciami innych ludzi. Dlatego dopiero wyścig weryfikuje co umiesz. Tutaj tak samo: pomysł typu "zrobię 4004 wykonujący jego natywny kod binarny" jest dobrym wyzwaniem, ale dużo lepszym jest "ale w mniejszej liczbie taktów zegara" (co akurat w przypadku tego 16-pinowego CPU z 4-bitowym kontaktem ze światem jest bardzo proste). A w przypadku architektur własnych - jak ta tutaj - świetną oceną mogą być benchmarki starych procesorów. Co więcej, były one wręcz stworzone do pisania w językach asemblera więc nauczenie się kilku z nich choćby dla potrzeb stworzenia własnych testów prędkości byłoby kolejnym plusem tej zabawy. Jeżeli Twoje 8-bitowe cudo zrobione na nowoczesnym FPGA i używające w zasadzie nieograniczonej liczby bramek będzie wolniej (w sensie liczby taktów zegara) sortowało blok pamięci albo wolniej liczyło iloraz dwóch liczb 32-bitowych lub zmiennoprzecinkowych niż 8080 to wiesz, nie ma się czym chwalić ani z czego cieszyć. Gdzieś popełniłeś poważne błędy w projekcie: albo w architekturze, albo w liście instrukcji a goście sprzed kilkudziesięciu lat zrobili to zwyczajnie lepiej. No chyba, że założenie było inne, np. "moje 8-bitowe CPU będzie miało wyłącznie 1-bitowe magistrale szeregowe" - bo takie procesory też były, albo może "mój procesor będzie natywnie wykonywał kod Brainfuck'a" - to też już było, albo "skoro każdy układ logiczny można zsyntetyzować przy użyciu bramek NAND to moje CPU będzie miało1-bitowe ALU z jedną instrukcją - zgadnijcie jaką". Cóż, zmyślam na poczekaniu... Podsumowując: nie widzę sensu w implementacji czegokolwiek (niechby i procesora) bez postawienia sobie jasnych i weryfikowalnych założeń. Nie muszą to być wyzwania z kosmosu, ale na pewno nic trywialnego lub mglistego. I chętnie o takich założeniach mogę dyskutować. A tej uwagi o kompilatorze C nie bardzo rozumiem. Tworzenie kompilatorów jest dzisiaj zautomatyzowane, ale projektant sprzętu nie musi umieć ich pisać. Od tego są inni ludzie. Ma zrobić procesor, który nie ma wąskich gardeł i spełnia założenia (np. jeśli ma być programowany głównie w C to ma się niego dobrze pisać kompilatory - to też widać w architekturze) natomiast może i powinien przetestować swój procesor na wielu typowych programach/testach a do tego wystarczy asembler. Zaznaczam, że wciąż mówimy o małych, jednowątkowych maszynkach do nauko-zabawy w domu. BTW: Chyba pamiętam ten walizkowy system na 8080. EDIT: -------------------------------------- "Zgadzam się z Tobą, że jego architektura (MOS6502) była dużo lepsza od Intela 8080.." Hej, nigdzie tego nie napisałem. Wspomniałem o minimalnej, czyli prostej do implementacji nawet dla początkującego a dającej już frajdę w pisaniu programów.
  22. W zasadzie wystarcza, bo z punktu widzenia sprzętu PC to jedyny zasób którego program rozpoczynający wykonywanie ISR nie jest w stanie odtworzyć. Jak rozumiem miałeś na myśli "niewystarczanie:" w sensie niszczenia ogólnego stanu procesora w trakcie wykonywania obsługi przerwania. Niestety tu mamy kolejny przykład ważnej decyzji: jeżeli sprzęt będzie zapisywał na stos dużo rzeczy, to będzie to kosztowało dużo czasu więc reakcja procesora na przerwanie będzie wolna. Pierwsza instrukcja naszego kodu ISR wykona się dopiero po dokonaniu iluś tam zapisów do pamięci, a nie zawsze jest to konieczne. Można sobie wyobrazić przerwanie, którego obsługa składa się z jednej instrukcji, np. mając do dyspozycji wiele rejestrów, jeden z nich można globalnie zarezerwować na wskaźnik w jakimś buforze. Przykładowy ADC zgłasza koniec konwersji, sprzęt zapisuje tylko PC na stos, wykonuje pierwszą instrukcję z ISR która polega na a) przeładowaniu słowa danych z ADC do pamięci pod adres umieszczony w umówionym rejestrze i b) jego automatycznej postinkrementacji, po czym następuje powrót do przerwanego wątku (instrukcja RET lub RETI odblokowujące system przerwań). To oczywiście skrajny przykład, ale pokazujący, że być może przerzucenie na sprzęt zapisywania stanu całego procesora jest przesadą. Architektura oraz lista instrukcji procesora muszą być jednak przemyślane tak, by wspierały takie rozwiązania. Co więcej, PC nie musi być zapisywany na stos.Jeśli zrobisz rejestr leżący tuż obok PC to tam możesz zapisać jego aktualną zawartość i już w następnym cyklu maszynowym zaadresować pamięć wektorem pierwszej instrukcji ISR. Wtedy to programiście (ew.kompilatorowi) zostawiasz decyzję co do zapisu kontekstu na stos. I znów: lista instrukcji musi to wspierać, bo program musi mieć dostęp do rejestru shadow-PC aby jego zawartość móc przesłać gdzieś w bezpieczne miejsce. Ten sam mechanizm, ale w drugą stronę można wykorzystać do powrotu: jakaś instrukcja zdejmuje ze stosu (lub z innego bezpiecznego miejsca) rejestr shadow-PC a właściwy RET przeładowuje to do PC. Co więcej (po raz drugi) operacje na tym drugim rejestrze nie muszą być rzeczywistą wymianą danych między PC a shadow. Wystarczy przecież zmieniać jednobitową flagę określającą który z tych rejestrów jest aktualnie prawdziwym licznikiem rozkazów. Idźmy dalej: w 8035 mamy 12-bitowy PC a 8-poziomowy stos jest umieszczony w 8-bitowej pamięci więc podczas cyklu potwierdzania przerwania procesor zapisuje nie tylko PC ale też 4 bity (flagi) stanu ALU (tzw. PSW - Processor Status Word). Sprzęt robi zatem tylko to co niezbędne a program może zrobić resztę, np. zachować akumulator. Co ciekawe mamy tam 2 banki po 8 rejestrów przełączanych jedną instrukcją więc ISR może błyskawicznie zmienić sobie kontekst na bank alternatywny, podziałać na nim a przed powrotem (specjalna instrukcja RETN) odtworzyć flagi powracając tym samym do oryginalnego banku rejestrów. I to wszystko bez użycia stosu. Co prawda zmusza to do jednopoziomowego systemu przerwań (choć są mechanizmy by to rozszerzyć), ale w małych procesorkach to się sprawdza. Potwierdzeniem tego jest rozwiązanie zastosowane w następcy, czyli 8051. Tam, dostaliśmy już 4 banki rejestrów także bardzo szybko przełączane, no i system przerwań ma 4 poziomy.. To tylko kilka przykładów na to jak bardzo architektura procesora musi być przemyślana i jak ściśle współpracuje z listą rozkazów. Robiąc taki projekt warto narysować sobie model sprzętu z punktu widzenia programisty: bez tych wszystkich strzałek, magistral czy multiplekserów. Mamy wtedy czysty obraz dostępnych rejestrów, mapę pamięci itp i wtedy porównać to z planowaną listą instrukcji, która nie powinna być kulą u nogi a szansą na sprawną realizację algorytmów. A żeby taką się stała trzeba zwyczajnie napisać trochę nietrywialnych funkcji/programów i zmodyfikować ja tak, by w danej architekturze była optymalna. W prostszych przypadkach wystarczy mieć trochę doświadczenia bo na tym najniższym poziomie procesory robią jakieś bardzo podstawowe rzeczy: przesuwają bloki pamięci, porównują je, liczą arytmetykę wielokrotnej precyzji, odliczają pętle for z liczników czy wołają podprogramy z przekazywaniem do nich parametrów i odzyskiwaniem wyników. W każdym z takich przypadków architektura i lista instrukcji muszą ze sobą ściśle współgrać. BTW: Osobnym problemem jest właśnie. przekazywanie argumentów do funkcji. Nie licząc jakichś egzotycznych pomysłów, robimy to przez stos albo przez rejestry. W każdym z przypadków potrzebne są instrukcje do sprawnej obsługi "stałych fragmentów gry": tworzenia, dostępu do i niszczenia ramek na stosie. W przypadku stosu przydaje się adresowanie bazowe z możliwością albo adresowania względem SP (np. coś w rodzaju MOV A, [SP+6] ) albo przeładowania jego zawartości do któregoś z rejestrów ogólnego przeznaczenia. Jest to szczególnie ważne w procesorach z małą liczbą rejestrów. Moim zdaniem minimalna architektura 8-bitowej maszynki to coś w rodzaju Motoroli 6800 (dwa akumulatory i jeden rejestr indeksowy) albo któryś z jego "dzieci" np. MOS Technology 6502 (jeden akumulator ale za to dwa rejestry indeksowe). Nie ma co wyważać dawno otwartych drzwi i po prostu podglądać jakie sprytne rzeczy powymyślali projektanci tamtych układów. W szczególności chodzi mi o tryby adresowania: stronę zerową i dwie zupełnie różne koncepcje używania rejestrów indeksowych.
  23. Dzięki za odpowiedzi. Zapytałeś w mailu jaką książkę polecam żeby o procesorach dowiedzieć się wiecej, ale odpowiem tutaj. Być może jest więcej chętnych do poszerzenia swojej wiedzy w tym temacie i ktoś tam jeszcze wynajdzie tę staroć na aukcji. Myślę, że swoją zabawę powinieneś zacząć od przeglądu istniejących proocesorów. I to nie od spisania typów i poczytania o nich w Wikipedii, ale od zdobycia jak najbardziej szczegółowych informacji o nich i przymierzeniu się do pisania programów w asemblerach tych układów. To daje niesamowitą wiedzę o tym jak procesor może/powinien być zbudowany i co musi mieć a bez czego można się obejść. Dobrą książką jest cegła Klingmana "Projektowanie systemów mikroprocesorowych" - o ile pamiętam, bo zaczyna od podstaw i pokazuje jak projektować sprzęt dla bardzo starych konstrukcji typu 8008, 6502 czy 8080. Przy okazji omawia je szczegółowo, także przez porównywanie pewnych podsystemów (pamięć, I/O) ze sobą. Na takich przykładach nauczysz się najwięcej. Wbrew pozorom te klasyczne już dzisiaj projekty były bradzo dobrze zrobione. Listy instrukcji były wysoce optymalne (także ze względu na ograniczoną liczbę tranzystorów) a rożnorodność architektur daje dobry przegląd tego jak można podejść do realizacji bądź co bądź tego samego: do stworzenia kompletnej (wg Turinga) maszyny cyfrowej. Możesz zacząć od prymitywnego 4004 - jest na jego temat mnóstwo wiedzy w sieci, łącznie z modelami w VHDL czy Verilogu, symulatorami na PC, asemblerami itp. To samo o 8080 - koniu pociągowym wczesnej mikrokomputeryzacji świata. Musisz mieć to w małym palcu, żeby rozumieć jak architektura przekłada się na listę instrukcji i możliwości operacyjne procesora. Dopiero potem przyjdzie czas na peryferia czy co bardziej skomplikowane bloki jak MMU, DMA, system przerwań wektoryzowanych czy instrukcje/stany uprzywilejowane. Procesory dzisiaj to nieprawdopodobnie skomplikowane maszyny, ale żeby je zrozumieć i móc projektować swoje własne (a nie tylko błądzić na oślep mozolnie ucząc się na własnych błędach) musisz poznać te pierwsze. Proponuję, byś po zgromadzeniu informacji na temat jakiegoś 4-bitowca (może być 4004 lub 4040) i kilku 8-bitowych kostek (np. 8008, 8080 i powiedzmy 6800 lub 6502) spróbował napisać w ich asemblerach jakieś wspólne funkcje np. konwersję bin->ASCII, jakieś sortowanie (tablicy liczb a może słów), wyszukiwanie wzorca (parsowanie) linii tekstu czy nawet zegarek z datą. To z pewnością otworzy Ci oczy na to jak pisze się kod dla typowego procesora i pokaże jakie dana konstrukcja ma wady a jakie zalety. Poznasz tryby adresowania, ich siłę lub ból braku tych co fajniejszych. Do tego możesz dorzucić jakis jednoukładowiec (np. pierwszy mikorokontroler 8035/8048 albo od razu 8051) plus coś "nowszego" z architekturą RISC np. jądro AVR lub któryś wczesny PIC. Celowo nie piszę tu o dużych maszynach typu 8086 czy ARM, bo to już wyższa szkoła jazdy a bez podstaw wyssanych z klasyki nic Ci nie da wykonywanie 100 milionów instrukcji na sekundę. Znając wiele standardowych architektur będziesz miał szansę świadomej oceny: co się udało a co było takie sobie. Co było pomysłem wyprzedzającym konkurencję a co smutnym ograniczeniem koniecznym ze względu na ówczesną technologię. Dopiero wtedy będzie można rozmawiać o własnych, niestandardowych pomysłach czy ciekawych rozszerzeniach. Teraz nawet trudno mi komentować to co napisałeś, bo np. jak zrozumieć zdanie: Przecież z przerwaniem ma tu coś wspólnego jedynie "skok do podprogramu" - wymuszony przez sekwencer i właśnie o to pytałem, jak chcesz to zrealizować a dokładniej gdzie chcesz zapamiętać ślad. Po zapamiętaniu kontekstu (cokolwiek to w danej architekturze znaczy) i przeładowaniu PC (jakkolwiek się to w danej architekturze wykona) procesor kontynuuje pracę jakby nic się nie stało a jedynym zadaniem logiki było bezbolesne "wstrzyknięcie" w ciąg wykonywanych instrukcji właśnie skoku ze śladem (CALL?). Ew. możesz sprzętowo blokować system przerwań dzięki czemu masz natywnie tylko jeden ich poziom. Tak czy tak sensowny procesor (czyli nie akademickie rozważanie o bramkach tylko wykonujący rzeczywiste programy układ) powinien mieć jakiś stos a ten wiąże się tak z prodprogramami jak i z systemem przerwań. Możesz to rozdzielić i skoki ze śladem zrobić bardzo proste (np. tylko shadow register dla PC) z programowym wsparciem zachowywania/odtwarzania kontekstu i nawet programowym wskaźnikiem stosu, a możesz w sprzęcie zaszyć dużo więcej. To Twoje decyzje, ale nie wiedząc jakie są w ogóle są możliwości jak możesz je podejmować świadomie? Były procesory niemające przerwań wcale (4004), były takie ze sprzętowym stosem o zaledwie kilku poziomach i to przeznaczonym jedynie na adresy powrotu (8035/8048), były takie ze stosem ograniczonym do małego obszaru RAMu (8051) i były takie z pełnym, 16-bitowym SP (8080 i następcy). Jedne miały tylko podstawowe tryby adresowania (8008) a inne miały ich całą feerię (Z-80), mimo że i jedne i drugie były stosunkowo prymitywne i wolne. Na pewno zauważysz po bliższym przyjrzeniu się, że projektanci nawet tych prostszych chipów zostawiali nam furtki dodając specjalne instukcje umożliwiające programową emulację brakujących trybów. I to było piękne.. Dobra, znowu popłynąłem.. sorki za dłużyzny. Także, tego, do roboty
  24. Ma kilka pytań: Przede wszystkim dziwne jest ścisłe powiązanie (a raczej brak wyraźnego rozgraniczenia) procesora i peryferiów. Mam nadzieję, że nie zrobisz osobnych instrukcji do komunikacji np. z rejestrami UARTa czy LED a będzie to jakoś ujednolicone, np. przez użycie osobnej przestrzeni adresowej banku rejestrów I/O. Z punktu widzenia struktury projektu chyba wygodniej byłoby wydzielić duże bloki właśnie typu procesor, peryferia (UART, LED, ew. kontroler przerwań, może w przyszłości jakieś timery itp) czy pamięć choćby po to, by po sprzęgnięciu je jakimiś dobrze określonymi magistralami można było w łatwy sposób dodawać/usuwać bloki. Obecnie to wygląda na słabo modyfikowalne. Dlaczego aby zapisać coś do B trzeba przepuścić to przez A? Wydaje się to dziwne. Nie możesz przez to używać ALU do innych rzeczy np. inkrementacji/dekrementacji B czy ew. innych przyszłych rejestrów. Czy jest to procesor 4-, 8-, czy 16-bitowy? Jak szeroką przewidujesz pamięć programu (albo jak długi kod operacyjny instrukcji)? Czy będziesz skupiał się na szybkości wykonywania instrukcji (a więc rozbudowie logiki) czy raczej na zajętości FPGA (czyli raczej układ mikroprogramowany)? Wydaje się, że system przerwań powinien być ściśle powiązany z głównym sekwencerem a tego tu nie widać. Czy przyjęte przerwanie będzie jakoś sprzętowo zachowywać kontekst? Bez możliwości zachowania gdziekolwiek choćby PC przerwania trochę nie mają sensu. Jak będzie wyglądać sekwencja porzucenia głównego wątku i rozpoczęcia wykonywania ISR? Czy będą wektory w RAMie? Czy ustalone punkty wejścia? Czy wszystko wchodzi przez jeden adres? Czy będzie stos a jeśli tak to jaki? W RAMie (wskaźnik stosu?) czy sprzętowy zestaw rejestrów LIFO? A może jeden rejestr śladu? Tego też nie widać. Jakie tryby adresowania przewidujesz? Nawet najprostsze konstrukcje ogromnie zyskują gdy mogą adresować pamięć pośrednio przez rejestr (indirect) - dopiero wtedy, gdy można wyliczać adresy daje się sensowne obsługiwać tablice itp struktury danych. Czy jakoś to przewidujesz? Moim zdaniem różnorodność metod adresowania jest nawet ważniejsza niż rozbudowane funkcje ALU. A propos: czy mógłbyś przedstawić proponowaną listę instrukcji wraz z możliwymi trybami adresowania? Czy przewidujesz jakieś instrukcje zatrzymujące CPU choćby do przyjścia przerwania (np. IDLE) bo wiesz, obniżanie poboru mocy to dziś priorytet. Czy mógłbyś jakoś pokrótce odpowiedzieć na powyższe zanim zrealizujesz ten projekt? BTW: Przerwania rzeczywiście dzielimy na zewnętrzne i wewnętrzne, ale to nie jest tak jak opisałeś. Zewnętrzne to wszystkie te , które przychodzą ze źródeł niezależnych (asynchronicznych) od programu: peryferia, piny I/O itp a wewnętrzne to te, które zgłasza sobie niejako sam procesor: dzielenie przez zero, naruszenie ochrony pamięci, nieprawidłowy kod operacyjny instrukcji czy jawne wykonanie instrukcji przerwania (np. zmieniającego poziom przywilejów lub robiącego breakpoint).
  25. Czas propagacji komparatora w takiej aplikacji jest sprawą dziesiątej ważności. Napędy, mechanika i procesy zachodzące w robocie są kilka rzędów wielkości wolniejsze niż jakikolwiek komparator a poza tym czasy reakcji tego typu układów zależą od wielkości przesterowania czyli różnicy napięć jakie są porównywane. Nigdy nie sugeruj się liczbą przeczytaną na pierwszej stronie danych katalogowych a już na pewno nie tą wziętą ze strony sklepu. Po prostu jeśłi chcesz mieć obiektywną ocenę, musisz szukać głębiej. Nie twierdzę, że 311 nie jest szybki, ale nie o to tu chodzi. W tym układzie dużo ważniejsze są np. zakresy napięć zasilania oraz zakresy napięć wejściowych. Te drugie podawane są zwykle jako minimalna odległość od szyn zasilania i jeśli np. czytasz, że od minusa musi być 0.5V a od plusa 2V to z 5V zasilania jakie tu przewidziałeś zostaje Ci jedynie 2.5V i to w dość dziwnym zakresie 0.5-3V, jakiego Twój czujnik opto nie jest w stanie zapewnić. Kolejna sprawa to wyjście. Masz emiter tranzystora podłączony do masy i kolektor którego nic nie ciągnie do plusa. Skąd weźmiesz stan wysoki? Możesz powiedzieć, że właczysz pullup w procesorze, ale wartość takiego podciągu jest nieznana. Niestety w układzie z histerezą jest ona kluczowa więc siła z jaką komparator wystawia swoje jedynki i zera jest ważna. Co więcej, histereza powstaje przez połączenie dodatniego sprzężenia zwrotnego (to ten 1Meg) z impedancją/rezystancją widzianą na wejściu komparatora. Brakuje mi tu opornika szeregowego stabilizującego tę wartość i umożliwiającego policzenie szerokości histerezy. Trochę wygląda jakbyś o tym zapomniał albo przerysował komparator z innego schematu nie do końca rozumiejąc rolę poszczególnych elementów. Tu masz przykład nowoczesnego komparatora za 5zł. Jest poczwórny (ale także w wersjach x2 i x1), ma wbudowaną histerezę, wyjścia dwustanowe jak bramka logiczna i pracuje z napięciami wejściowymi od 0 do swojego Vcc: https://www.tme.eu/pl/details/mcp6544-i_p/komparatory-tht/microchip-technology/ Nie musisz bawić się z opornikami zarówno w sprzężeniu zwrotnym jak i na wyjściu. Wstawiasz i działa. Filtr RC - jeśli nie musi być szybki wystarczy, by dobrze tłumił składowe AC sygnału PWM. Układ taki jak narysowałeś to tzw. filtr pierwszego rzędu, tłumi coraz lepiej powyżej swojej częstotliwości środkowej, wynoszczącej f0 = 1 / (2*PI*R*C) A coraz lepiej oznacza, że tłumienie rośnie o 6dB z każdą oktawą. Czyli jeśli zaprojektujesz filtr na f0 = 80Hz to do tych 80Hz będzie płasko, częstotliwość 160Hz będzie tłumiona 2 razy, 320Hz 4 razy itd.. W sygnale PWM nie masz składowej niższej niż podstawowa a tej jest najwięcej i to tej częstotliwości głównie oczekujesz w "śmieciach" wyjściowych. Przemyśl więc jaki bedzie Twój PWM i jaką wielkość "schodków" na wyjściu filtra akceptujesz (bo zero to nie będzie nigdy) a potem policz co trzeba lub.. zadaj kolejne pytania.
×
×
  • Utwórz nowe...