Systemy wbudowane :: Mikrokontrolery :: Potrzebne oprogramowanie i sprzęt: :: Kompilacja (programów w C dla AVR): :: Debugowanie, ...: :: Nut/OS :: ARM :: DSP - przetwarzanie sygnałów :: Linki i moje projekty :: Zwiększamy ilość wejść/wyjść czyli magistrale :: Interfejsy elektroniki :: Zestawienie sieci czujnikowych :: konwersje

Układy programowalne

Obecnie bardzo istotną rolę w elektronice (cyfrowej) odgrywają układy programowalne. Można wśród nich spotkać zarówno bardzo proste układziki, jak i bardzo rozbudowane systemy (często oparte o architekturę ARM, MIPS lub x86 i dysponujące znaczną mocą obliczeniową).

Zasadniczo należy wyróżnić dwa rodzaje ukłądów programowalnych:

Wśród układów o programowalnej strukturze wyróżnić należy:

Wśród układów mikroprocesorowych wyróżnić należy:

Współcześnie w przypadku układów typu PLD (podobnie zresztą jak ma to miejsce na rynku mikrokontrolerów) ważniejsza jest struktura i możliwości danej serii układów czy konkretnego przedstawiciela niż podział na grupy takie jak FPGA, CPLD, ... . Możliwa a często konieczna w jednym systemie jest współpraca kilku wyżej przedstawionych technologi. Szczególnie interesującym wydaje się pomysł zastosowania FPGA (bez pamięci stałej, czyli konfigurowanego niezależnie po każdym restarcie) jako rekonfigurowalnego układu wspierającego system mikroprocesorowy (mikrokontroler czy nawet coś klasy PC), który byłby każdorazowo reprogramowany pod bieżące potrzeby przez zarządzający nim system procesorowy.

Systemy wbudowane

Układy programowalne powszechnie stosowane są także w systemach wbudowanych oraz dostępnych na rynku urządzeniach elektronicznych. Przy wyborze takich urządzeń (zwłaszcza w przypadku: telefonów IP, routerów/bramek IP, kamer IP, rejestratorów cyfrowych, odtwarzaczy, tunerów dvb, switchy zarządzanych, sterowników PLC/sterowników automatyki domowej, itp.) warto zwrócić uwagę na dostępność źródeł programu w oparciu o który działa dane urządzenie. Często jest to nawet istotniejsze od schematów elektronicznych urządzenia (gdyż stosowanie układów programowalnych dość radykalnie schematyzuje i uprasza budowę urządzeń), ale miło by było oczywiście jakby także hardware był "open source".

Na rynku dostępnych jest również bardzo wiele rozwiązań deweloperskich opartych na płytce z procesorem ARM (ew. MIPS) i działającym na niej systemem Linux (i nie tylko). Pozwalają one na dość łatwe i tanie budowanie różnego rodzaju systemów monitoringu i automatyki opartych na TCP/IP (np. poprzez dodanie peryferiów po I2C lub USB). Pewną niedogodnością takich rozwiązań w stosunku co do dedykowanych platform rozproszonego wejścia wyjścia, czy też profesjonalnych sterowników jest trudność w zapewnieniu estetyki podłączeń kabelkowych takiego systemu. Natomiast pod względem elastyczności, możliwości i dostosowania do potrzeb danego zagadnienia często przewyższają one wielokrotnie droższe rozwiązania profesjonalne.

W temacie dostępności tego typu rozwiązań swego rodzaju rewolucja rozpoczęła się wraz z projektem OpenWrt i routera Linksys WRT54G w 2003 roku. Udostępnienie zgodnie z wymogami GNU GPL opartych na Linuxie źródeł tego routera pozwoliło na tworzenie alternatywnych wersji jego oprogramowania, o znacznie większych funkcjonalnościach niż oryginalne. W następstwie tego alternatywne wersje firmware pojawiały się dla coraz to większej gamy urządzeń. Na rynku także przybywało innych rozwiązań opartych na otwarte oprogramowanie. Niestety często nie udostępniających źródeł sterowników do wykorzystywanego sprzętu, lub też na tyle skutecznie blokowanych że nie możliwe okazywało się uruchomienie na nich alternatywnego firmware. Niekiedy także z powodu zbyt wysokiej ceny danego sprzętu lub jego małej popularności nie doczekiwał się on otwartego systemu.

