Programowanie i integracja inteligentnego domu w języku C, C++, Object C na różne platformy soft&hard ware

Inteligentny Dom eHouse. Programowanie w językach C, C++, Object C pozwala na integrację inteligentnego domu eHouse z prawie dowolnym sprzętem i systemami operacyjnymi.
Jest to jeden z najbardziej niskopoziomowych języków programowania (w zasadzie drugi po assemblerze).

Dzięki temu, oprogramowanie pisane w dowolnych wariantach C jest:

  • Najszybsze z możliwych
  • Najmniej obciążające system mikroprocesorowy (procesor)
  • ma najmniejsze wymagania odnośnie wydajności i szybkości sprzętu, na którym pracuje
  • pozwala na łatwą adaptację w dowolnym systemie operacyjnym (w zasadzie każdy system posiada kompilator C) umożliwiający tworzenie oprogramowania na dowolną platformę
  • może pracować na dowolnym sprzęcie wyposażonym w procesor: komputery PC, mikro i mini komputery, płyty komputerowe, sterowniki mikroprocesorowe i mikrokontrolery

Aby ułatwić integrację sterowników inteligentnego domu eHouse z oprogramowaniem indywidualnym tworzonym przez użytkowników końcowych, vendorów, firm współpracujących – zamieszczamy szablony aplikacji do tworzenia oprogramowania w językach C, C++, Object C.

Daje to możliwość tworzenia oprogramowania na dowolne systemy operacyjne nawet bardzo egzotyczne:

  • Amiga (AmigaOS, AROS, MorphOS)
  • Apple (iOS, Mac OS, Apple DOS, ProDOS, Darwin, GS/OS, OS X, OS X Server )
  • Atari ST (Atari TOS, MultiTOS, FreeMiNT, MagiC)
  • Be (BeOS, BeIA , NewOS/Haiku, YellowTAB, Zeta)
  • DEC/Compaq (AIS, OS-8, RSTS/E, RSX, RT-11, TOPS, VMS/ OpenVMS)
  • Google (Android, Chrome OS)
  • IBM (OS/2, AIX, OS/400, OS/390, VM/CMS, DOS/VSE, DOS/360, OS/360, MFT, MVT, PC-DOS, SVS, MVS, TPF, ALCS, z/OS)
  • ICL (EXEC, JEAN, MINIMOP, GEORGE,KOZBER MANUL)
  • Microsoft (MS-DOS,PC-DOS, DR-DOS, FreeDOS, DOS, QDOS, Microsoft Windows: 1.0, 2.0, 3.x, 95/98/Me, CE i Mobile, NT/2000/XP/2003/FLP/Vista/2008/7/8, PetrOS, ReactOS)
  • Novell (Novell NetWare, Novell DOS)
  • NeXT / NeXTStep
  • Unisys ( MCP(Master Control Program), OS 2200)
  • UNIX ( AIX, Android, BSD, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, DesktopBSD, PC-BSD, bada, Darwin, Digital UNIX, HP-UX, iOS)
  • IRIX, OS X, Minix, OSF/1, SCO UNIX, Oracle Solaris (dawniej Sun Solaris, SunOS), Oracle OpenSolaris, OpenIndiana, Unix Wersja 7, QNX, Ultrix, Venix, Xenix, GNU/Linux,GNU/Hurd, Linux, Palm webOS
  • Real Time OS (LynxOS, FlexOS, OS9, Phoenix-RTOS, QNX, Nut/OS, RT-Linux, VxWorks, Suse Linux Enterprise Real Time, MicroC/OS-II)
  • Inne ( Agnix, Amoeba, AtariDOS, AtheOS/Syllable, Athene, Azure Operating System, Commodore DOS (zapisany w stacji dysków), Contiki, CP/J, CP/M, CROOK, eComStation, Egzekutor RTX, EMOS, EPOC32, GEM, GEOS, Inferno, IOS, iRMX, ISIS-II, Kylin, MenuetOS, Mikros, Multics, Palm OS, Quarn OS, SkyOS, Symbian, UDOS, Unununium, System V7)

Dotyczy to dowolnego sprzętu komputerowego, mikroprocesorów lub nawet mikrokontrolerów jednoukładowych 8-bitowych, 16, 32 bitowych.
Podstawową strukturą szablonu dla tworzenia oprogramowania dla sterowników są struktury zawierające statusy każdego typu sterownika eHouse1 w zależności od typu architektury

  • RS-485 (Magistrala szeregowa przemysłowa)
  • Ethernet (LAN)
  • CAN (Controller Area Network)

oraz rodzaju sterownika np.

  • RoomManager
  • HeatManager
  • ExternalManager
  • CommManager
  • LevelManager

Bez względu na medium transmisyjne i protokół transmisji:

  • RS-485 “Uart” eHouse 1
  • TCP/IP – Ethernet eHouse, eHouse4Can
  • UDP – Ethernet eHouse, eHouse4Can
  • Inne media transmisyjne