Kolejnym etapem tej rewolucji było wypuszczenie w 2012 roku Raspberry Pi, który zapoczątkował kolejny etap tej rewolucji. Po jego sukcesie masowo zaczęły pojawiać się inne platformy deweloperskie oparte o System-on-a-chip (typowo z rdzeniem ARM) deklarujące wprost wsparcie dla Linuxa (a także innych systemów FLOSS). Zdecydowanej poprawie uległa ich dostępność handlowa (dość szeroki wybór alternatywnych rozwiązań, brak konieczności szukania czy dany model da się przeflashować alternatywnym firmware, etc), cenowa (kompletny system komputerowy za mniej niż 100PLN) oraz użytkowej (dość przyzwoity poziom wsparcia, dokumentacji, etc).

Oprócz, wspomnainego już, znanego chyba wszystkim Raspberry Pi, wśród tego typu systemów deweloperskich należy wymienić:

Wartym uwagi są także układy konwersji USB na UART, inne protokoły lub GPIO, w szczególności FT4232 pozwalający uzyskać 4 interfejsy z których każdy może zostać skonfigurowany i użyty niezależnie jako: RS232, RS485/RS422, I2C, SPI, JTAG, GPIO. Niestety układy FTDI dostępne są tylko do montażu powierzchniowego, ale z pomocą przychodzą stosowne moduły (np. MMusb4232H). Układ może być obsługiwany przez standardowe sterowniki w jądrze, własne sterowniki w jądrze oraz libusb.

Zobacz także: ewolucja koncepcji projektów inteligentnego domu, DVB STB: Enigma2, Rescue Avtech KPD674 after firmware upgrade fail, Open Hardware, Open Graphics Project, OpenSPARC, RepRap, OpenMoko, LEON.

Komputery przemysłowe

Nazwą tą określa się systemy wbudowane stosowane w różnego rodzaju sterownikach, kontrolerach itp. Rozwiązaniem spotykanym w zasadzie tylko w tego typu systemach jest architektura oparta o karty procesorowe lub wręcz komputery jedno-płytkowe (SBC) i płyty główne zawierające wyłącznie magistralę - backplane. Pewnym szczególnym rodzajem SBC są systemy "computer on module". Warto tu wspomnieć iż w rozwiązaniach przemysłowych nadal często stosuje się standard magistrali ISA wyparty prawie całkowicie z komputerów domowych ze względu na zbyt małą prędkość. Na koniec należy jeszcze wspomnieć iż rozwiązania "przemysłowe" przystosowane są często do zasilania niskonapięciowego, wykonywane są często także w różnych wariantach obudów - rack 19", 10", szyna DIN, montaż naścienny, itd.. Zobacz także: PC/104, CompactPCI, PXI, VMEbus, VXI, PICMG, KIM-1, ETX (form factor), COM Express, XTX.

Mikrokontrolery

mikrokontrolery są to programowalne, scalone układy cyfrowe integrujące w sobie jednostkę centralną (CPU), pamięć (zarówno operacyjną jak i służącą do przechowywania programu oraz danych) oraz układy wspomagające takie jak przetworniki analogowo-cyfrowe, ... .

W dziale tym zajmiemy się głównie układami opartymi na mikrokontrolerach AVR oraz programowaniem tych układów w C (z elementami asemblera). Na wstępie zachęcam do zapoznania się z instrukcją modułu zawierającego mikrokontroler ATMega128, dodatkowy RAM (z zewnętrznym kontrolerem pamięci) oraz kontroler ethernetowy: MMnet02 (zwłaszcza opis działania kontrolera pamięci i metody podłączenia do wyświetlacza LCD - uświadamia też pewne aspekty działania PC). Zachęcam też do zajrzenia do artykułów o podstawach programowania w C i C++.

Przy projektowaniu układów z mikrokontrolerami należy:

Warto także bazować w swoich projektach na kilku mikrokontrolerach z jednej rodziny - w przypadku nie seryjnej produkcji oszczędności z zastosowania bardzo małego mikrokontrolera zostaną zatarte "kosztami" związanymi z trudnościami w jego użyciu (brak pinów do debugowania, mała pamięć programu, ...) oraz związanymi z rozwijaniem projektów na różnych mikroprocesorach (bo do kolejnego był już za mały). Osobiście polecam za minimum przyjąć Atmega8 (a jeżeli jest nie wystarczający to Atmega16). Niestety niektóre z starszych, porzuconych projektów przedstawionych na stronie są niezgodne z przedstawionymi wytycznymi dotyczącymi projektowania układów bazujących na mikrokontrolerach.

Potrzebne oprogramowanie i sprzęt:

Kompilacja (programów w C dla AVR):

Kompilujemy i linkujemy: avr-gcc -mmcu=atmega128 -Os -ggdb plik_zrodlowy.c -o plik_wynikowy.o
Tworzymy plik hex:avr-objcopy -O ihex plik_wejsciowy.elf plik_wynikowy.hex

Debugowanie, ...:

O debugowaniu, dezasemblerowaniu i symulacji z wykorzystaniem narzędzi linuxowych napisałem w "Debugowanie (gdb)". Jednak opisany tam program do symulacji nie jest jeszcze idealny i może się zdarzyć że nie będzie działał poprawnie, drobne problemy miałem też z jtag. Przy szukaniu błędów w programie uruchamianym już w układzie bardzo przydatny jest port szeregowy przez który program może podawać co aktualnie robi, a my możemy wpływać na jego działanie. Przykłady wykorzystania portu szeregowego można zobaczyć m.in. w moim projekcie "Sterownik ogrzewania akwariowego". Poniżej przykład komend potrzebnych/przydatnych do debugowania przez jtag:

avarice --debug --part atmega128 --jtag /dev/ttyS0 :4242
avr-gdb simple.elf
	# target remote localhost:4242
	# break *0xaddr
	# backtrace
avr-objdump -d simple.elf
avarice --erase --program --verify --file simple.elf --jtag /dev/ttyS0

Nut/OS

Jednym z projektów dotyczących programowania mikrokontrolerów jest dystrybuowany na zasadach licencji typu BSD system czasu rzeczywistego z stosem TCP/IP - Nut/OSkopia lokalna. Poniżej zamieszczę krótki poradnik dotyczący wykorzystania tego systemu w wspomnianym wyżej module sieciowym Mmnet02.

  1. instalujemy na komputerze Nut/OS - opis instalacji Nut/OS dla Debian
  2. budujemy biblioteki oraz drzewo przykładowych programów (np. przy pomocy nutconf - do NutOSa załączone są pliki opisujące konfigurację dla Mmnet02, w przypadku problemów z ściezkami warto zajrzeć do opcji programu)
  3. w katalogu w którym utworzyliśmy drzewo z przykładowymi programami tworzymy podkatalog na nasz projekt i kopiujemy do niego plik Makefile np. z basemon i dostosowywujemy do swoich potrzeb (nazwę projektu, listę plików źródłowych, bibliotek itp.)
  4. w katalogu naszego projektu tworzymy program ... zachęcam do skorzystania na początek z stworzonego przeze mnie nut_first.c oraz do zapoznania się z przykładami w wygenerowanym drzewie (m.in. serwer http, ftp, ...).

ARM

ARM czyli Advanced RISC Machine jest zaawansowaną 32-bitową architekturą procesorów (mikrokontrolerów). Procesory tego typu bardzo często wykorzystywane są w systemach wbudowanych, routerach sprzętowych, telefonach IP itp.

Dużą zaletą w programowaniu większych układów ARM (a także innych tego typu mikrokontrolerów, procesorów, układów system-on-chip, np. MIPS) jest to iż często posiadają one normalny system - dedykowana/okrojona (np. OpenWRT), albo nawet typowa (np. w Raspberry Pi) dystrybucja systemu Linux. Umożliwia to bardzo wygodne debugowanie kodu sterującego tworzonego na taką platformę, a także tworzenie go z wykorzystaniem standardowych posixowych rozwiązań (system plików, sieć, ...).

DSP - przetwarzanie sygnałów