Pozwalają one na bezpośredni odbiór ramki zawierającej status danego typu sterownika i załadowanie go do struktury danych dla danego sterownika – bezpośrednie przekopiowanie bufora pamięci bez dekodowania informacji.
Struktury umożliwiają automatyczne dekodowanie odebranej ramki transmisyjnej i przyporządkowanie do zmiennych struktury wliczając zmienne bitowe.
Definicja Unii zawierających struktury poszczególnych sterowników pozwala na przekopiowanie bufora pamięci odebranej ramki i załadowanie do elementu unii “data”. Dzięki czemu zapis ramki jest natychmiastowy, a w momencie odczytania elementów struktury następuje “automatyczne dekodowanie” informacji zawartych w strukturze.

Uwaga: zdefiniowane unie zawierające stan sterowników eHouse1 wymagają przekopiowania z przesunięciem (offsetem):
1 – dla wybranego normalnego adresu, Ramka: {size}[ehouse1status struktura]
3 – dla wybranego rozszerzonego adresu (przy przesyłaniu także adresu własnego sterownika), Ramka: {size}{to addrh}{to adrl}[ehouse1status struktura]
– Struktura ma postać: {AddrH}{AddrL}{‘s’}[Dane……………..]
gdzie: AddrH – Adres – MSB
AddrL – Adres – LSB
‘s’ – litera s oznaczająca STATUS jako typ przesyłanych danych

Inteligentny Dom eHouse – programowanie C struktury sterowników eHouse 1

Struktury są częścią wspólną dla każdej aplikacji dla dowolnego mikroprocesora czy systemu operacyjnego.
Odbiór statusu, puźniejsze przetwarzanie, akwizycja danych, wyświetlanie wymaga już tworzenia indywidualnego oprogramowania na daną platformę sprzętową i softwarową.
Pola unii wpisuje się po znaku “.” jeśli nie mamy do czynienia ze wskaźnikiem lub “->” jeśli jest to wskaźnik. np. “HM.AddrH” lub *(HM->AddrH)

Opis oprogramowania integrującego system eHouse z zewnętrznym oprogramowaniem i sprzętem:

  • Napisać funkcję odbioru ramki statusu dla indywidualnej platformy sprzętowej i softwarowej
  • Utworzyć tablicę instancje unii w ilości >= od ilości sterowników sprzętowych eHouse 1:
    RMeHouse1Status RMs[COUNT_OF_RMS]; //Dla roommanagerów w ilości = COUNT_OF_RMS dla PC może to być do 250
    //dla innego typu urządzenia jak najmniejsza ilość aby nie obciążać systemu np kilka sztuk więcej niż liczba sterowników
    HMeHouse1Status HM; ///Jedna instancja heatmanagera jeśli jest w systemie
  • zainicjować wszystkie elementy unii RMs[i].AddrH=55; oraz RMs[i].AddrL=%x% wartościami adresów zainstalowanych sterowników RoomManager’ów
  • jeśli posiadamy HeatManager zainicjować “HM.AddrH=1;” oraz “HM.AddrL=1;” – jest to stały adres HeatManager’a
  • przy odbiorze ramki statusu z dowolnego media transmisyjnego porównać pole AddrH i AddrL bieżącej ramki i przekopiować do instancji unii o tym samym adresie np funkcją memcpy zgodnie z algorytmem
    for (k=0;k
    np w zależności od definicji funkcji memcopy dla danego kompilatora i systemu:
    memcpy(*RMs[i]->data,*(ReceivedBuffer+offset),sizeof(RMs[i])) gdzie “i” jest indexem RoomManagera ze zgodnym adresem w stosunku do odebranej ramki
  • W tym momencie otrzymujemy szablon aplikacji na dowolny system zawierający w strukturze dla sterownika zdekodowany ostatni status dla każdego sterownika
  • W oparciu o te dane możemy tworzyć online’owe bramki komunikacyjne, analizatory logów, aplikacje przetwarzające zaawansowane algorytmy automatyki zależne od wielu parametrów

Szablon aplikacji jest na tyle prosty i wydajny że przy pomocy mikrokontrolera 8 bitowego można przetwarzać te dane w czasie rzeczywistym.

przykład zaawansowanego algorytmu obrazujący użycie unii ze statusami po automatycznym ładowaniu danych:

if (
(RMs[0].OUT.o1) &&
//jeśli wyjście 1 RM[0] włączone
(RMs[1].INPUTS.i7) && //i jeśli wejście 7 RM[1] włączone
(!RMs[2].INPUTS.i3) && //i jeśli wejście 3 RM[2] wyłączone
(!RMs[11].OUT.o7) && //i jeśli wyjście 7 RM[11] wyłączone
(RMs[4].ADC.an1<255) //i jeśli wartość pomiaru przetwornika analogowo cyfrowego an1 wymaga przeliczenia z wartości

) //zaawansowany warunek
if (!RMs[7].OUT.o13) tylko jeśli wyjście 13 RM[7] wyłączone
{ //uruchom zdarzenie – włącz wyjście 13 RMs[7]
SendEvent(“5507210d010000000000”);//uruchomienie – przesłanie zdarzenia “direct event” w kodzie hex
// hhlleea1a2a3a4a5a6a7
//gdzie
// hh – AddrH
// ll – AddrL
// ee – Event Code (command)
// a1..a7 – (argumenty dla komeendy)
}