Procesor DSP są procesorami zoptymalizowanymi do przetwarzania ucyfrowionych sygnałów. Charakteryzują się możliwością równoczesnego wykonywania kilku operacji w ramach jednej instrukcji, sprzętowymi układami mnożącymi lub mnożąco-akumulującymi, rozdziałem (możliwością równoległych dostępów) pamięci próbek i współczynników. Do najistotniejszych cech charakteryzujących procesor sygnałowy od strony programistycznej (znaczną część tych cech można także rozpatrywać porównując architektury procesorów ogólnego przeznaczenia) należą:

W wspomnianym przetwarzaniu sygnałów coraz istotniejszą rolę zaczynają odgrywać architektury wielordzeniowe, gdzie grupy rdzeni funkcjonują w trybie SIMD lub SPMD. Do głównych przedstawicieli tego nurtu należą procesory CELL i procesory graficzne GPU. Tendencja ta wpływa także na wzrost znaczenia algorytmów umożliwiających prowadzenie obliczeń w sposób równoległy (np. algorytmów kratowych).

Linki i moje projekty

Zachęcam także do zapoznania się z moimi projektami związanymi z programowaniem mikrokontrolerów: powiadamiacz o IM dla jabberd2 (AVR NutOS), sterownik ogrzewania (AVR), sterownik oświetlenia (AVR), centralka alarmowa.

Zobacz w Sieci: programowanie mikrokontrolera ATmega32 (m.in. opis liczników, komparatora, ...), radzio.dxp.pl, mikrokontrolery.net, Zbigniew Czaja - strona domowa, Craft (gra wideo na ATmega88), Zablokowany ATMEGA8.

Zwiększamy ilość wejść/wyjść czyli magistrale

Typowe mikrokontolery posiadają pewien zasób GPIO i innych interfejsów wbudowanych w siebie, w niektórych sytuacjach okazuje się on jednak niewystarczający - można wtedy podłączyć poprzez jakąś magistralę układy zwiększające ilość wejść/wyjść lub zastosować kilka mikrokontrolerów (często również komunikujących się poprzez jakąś magistralę). Zasadniczo mamy do wyboru:

Najprostsza w użyciu wydaje się magistrala równoległa bez multipleksowania szyny adresowej i danych (ustawienie adresu, zapis danych sterowane dwoma sygnałami), jednak wymaga ona stosowania dużej ilości połączeń między modułami (typowo minimalistycznie: 8 bitów szyny danych, 3-8 bitów szyny adresowej, 2 sygnały sterujące). W przypadku podziału projektu na moduły nastręcza to problemy z ich łączeniem - można/trzeba kombinować z tworzeniem jakiegoś backplane i stosowania jakiś złączy (np. złączy krawędziowych na PCB), ale jest to dość kłopotliwe w realizacji i przy małych modułach (a tym bardziej niewielkiej ich liczbie) trochę dziwne.

Przy konieczności dodania niewielkiej ilości modułów wejść wyjść mogą się sprawdzić rejestry przesuwne, ale w odróżnieniu od magistral szeregowych rozwiązanie to nie skaluje się dobrze.

Najbardziej elastycznym (ale i dość drogim) rozwiązaniem jest zastosowanie magistral szeregowych (zasadniczo będących bardziej rozwiniętą formą rejestrów przesuwnych). Na przykład wspomniana magistrala I2C umożliwia podpięcie na pojedynczej linii kilkunastu układów, umożliwia multipleksowanie swojej linii celem zwiększenia pojemności i zapewnia 8 bitowe adresowanie układów na magistrali (realizowane w protokole transmisji - bez dodatkowych połączeń w tym celu).

Podobnym zagadnieniem jest podłączanie klawiatur, ale tutaj możemy potraktować ją jako matrycę przełączników - i zasilać tylko kolejno pojedyncze rzędy szukając kolumny która jest zwarta (patrz manipulator alarmowy), w przypadku gdy dopuszczamy równoczesne wciśnięcie kilku z tych przełączników należy stosować diody uniemożliwiające przeniesienie potencjału zasilonego wiersza poprzez linie kolumny do innych rzędów.

Interfejsy elektroniki

Praktycznie każdy z systemów elektronicznych korzysta z jakiś interfejsów komunikacyjnych. Podstawowym interfejsem jest magistrala (szyna danych i adresów), jej szczegółowe parametry zależą od konkretnego systemu. Szyna systemowa może składać się z osobnej szyny danych (linie oznaczane zazwyczaj D0-Dxx, gdzie xx to bitowość szyny danych) i adresowej (linie oznaczane zazwyczaj A0-Ayy), bądź wspólnych linii (AD) multipleksowanych osobnym sygnałem (AEN) informującym czy aktualnie nadawany jest adres czy dane. Szyna taka zawiera także linie informujące o przeprowadzanej operacji (WR i RD) ich funkcja może być także połączona w jednej linii. Któreś z sygnałów (AEN, WR, RD, lub jakieś inne) pełnią rolę tzw. strobu (zmiana ich stanu decyduje o rozpoczęciu ważności danych / adresów na liniach). W wielu mikroprocesorach szyna dostępna jest w dwóch trybach - pamięci i urządzeń I/O (o trybie pracy decyduje osobna linia). Niekiedy można się spotkać z memory maped I/O czyli udostępnianiem urządzeń w przestrzeni adresowej pamięci (nawet pomimo że architektura wspiera rozdzielenie przestrzeni I/O i pamięci). Warto wspomnieć także o technice DMA umożliwiającej zlecenie wykonania operacji na szynie (np. kopiowania z pamięci do urządzenia) zewnętrznemu kontrolerowi (tak aby nie blokowały one procesora). Zauważalne jest obecnie odchodzenie od koncepcji magistrali (szyny systemowej) na rzecz łączy szeregowych punkt-punkt lub rozwiązań sieciowych opartych na przekazywaniu pakietów.

Dostęp do pamięci czy urządzeń podłączonych do szyny odbywa się za pomocą ich adresów - logika urządzenia musi kontrolować czy w danym cyklu szyny był wywołany jej adres (odpowiednia kombinacja bitów na szynie adresowej) czy nie. W przypadku podłączania standardowych układów często logikę tą konstruujemy samodzielnie i wykorzystujemy wejście chip select /chip enable (CS/CE) do aktywacji lub dezaktywacji układu. Urządzenia nadawcze powinny być wyposażone w bufory trój-stanowe, które dopóki dane urządzenie nie zostanie wywołane do odczytu odłączają je od szyny danych. Urządzenia odbiorcze powinny posiadać rejestry zapamiętujące stan linii danych (interesujących nas bitów z tej linii) w chwili strobu zapisu. Istotne jest także uwzględnianie czasu potrzebnego na skonsumowanie / bądź wystawienie na szynę odpowiednich danych (czas ten musi upłynąć zanim do układu peryferyjnego/pamięci będziemy mogli zapisać kolejną wartość lub zanim dane wystawiane przez układ na liniach danych będą ważne). Niektóre z urządzeń potrafią sygnalizować zakończenie bardziej czasochłonnych operacji (np. pamięci EEPROM dopóki nie zakończą zapisu przy odczycie wystawiają zaprzeczenie zapisywanych danych na D7 lub zmieniają przy każdym kolejnym odczycie wartość D6).

Również często są wykorzystywane standaryzowane interfejsy (głównie szeregowe) takie jak:

Istotnymi interfejsami komunikacyjnymi systemów elektronicznych są współcześnie sieci. Rozwiązania sieciowe mogą wykorzystywać jako warstwę sprzętową któryś z opisanych powyżej interfejsów szeregowych (w zasadzie poza UART i po części SPI wszystkie one są sieciami opisującymi 1 i 2 warstwę wg. modelu OSI) albo posiadać własny standard interfejsu (np. światłowodowy, bezprzewodowy, wykorzystujący okablowanie energetyczne). Obecnie popularność Ethernetu staje się na tyle istotna iż zaczyna on wypierać popularne dotychczas standardy sieci przemysłowych służących do komunikacji pomiędzy sterownikami (fieldbus) takie jak: Interbus, Foundation Fieldbus, CC-Link. Ponadto zauważalna jest migracja wielu protokołów tego typu sieci (standardów nie definiujących warstwy fizycznej i łącza danych) w stronę wykorzystania Ethernetu czy nawet TCP/IP, za przykłady mogą posłużyć tutaj:

W tym miejscu należy też wspomnieć o protokołach używanych do udostępniania informacji przez różne systemy w sieciach TCP/IP takich jak:

W specyficznych zastosowaniach (np. motoryzacja) można spotkać wiele innych rozwiązań w mniejszym bądź większym stopniu zbliżonych do tu wymienionych.

Zestawienie sieci czujnikowych

warstwa opis warstwy
aplikacyjna inne / dane dane BACnet MS/TP P-Net Profibus inne / dane BACnet PTP M-Bus
transportowa
sieciowa
łącza danych format ramki komunikatu wraz z adresacją Modbus RTU Modbus ASCII IEC 60870
łącza danych format przesyłu bajtu UART
fizyczna standard elektryczny RS-485 inne RS-232 M-Bus

warstwa opis warstwy
aplikacyjna inne / dane DeviceNet CANopen inne / dane inne / dane inne / dane inne / dane LonWorks EIB / KNX
transportowa
sieciowa
łącza danych format ramki komunikatu wraz z adresacją CAN (ISO 11898) I2C / TWI 1Wire USB
łącza danych format przesyłu bajtu SPI
fizyczna standard elektryczny

warstwa opis warstwy
aplikacyjna inne / dane inne SNMP Modbus TCP BacNet IP KNXnet/IP Profinet
transportowa TCP / IP
sieciowa
łącza danych format ramki komunikatu wraz z adresacją Ethernet / inne Ethernet
łącza danych format przesyłu bajtu
fizyczna standard elektryczny

konwersje

Diagram prezentujący kierunki konwersji typowych interfejsów w systemie automatyki opartym na mikrokontrolerach:
POWIĘKSZDiagram prezentujący kierunki konwersji typowych interfejsów w systemie automatyki opartym na mikrokontrolerach
A także tabelaryczne zestawienie różnych wariantów konwersji (wraz z układami to realizującymi) interfejsów typowych dla elektroniki (typowych interfejsów mikrokontrolera) oraz popularnych sieci czujnikowych:

konwersja z (kolumny) / na (wiersze): I2C UART TTL GPIO, data_bus SPI
I2C / TWI / SMBus       CP2120
UART TTL MAX3107, SC16IS7?0   SC26C92 MAX310?, SC16IS7?0
RS232   MAX232, ...    
RS2485   SN75176, MAX485, ...    
GPIO, data_bus MCP2300?, PCF8574, PCA9554     MCP23S0?
Analog input/output PCF8591      
SPI SC18IS602      
1Wire DS2482 DS2480    
CAN warstwa fizyczna       MCP2515
warstwa łącza danych       MCP2515
LIN warstwa fizyczna   MCP2003    
warstwa łącza danych        
Mbus / Metter-Bus warstwa fizyczna   MSP430    

Zobacz także: SNMP-BACnet gateway, BACnet Stackkopia lokalna, libmodbuskopia lokalna.



Copyright (c) 1999-2015, Robert Paciorek (http://www.opcode.eu.org/), BSD/MIT-type license


Redystrybucja wersji źródłowych i wynikowych, po lub bez dokonywania modyfikacji JEST DOZWOLONA, pod warunkiem zachowania niniejszej informacji o prawach autorskich. Autor NIE ponosi JAKIEJKOLWIEK odpowiedzialności za skutki użytkowania tego dokumentu/programu oraz za wykorzystanie zawartych tu informacji.

This text/program is free document/software. Redistribution and use in source and binary forms, with or without modification, ARE PERMITTED provided save this copyright notice. This document/program is distributed WITHOUT any warranty, use at YOUR own risk.

Valid XHTML 1.1 Dokument ten (URL: http://www.opcode.eu.org/digital/programowalne) należy do serwisu OpCode. Autorem tej strony jest Robert Paciorek, wszelkie uwagi proszę kierować na adres e-mail serwisu: webmaster@opcode.eu.org.
Data ostatniej modyfikacji artykulu: '2016-05-03 08:54:00 (UTC)' (data ta może być zafałszowana niemerytorycznymi modyfikacjami artykułu).