Schlagwort-Archive: Arduino

MIDI DB50XG – ein Interface für das Daughter Board

Loading

Beim Stöbern in einer Kiste mit meinen alten Bastelarbeiten ist das folgende Kästchen zum Vorschein gekommen.  Es stammt aus der Zeit als ich noch mit Amgia, aber auch schon mit PCs zu tun hatte – ich schätze so ca.  um 1996. Das Kästchen beschriftete ich mit „DB50XG MIDI – Wavetableprozessor“.

Das Fundstück aus der Kiste

Darin befindet sich eine Platine von Yamaha, die sich eben DB50XG nennt. Diese Platine war als Tochterplatine für PC-Soundkarten mit „Waveblaster“ Erweiterungsport konzipiert. Sie erweiterte die Soundkarten um einem polyphonen MIDI – Wavetable – Sampler. So konnte der General Midi Standard und der Yamaha XG Standard wiedergegen werden.  Heute macht sich darüber niemand mehr Gedanken. Wenn man damals mit einem PC aus Midi – Daten Sounds erzeugen wollte, dann war entweder eine externe Hardware notwendig, oder eben eine Soundkarte mit einem OnBoard Midi Synthesizer oder Wavetable Chipsatz. Der PC übernahm dann die Steuerung, das Senden und Empfangen der Midi Daten über eine Sequenzer Software. Heute werden die Midi Sounds direkt am PC generiert und die Samples und Tonmodelle in die Software eingebunden. Damals reichte die Leistung der PC-Hardware dazu nicht aus. Wenn sich jetzt jemand gerade fragt, worüber ich hier palavere – was ist Midi und wofür benötigt man das? – dann sei hier kurz gesagt: Midi ist die Abkürzung für „Musical Instrument Digital Interface“ – also eine digitale Schnittstelle – ein Datenprotokoll für Musikinstrumente. Es dient – grob erklärt – dazu, elektronische Musikinstrumente untereinander zu vernetzen und zu steuern. So kann zum Beispiel über ein einziges Keyboard eine Vielzahl von klangerzeugenden Geräten gesteuert werden. Wie der Midi Standard funktioniert, wie die Datenpakete aussehen und das elektrisch aussieht, werde ich hier nicht erläutern. Dazu findet man, wie immer, reichlich Informationen im Netz.

Im Inneren des Kästchens

Zurück zum selber gebastelten Kästchen. In die Plastikbox habe ich damals das DB50XG gepackt und vom „Waveblaster“-Port, einer 26poligen Buchsenleiste, die notwendigen Leitungen zur Inbetriebnahme der Midi Platine nach Außen geführt. Und das war ziemlich simpel. Die Platine benötigt eine Spannungsversorgung von +/-12V und +5V. Es gibt einen Midi-IN und einen Midi-OUT (Through) Pin, einen Reset-Pin und zwei Analog Audio Out Pins – je einen pro Kanal. Die untenstehende Tabelle zeigt die Pinzuordnung des Steckers:

Pin Nummer Zuordnung
1 Digital Masse
2 nicht verbunden
3 Digital Masse
4 nicht verbunden
5 Digital Masse
6 Versorgung +5V
7 Digital Masse
8 nicht verbunden
9 Digital Masse
10 Versorgung +5V
11 Digital Masse
12 nicht verbunden
13 nicht verbunden
14 Versorgung +5V
15 Analog Masse
16 nicht verbunden
17 Analog Masse
18 Versorgung + 12V
19 Analog Masse
20 Audio out rechts
21 Analog Masse
22 Versorgung -12V
23 Analog Masse
24 Audio out links
25 Analog Masse
26 Reset

Der ganze Aufbau war damals eher sehr spartanisch gestaltet. Die Stromversorgung musste über ein, oder mehrere externe Netzteile hergestellt werden. Es gab keine galvanische Signaltrennung mittels Optokoppler. Da musste ich mich auf den ordentlichen Aufbau des Midi-IO-Controller verlassen, den ich an den Amiga angeschlossen hatte. So durfte das natürlich nicht bleiben. Und das schöne DB50XG Board nicht mehr zu verwenden, oder dem Elektronikschrott zuzuführen, bringe ich nicht über´s Herz. Der Plan der daraus entstand, war, ein neues Interfaceboard zu entwickeln – oder basteln, das möglichst universell einsetzbar werden sollte. 

DB50XG

Diese Idee ist nun schon wieder einige Jahre her und immer wieder einmal habe ich ein wenig daran gearbeitet. Folgende Punkte, so habe ich mir ausgedacht, sollte das Interfaceboard erfüllen:

  • eine einfache Spannungsversorgung soll das Yamaha Board mit Energie versorgen. Idealer Weise soll ein USB-Port und optional ein Anschluss für ein Universalnetzteil vorhanden sein. Alle benötigten Spannungen sollen auf dem Interfaceboard aus den 5VDC generiert werden.
  • Das DB50XG soll, wie seinerzeit, auch als „Huckepack“ Platine aufgesteckt werden können
  • Das Midi-in Signal soll über die 5polige DIN Buchse und auch über einen Pinheader eingespeist werden können – natürlich schön entkoppelt (Damit kann auch ein Microcontroller wie Arduino und co. ganz ohne Aufwand angeschlossen werden)
  • Der Ton, also das Audiosignal soll pro Kanal über je eine Chinch-Buchse und auch als 3.5mm Klinkenbuchse und über einen Pinheader zur Abnahme bereitstehen.
  • Wortwiederholungen SOLLTEN vermieden werden, ist mir aber egal 🙂

Daraus entstand schlussendlich der folgende Schaltplan. Die 5VDC Versorgung der USB Quelle wird direkt zur 5V Versorgung des Midi Boards geführt. Die ebenfalls benötigten +12V/-12V erzeugt ein DC/DC Converter (TMR0522). Dieser wird eingangsseitig vom 5V Netz versorgt. Der optionale „Externe“ Spannungseingang gelangt an einen LM2596ADJ. Das ist ein Step-Down Voltage-Regulator der mit Eingangsspannungen bis zu 40V arbeiten kann. Die geregelte Ausgangsseite ist in vielen Bereichen verfügbar. Ich habe hier den ADJ (Adjustable) Typ in die Schaltung integriert, da ich davon einige Stück im Sortiment Kasten habe. Durch einen Jumper am Board ist, die Spannungsquelle wählbar.

Auf Basis dieses Schaltplanes habe ich ein Layout erstellt und es vorerst einmal im eigenen Ätzbad hergestellt. Heraus kam die folgende Platine, die als Testaufbau diente. Technisch funktionierte das Board einwandfrei, jedoch die Anordnung der Komponenten hat mir nicht gefallen. Den Step-Down Converter samt Spule hatte ich auf der Rückseite platziert. Auch war mir der Abstand zwischen den Anschlussbuchsen zu eng beieinander. Und wie man das als PCB Layouter so macht – man macht immer ein zweites Design. So auch dieses Mal.

Der Testaufbau mit bestücktem Midiboard ist im nachfolgenden Bild zu sehen. Das Midi-Signal als Testquelle kommt vom PC und wird durch einen USB-Midi Adapter aus Fernost generiert.

Also noch einmal vor den Rechner gesetzt und das Layout umgezeichnet. Heraus gekommen ist dann die folgende Version. Diese Ausführung habe ich dann bei einem Leiterplattenhersteller bestellt.

Die schlussendlich gefertigte Platine in bestücktem Zustand sieht dann so aus. Darunter ist sie  mit dem aufgesteckten DB50XG Board zu sehen.

 

UV-Sensor Logger selbstgebastelt

Loading

Kommt der Sommer, kommen neue Ideen. In den Sommermonaten ist ja bekanntlich die Sonnenscheindauer länger und auch die Intensität der Sonnenstrahlen höher. Viele nutzen diese Eigenschaft der Sonne, um ihre Vitamin-D Produktion des Körpers anzutreiben, andere wiederum legen sich unter die Strahlenquelle um durch den hohen UV Anteil ihrer Hautfarbe abzudunkeln. Dies wiederum steigert vermeintlich deren Attraktivität und regt die Hormonproduktion und die Paarungsbereitschaft an… Leider hat der nicht sichtbare UV Bereich im Spektrum des Sonnenlichts bekanntlich auch negative Auswirkungen auf den menschlichen Körper. Auch technisch kann das Sonnenlicht genutzt werden. Durchschnittlich wird die Leistung der Sonne pro Flächeneinheit mit 1000W pro m² angenommen. Großflächige P-N Übergänge in Halbleitermaterialien schaffen mittlerweile mit einem Wirkungsgrad von bis zu 22% daraus elektrische Energie zu erzeugen.

Man kann die Energie aber auch noch anders nutzen, bzw. den UV-Anteil. Vielen Retrosammlern ist sicherlich das Problem mit den vergilbten alten Kunststoffgehäusen bekannt. Um das in den Griff, bzw. wieder in den Ursprungszustand von vor 30, 40 Jahren zu bekommen, verwendet man H2O2 also Wasserstoffperoxid und UV Licht um so einen Bleichprozess in Gang zu bekommen. Und so kam ich zur Idee für folgendes Projekt.

Bei einem online-Elektronik-Laden fand ich im Abverkaufs Angebot ein UV-Sensor Board des Herstellers Waveshare. Darauf befindet sich ein LITEON OPTOELECTRONICS LTR390 Chip samt Levelshifter-Schaltung. Als Interface steht ein I²C Bus zur Verfügung. Ein Blick ins Datenblatt verriet mir, dass der Sensor zwei Wellenlängenbereiche erfasst und separat ausgibt.  Der ALS (Ambient Light Sensor von 500-600nm) und der UV (Ultra Violett Bereich von 300-350nm).  Damit kann man doch schnell ein einfaches Logging Board basteln – dachte ich mir.  So habe ich mir gedacht, das Board sollte folgendes können:

  • Spannungsversorgung von einer 18650er Zelle oder USB
  • USB soll den Akku auch laden können
  • einen Micro-SD Slot zum Aufzeichnen der Sensordaten
  • einen RS-232 Port, zum direkten Loggen am PC
  • ein cooles OLED Display
  • zwei Taster zum Bedienen des Loggers (Intervall, Start/Stop etc.)

Die Steuerung soll natürlich wieder einmal ein Chip von Atmega – der 328er übernehmen. Davon befinden sich einfach noch genügend Stück in meinen Sortiment Kästchen. Damit man sich schneller einen Überblick über den Aufbau verschaffen kann, habe ich das folgende Blockdiagramm gezeichnet:

Im nächsten Schritt habe ich aus dem Blockschaltbild einen Schaltplan erstellt, um aus dem dann wiederum ein Layout erstellen zu können.  Parallel zur Schaltplanerstellung habe ich einzelne Bereiche per „Luftverkabelung“ auch gleich probeweise zusammengeschaltet und getestet, ob das alles auch so funktioniert, wie ich mir das vorstelle. Und vor allem sollte auch alles im Flashspeicher des Microcontrollers Platz haben.

Im Bild oben ist der „luftige“ Aufbau bestehend aus fertigen Komponenten zu erkennen. Für die ersten Tests mit dem Sensor und dem OLED Display reichte ein Arduino vollkommen aus. Damit war es mir möglich, die gewünschten Funktionen zu testen. Somit stand der Erstellung des Schaltplanes nichts mehr im Weg. Eine 18650er Lithiumzelle soll als primäre Energiequelle dienen. Alternativ wird auch ein USB-Port vorhanden sein, der die Zelle laden kann bzw. den Sensor betreiben kann. Dafür, weil ich faul bin und auch ziemliche Bauteil Lieferengpässe ein großes Problem sind, verwende ich zum Laden des Akkus eine fertiges Wemos-D1-Mini Board. Das wird genauso wie das OLED Displayboard und das Sensorboard als fertige Komponente auf dem Design der Platine Platz finden.  Als Controller kommt wieder, wie schon erwähnt, ein Atmega328 im TQFP Gehäuse zum Einsatz. Dieser wird über die I²C Schnittstelle mit dem OLED Display (SBC-OLED01 mit SSD1306 Controller) und dem LTR390 UV-Sensorboard kommunizieren. OLED und Sensor sind 5V kompatibel. Die SD-Karte wird aber mit 3.3V betrieben. Dafür benötigt die Schaltung noch einen Spannungswandler von 5V auf 3.3V für die Versorgung und einen Levelshifter für den SPI-Datenbus, über den die SD-Karte mit dem Atmega die Daten austauscht. Da der Atmega dann auch mit seiner Firmware programmiert werden möchte, habe ich einen 2×4 Pinheader für den Anschluss eines Programmers vorgesehen. Sechs Pins davon (GND,5V, MOSI, MISO, SCK und RESET) benötigt der Programmer und die zwei verbleibenden Pins sind für die serielle Schnittstelle vorgesehen. Die beiden Interrupt-Eingänge des Atmega werden mit je einem Taster beschalten, der dann die Software bedienbar macht. Die Batteriespannung wird über einen Teiler an einem der ADC-Eingänge gemessen bzw. auch mitgeloggt. Das Ergebnis dieser Gedanken ist der folgende Schaltplan:

Ein Layout ist danach der nächste Schritt.  Bei einer Größe von 12 x 4,5 cm ist die Platine einigermaßen „handlich“. Die Leiterbahnführung findet auf beiden Seiten statt und die Module (Ladeschaltung, Display und UV-Sensor) sind über Pinheader steckbar ausgeführt.

Die beiden Bilder oben zeigen die Vorschau der „Top-“ bzw. „Bottom-“ Seite des Layouts. Aus den so erstellten Produktionsdaten konnte eine Platine erstellt werden.

Nach einiger Lötarbeit war die Hardware dann soweit fertig. Um diesem „Lötwerk“  letztendlich auch Leben einzuhauchen, bedurfte es einer Software, die auf dem Microcontroller ihre Arbeit verrichtet.

Beim Basteln der Software bediente ich mich der kostenlosen „Arduino IDE“ Entwicklungsumgebung.  Die Dokumentation des LTR390 beschreibt genau über welche Register welche Funktionen des Sensors zu bedienen sind. Es gibt aber auch schon für ganz Bequeme eine fertige Library – so wie für fast alle Sensoren und Aktoren, die an Microcontroller angeschlossen werden sollen. In der Arduino IDE findet man über den Boardmanager die „Adafruit LTR390 Library“ über die man einfach mit dem Sensor kommunizieren kann.  Die Ansteuerung des OLED Displays übernimmt in meinem Fall die SSD1306Ascii Library. Die Buskommunikation übernehmen die „Wire“ und “ SPI“ Library und die „SD“ spricht mit der SD – Karte.  Die Includes sehen dann so aus:

#include <LTR390.h>
#include <SD.h>
#include <SPI.h>
#include <Wire.h>
#include „SSD1306Ascii.h“
#include „SSD1306AsciiWire.h“

Den gesamten Code kann ich bei Bedarf gerne hier veröffentlichen. Er ist allerdings kein Hexenwerk, sondern simples und sicher nicht optimiertes Codezeilen Geschreibe 🙂 In der derzeitigen Code- (Firmware) Version 1.3d gibt es ein kleines Auswahlmenü, das es ermöglicht, das Logintervall der SD-Karten-Aufzeichnung einzustellen und natürlich auch die Aufzeichnung zu starten bzw. zu stoppen. Geloggt wird in ein Textfile. Die aufgezeichneten Daten sind UV-Index, Umgebungshelligkeit und die Akkuspannung.

Einen Auszug aus dem Datalog habe ich unten eingefügt:

 Ambient[lx], UV-indx, Batt[V], Loggingintervall[s]  
 691.60,0.01,3.77,20  
 691.60,0.03,3.76,20  
 1184.00,0.03,3.77,20  
 1184.00,0.03,3.75,20  
 1191.00,0.03,3.77,20  
 1191.00,0.03,3.75,20  
 1198.60,0.03,3.76,20  
 1198.60,0.03,3.73,20  
 1211.60,0.03,3.76,20  
 1211.60,0.04,3.75,20  
 1223.00,0.04,3.75,20  
 1223.00,0.04,3.76,20  
 1234.20,0.04,3.76,20  
 1234.20,0.04,3.74,20  
 1243.60,0.04,3.76,20  
 1243.60,0.04,3.76,20  
 1252.00,0.04,3.75,20  
 1252.00,0.04,3.73,20  
 1261.20,0.04,3.74,20  
 1261.20,0.04,3.72,20  
 1269.60,0.04,3.76,20  
 1269.60,0.04,3.76,20  
 1278.40,0.04,3.76,20  
 1278.40,0.04,3.75,20  
 1288.40,0.04,3.76,20  
 1288.40,0.04,3.75,20  
 1298.20,0.04,3.76,20  
 1298.20,0.04,3.74,20  
 1305.80,0.04,3.73,20  
 1305.80,0.04,3.73,20  
 1313.20,0.04,3.73,20  
 1313.20,0.04,3.75,20  
 1321.60,0.04,3.74,20  
 1321.60,0.04,3.75,20  
 1331.80,0.04,3.75,20  
 1331.80,0.04,3.75,20  
 1341.60,0.04,3.74,20  
 1341.60,0.04,3.76,20  
 1349.40,0.04,3.76,20  
 1349.40,0.04,3.76,20  
 1358.20,0.04,3.72,20  
 1358.20,0.04,3.76,20  
 1365.60,0.04,3.74,20  
 1365.60,0.04,3.73,20  
 1374.20,0.04,3.72,20  
 1374.20,0.04,3.75,20  
 1380.60,0.04,3.75,20  
 1380.60,0.04,3.76,20  
 1386.60,0.04,3.75,20  
 1386.60,0.04,3.76,20  
 1394.80,0.04,3.75,20  
 1394.80,0.04,3.75,20  
 1401.40,0.04,3.73,20  
 1401.40,0.04,3.74,20  
 1408.60,0.04,3.75,20  
 1408.60,0.04,3.74,20  
 1414.20,0.04,3.73,20  

 

Diese Daten lassen sich jetzt sehr einfach weiterverarbeiten und grafisch darstellen. Als Office-Nutzer kann man zum Beispiel auf Excel zurückgreifen und die Daten dort importieren und als Graphen darstellen. Es geht aber noch einfacher und auch sehr schnell mit Tools wie Matlab. Mit einem Script wie dem nachfolgenden kann man die Logdatei dann visualisieren.

 

 %% Setup the Import Options and import the data  
 opts = delimitedTextImportOptions("NumVariables", 4);  
 opts.DataLines = [3, inf];  
 opts.Delimiter = ",";  
 opts.VariableNames = ["Ambientlx", "UVindx", "BattV", "Loggingintervalls"];  
 opts.VariableTypes = ["double", "double", "double", "double"];  
 opts.ExtraColumnsRule = "ignore";  
 opts.EmptyLineRule = "read";  
 opts = setvaropts(opts, ["Ambientlx", "UVindx", "BattV"], "TrimNonNumeric", true);  
 opts = setvaropts(opts, ["Ambientlx", "UVindx", "BattV", "Loggingintervalls"], "DecimalSeparator", ",");  
 opts = setvaropts(opts, ["Ambientlx", "UVindx", "BattV"], "ThousandsSeparator", ".");  
 datalog = readtable("F:\ingmarsretro\datalog.txt", opts);  
 clear opts  
 x=size(datalog); % groesse der tabelle  
 measurement=x(1); % anzahl messungen   
 uvi=datalog{1:measurement,2};  
 ambient=datalog{1:measurement,1};  
 messzeit = linspace(0,(measurement*datalog{1,4}),measurement); %zeitvektor von 0 bis zeitintervall aus datalog spalte4 * messungen  
 figure(1);  
 title('UV - Index');  
 subplot(2,1,1);  
 plot(messzeit,uvi);  
 title('UV - Index');  
 xlabel('Zeit [s]');ylabel('UV - Index');  
 subplot(2,1,2);  
 plot(messzeit,ambient);  
 title('Beleuchtungsstärke');  
 xlabel('Zeit [s]');ylabel('Beleuchtungsstärke [lux]');  

Wird das Script ausgeführt, dann erhält man einen Plot, der die Messdaten visualisiert.

Die technischen Informationen zum Sensor sind dem Datenblatt des Herstellers zu entnehmen. Hier ein paar kurze Eckdaten:

Der LTR390 besteht aus zwei Fotodioden, einer für das sichtbare Spektrum des Lichtes und einer, die im UV-Bereich empfindlich ist. Der Strom der Photodioden wird in internen ADCs digitalisiert. Eine Interne Logic steuert die ADCs und über eine I²C Schnittstelle wird die Verbindung zur Außenwelt hergestellt. Die Auflösung von ALS und auch UVS ist in 13,16,17,18,19 und 20 Bit konfigurierbar. Der Sensor Chip ist in einem 2x2mm 6pin Gehäuse untergebracht. Die Detektoröffnung hat eine Kantenlänge von 280×280 µm.

Quelle: Datenblatt LTR-390UV https://optoelectronics.liteon.com/en-global/Led/LED-Component/Detail/926
Quelle: Datenblatt LTR-390UV https://optoelectronics.liteon.com/en-global/Led/LED-Component/Detail/926

 

 

Datenknoten mit Arduino

Loading

Leider sind die Abstände, in denen ich ein wenig Zeit finde, einen neuen Beitrag für den Blog zu schreiben, nicht kürzer geworden. Aber einen Beitrag pro Monat zu posten, halte ich ein… 🙂

Dieses Mal ist es kein Retro Bastelprojekt aus den heimischen Gefilden oder eine Restauration eines alten Gerätes, sondern wieder etwas zum Thema Arduino. Die Idee – es soll ein Sensor gebaut werden, der wie immer, eine physikalische Größe in ein elektrisches Signal umwandelt. Das ist jetzt nichts Besonderes und um welche Art von Sensor es sich handeln wird, werde ich vorerst noch nicht beschreiben. Aber es soll nicht ein Sensorboard geben, sondern viele. Und diese Sensorboard kurz „Sensoren“ sollen in einer zweidimensionalen Matrix miteinander vernetzt werden. Man kann sich das in etwa vorstellen wie ein Schachbrett, wobei jedes der Schachbrettfelder einen Sensor darstellt. Dieses Netzwerk an Sensoren – also Sensorknoten – soll dann über eine Übergabestelle mit einem Rechner verbunden sein und die Sensordaten des jeweiligen Feldes ausgeben. Es soll dann auch möglich sein, einzelne Felder aus dem Netzwerk zu entfernen ohne dass das verbleibende Netzwerk seine Funktion verliert.

Das ganze System soll möglichst einfach und günstig aufgebaut werden. Und so ist schnell ein Systemkonzept entstanden, in dem die Knoten über den I²C Bus kommunizieren und ihre Daten zu einem Master senden. Das folgende Diagramm soll das verdeutlichen.

Dieses Konzept, so dachte ich mir, lässt sich am einfachsten mit einem Atmega Microcontroller realisieren. Der hat genügend IO´s, einen I²C Bus und UART onboard, ebenso auch analoge Eingänge und benötigt wenig Bauteilperipherie, um ihn in einem eigenen Layout zum Leben zu erwecken. Und es gibt nichts schnelleres, so einen Testaufbau eines solchen Knotennetzwerks zu realisieren, als die gut bekannten Arduino Development Boards zu benutzen. Ich habe die günstigste Variante für einen Testaufbau gewählt -> den Chinanachbau vom Arduino Uno (Joy-IT UNO) mit dem Atmga328 im gesockelten DIL Gehäuse.

Joy-It Uno Boards

Im Bild sind zehn Stück dieser Microcontrollerboards zu sehen. Von denen soll einer als Bus-Master und neun Stück als Slaves eingesetzt werden. Jeder dieser Slaves hat natürlich eine eindeutige Bus-Adresse, die im System nur einmal vorkommt. Im Testaufbau wird diese Busadresse über den Programmcode fest vergeben, da ohnehin jeder Arduino einmal mit dem Rechner verbunden werden muss, um den Programm-Upload durchzuführen. Das soll natürlich später anders aussehen. Denn der Arduino wird auf den Atmega328 Chip, seinen Quarz und die paar Widerstände reduziert auf dem Sensorboard mit gelayoutet. Programmiert soll der Chip dann über die ISP Pins werden. Da bei vielen Boards natürlich nicht jedes Mal der Programmcode individuell angepasst wird und alle das gleiche Flashfile erhalten sollen, will ich die Sensoradresse mit einem 7Bit Dipschalter einstellen. Ein 4021 Cmos Static Shift Register soll die Bits nach dem Einschalten des Controllers auslesen und seriell in den Controller schieben. Der daraus resultierende Wert steht dann in einer Variablen als Busadresse zu Verfügung.

Jeder dieser Slaves mit seiner individuellen Busadresse wird nun vom Masterknoten der Reihe nach abgefragt, welchen Zustand er hat und ob er einen Ausgang schalten soll, oder nicht. Das bedeutet, der Knoten hat lediglich einen DO (Digitalen Ausgang) mit dem er beispielsweise eine LED aus- und einschalten kann und einen oder mehrere DI (Digitalen Eingang) der einen Zustand, zum Beispiel eines einfachen Schalters abfragt. Diese Funktionen werden in 2 Bits eines Bytes gespeichert. Ein weiteres Byte dient zur Übertragung der Busadresse. Es werden also zwei Bytes über den Bus geschickt. Das untenstehende Bild zeigt den Testaufbau mit den „UNO-Boards“

Alle Arduinos sind mit I²C Datenbus und Spannungsversorgung verbunden

Der Ablauf läuft wie folgt:

MASTER:
Der Masterknoten sendet nach der Reihe an alle Slave-Adressen eine Anfrage und einen Schaltbefehl (der kommt für alle Knoten von einem TEST-Taster Eingang am Master) für den LED-Ausgang des Knotens und sieht ob eine Antwort zurückkommt oder nicht. Wenn keine Antwort kommt, ist der Knoten nicht im Netz oder defekt. Kommt eine Antwort, so besteht diese aus der Adresse des Knotens und seinem Statusbyte. Diese Informationen werden über ein RS232 Terminal an den, am Master angeschlossenen Rechner übertragen. So kann dort beispielsweise über eine Visualisierung mittels (NI LabVIEW, oder Matlab o.ä.) der Schaltzustand jedes einzelnen Knotens am Bildschirm angezeigt werden. Mit einer Anpassung des Master Programmes ist es auch möglich, die LED-Ausgänge der Slaves über den Rechner zu schalten.

SLAVE:
Wenn der Masterknoten vom Slave Daten anfordert, so sendet der Slave zwei Bytes zurück. Wobei Byte0 wieder die Slave ID (also Busadresse ist) und Byte1 die Daten. Byte1 besteht eigentlich aus nur zwei Bit, die wie folgt kodiert sind (in dezimaler Darstellung):
 0 = LED aus | Sensor nicht ausgelöst
 1 = LED ein | Sensor nicht ausgelöst
 2 = LED aus | Sensor ausgelöst
 3 = LED ein | Sensor ausgelöst

Der Programmcode als Beispiel:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
// I2C Slave Code
// 16.05.2018 
// ver 1.3
#include <Wire.h>
#define ADDRESS 2     // adresse des slave knotens
#define PAYLOAD_SIZE 2 // anzahl der bytes  die vom masterknoten zu erwarten sind
int LED=12;            // indicator led an pin D12
int SENSOR = 8;        // sensor input an pin D8
bool actionState=0;      // sensor zustand
int busstatus;  // statusvariable 
                       // 0 = LED aus | sensor nicht belegt
                       // 1 = LED ein | sensor nicht belegt
                       // 2 = LED aus | sensor belegt
                       // 3 = LED ein | sensor belegt
 
bool sensled=0;          // sensor LED
byte nodePayload[PAYLOAD_SIZE];

void setup()
{
  pinMode(LED, OUTPUT);         //sensorLED
  pinMode(SENSOR, INPUT);       //Sensor 
  Wire.begin(ADDRESS);          // Activate I2C network
  Wire.onReceive(receiveEvent);
  Wire.onRequest(requestEvent); // auf master anforderung warten
                      //  // debug interface
                      //  Serial.begin(9600); 
}

// *********************************mainloop****************************************************
void loop()
{ 
  delay(5);
  
   if(sensled){digitalWrite(LED, HIGH);}
         else{digitalWrite(LED, LOW);}

  actionState = digitalRead(SENSOR);  //Sensoreingang abfragen        
   if((actionState==1)&&(sensled==1)) {busstatus=3;}
   else if ((actionState==0)&&(sensled==1)) {busstatus=1;}
   else if ((actionState==1)&&(sensled==0)) {busstatus=2;}
   else if ((actionState==0)&&(sensled==0)) {busstatus=0;}

                      //  Serial.println("######################");
                      //  Serial.print("busstatus neu setzen ");
                      //  Serial.println(busstatus);
                      //  Serial.print("sensled LED            ");
                      //  Serial.println(sensled);
                      //  Serial.print("actionState           ");
                      //  Serial.println(actionState);
                      //  Serial.println("######################");
  nodePayload[0] = ADDRESS;                  // Adresse in byte0 zurücksenden.  
  nodePayload[1] = busstatus;                //byte 1 ist die statusinfo der LED
}



// *********************************************************************************************
void requestEvent()
{ Wire.write(nodePayload,PAYLOAD_SIZE);  
  Serial.println("bytes status schreiben");
  Serial.println(nodePayload[0]);
  Serial.println(nodePayload[1]);
  delay(5);
}

// *********************************************************************************************
void receiveEvent(int bytes)  //einen wert vom I2C lesen
      
{
  
  busstatus = Wire.read(); //If the value received was true turn the led on, otherwise turn it off  
                              //  Serial.println("status empfangen");
                              //  Serial.println(busstatus);
  if((busstatus==1)||(busstatus==3)){sensled = 1;}
                                else{sensled = 0;}
                                              
}

 

Die Busadresse ist in diesem Slave-Code noch individuell einzugeben. In der nächsten Version ist dann der vorherbeschriebene „Serializer“ der parallelen Dip-Schaltervariante implementiert. Das folgende Codebeispiel ist von Masterknoten, der die Slaves ausliest und mittel Prüftaster ein LED Muster an die Sensor Slaves sendet:

 

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
// I2C masterknoten 
// 16.05.2018 
// ver 1.2
// changes abfrage wenn kein knoten am bus dann 255 ausgeben
#include <Wire.h>

#define busbytes 2          // wievele byte vom I2C knoten zu erwarten sind
#define maxKNOTEN  10       // anzahl der zu scannenden slaves
#define startKNOTEN 2       // startadresse der slaves
#define DELAY 5             // einfach ein delay ....

int i; int j=0;
int buttonPin = 12;
int testbut = 0; int anim = 0;
int buttonState = 0;
int DATEN[busbytes];
int adresse; int busstatus;  
byte sensorbelegt; byte ledsensoron;

                       // 0 = LED aus | Sensor nicht belegt
                       // 1 = LED ein | Sensor nicht belegt
                       // 2 = LED aus | Sensor belegt
                       // 3 = LED ein | Sensor belegt

int leddat1[] = {1,1,1,1,0,1,1,1,1}; // -
int leddat2[] = {0,0,0,0,1,0,0,0,0}; // |

void setup()
{
  Serial.begin(9600);  
  Serial.println("MASTER-KNOTEN");
  Serial.print("Maximum Slaveknoten: ");
  Serial.println(maxKNOTEN);
  Serial.print("Datengroesse in byte: ");
  Serial.println(busbytes);
  Serial.println("***********************");
  
  Wire.begin();                 // Activate I2C link
  pinMode(buttonPin, INPUT);    // test-tastereingang festlegen
}


//#####################################################################################################
void loop()
    
{
  for (int Knotenadresse = startKNOTEN;         //alle knoten scannen
           Knotenadresse <= maxKNOTEN; 
           Knotenadresse++) 

        
    //################################################################################################       
    { 
     // testbut = 0;  
     anim = 0;   
    Wire.requestFrom(Knotenadresse, busbytes);        // daten vom jeweiligen knoten anfordern
                                                 
           DATEN[0]=255; DATEN[1]=255;   // wenn kein knoten dann auf 255 setzen    
          if(Wire.available() == busbytes) {                                    // wenn knoten und daten dann
            for (i = 0; i < busbytes; i++) DATEN[i] = Wire.read();          // daten holen (zuerst busID, dann daten)
           // for (j = 0; j < busbytes; j++) Serial.println(DATEN[j]);        // daten an rs232 ausgeben   
          }            

//            Serial.println(Knotenadresse);
//            Serial.println(DATEN[0]);
//            Serial.println(DATEN[1]);
//            Serial.println(" ");
           
            adresse=DATEN[0]; 
            busstatus=DATEN[1];
           
            if(busstatus == 0)       {sensorbelegt=false;  ledsensoron=false;}
            else if (busstatus == 1) {sensorbelegt=false;  ledsensoron=true;}
            else if (busstatus == 2) {sensorbelegt=true;  ledsensoron=false;}
            else if (busstatus == 3) {sensorbelegt=true;  ledsensoron=true;}
      
         //################################################################################################
         //Testbutton Status lesen und variable testbut entsprechend setzen
       
          buttonState = digitalRead(buttonPin);               //tastereingang einlesen
          if(buttonState == HIGH){                            //wenn taster aktiv dann variable anim setzen
          anim = 1;
          //delay(5); 
          }
            
//            //debug debuginfo tasterstatus auf rs232 ausgeben
//            Serial.println("#######################");
//            Serial.print("Knoten Adresse    :");
//            Serial.println(adresse);
//            Serial.print("Busstatus         :");
//            Serial.println(busstatus);
//            
//            Serial.println("----------------");
//            Serial.print("Fliese belegt    :");
//            Serial.println(sensorbelegt);
//            Serial.print("LED Fliese       :");
//            Serial.println(ledsensoron);
//            Serial.print("#######################");
//            Serial.println(" ");
      
          //################################################################################################
          //Testbutton Status an jeweiligen knoten senden
      
          Wire.beginTransmission(Knotenadresse);           // transmit to device actual in for loop
          //anim schreiben
                    
           if (anim==0) {testbut=leddat1[j]; j++;}
                   else {testbut=leddat2[j]; j++;}
           if (j>8){j=0;}
          
          Wire.write(testbut);                             // senden des tasterstatus
          Wire.endTransmission();                          // ende gelände mit uerbertragung
       
          delay(DELAY);
          

    }
   
}

 

Mit dieser Anordnung ist es jetzt möglich alle Arduinos und deren Eingang auszulesen bzw. die LED über den Bus zu steuern. Im nächsten Schritt wird ein „Sensor“ gebaut, eine Platine gelayoutet und der Arduino Uno auf seinen Microcontroller reduziert. Darüber werde ich in einem der nächsten Posts berichten…

 

 

 

NTC am Arduino

Loading

ArduTemp(2)Nach dem kleinen Projektchen „Arduino mit Matlab“ möchte ich der Vollständigkeit halber den selben Aufbau auch noch ohne Matlab laufen lassen. Dabei soll der Code mit der mitgelieferten Arduino Entwicklungsumgebung „Arduino Software 1.6.7“ erstellt und in den Atmega 328 geladen werden. Damit man in dieser Stand-Alone-Variante auch was sehen kann, soll ein altes vierzeiliges LC-Display angeschlossen werden. Idealerweise gibt es hier eine schöne library namens LiquidCrystal.h, mit der das LCD im 4Bit Betrieb ganz einfach angesteuert werden kann.

Also schnell die benötigten Pins des LCD (übrigens ein JM204A) aus dem Datenblatt herausgesucht und mit Flachbandkabel und Pinheadern versorgt und an den Arduino angeschlossen. (die Belegung des Arduino habe ich im Script angegeben)

 

ArduTemp(1)Der NTC-Spannungsteiler bleibt, wie er ist. Und schon kann’s losgehen. Da wir die vier schönen Zeilen mit 20 Zeichen pro Zeile am LCD zur Verfügung haben, kann auch viel Information angezeigt werden. Ich habe mich entschieden, den Integer Wert des 10Bit ADC anzuzeigen (0-1023), den errechneten Widerstandswert des NTC´s und natürlich die daraus errechnete Temperatur.

Und das hier ist der simple Code 😉 …

 

/* ingmarsretro 2016
* Pinzuordnungen fürs LCDisplay
&nbsp;* RS to digital 12
&nbsp;* EN to digital 11
&nbsp;* D4 to digital 5
&nbsp;* D5 to digital 4
&nbsp;* D6 to digital 3
&nbsp;* D7 to digital 2
&nbsp;* R/W to ground
&nbsp;* VSS to ground
*/

// include libraries
#include <LiquidCrystal.h>
#include <math.h>
int analogpin = 0;
int analogvalue = 0;
double a1=3.354016E-03;
double b1=3.2569850E-04;
double c1=2.61013E-06;
double d1=6.38309e-08;
double urt=0;
double rt=0;
double rvsrref=0;
double temp=0;
double tempc=0;
double r=2200;
double rref=2200;
double analog=0;

// interfacepins initialisieren
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

void setup() {
&nbsp; // setup LCD spalten und reihen
&nbsp; lcd.begin(20, 4);
&nbsp; lcd.print("Testprogramm NTC");
&nbsp; Serial.begin(9600);
}

void loop() {
&nbsp; analogvalue=analogRead(analogpin);
&nbsp; analog=(0.004882812*analogvalue);
&nbsp; urt=5-analog;
&nbsp; rt=((r/analog)*urt);

&nbsp; rvsrref=rt/rref;
&nbsp; temp=(1/(a1+(b1*log(rvsrref))+(c1*(log(rvsrref*rvsrref)))+(d1*(log(rvsrref*rvsrref*rvsrref)))));
&nbsp; tempc=temp-273.15;
&nbsp;
&nbsp; //&nbsp; column 0, line 1
&nbsp; // (note: line 1 is the second row, since counting begins with 0):
&nbsp; lcd.setCursor(0,1);lcd.print("ADC-Wert =");
&nbsp; lcd.setCursor(11,1);
&nbsp; lcd.print(analogvalue);
&nbsp;
&nbsp; lcd.setCursor(0, 2); &nbsp;
&nbsp; lcd.print("Widerstd =");
&nbsp; lcd.setCursor(11, 2);
&nbsp; lcd.print(rt);

&nbsp; lcd.setCursor(0, 3); &nbsp;
&nbsp; lcd.print("Temp Cels=");
&nbsp; lcd.setCursor(11, 3);
&nbsp; lcd.print(tempc);

 

Arduino mit Matlab … Der Sensor

Loading

Nachdem ich im letzten Teil die Installation der Arduino-Matlab Packages zum Laufen bekommen habe, kann es nun weitergehen. Ziel dieses kleinen Beispiels ist es ja, an einen Arduino Uno einen NTC-Widerstand anzuschließen. Dieser soll als analoger Temperatursensor dienen (was er ja ist 😀 ) und über einen der A/D – Eingänge des Arduino eingelesen werden. Matlab soll dann schlussendlich die eingelesenen A/D- Werte  in Temperaturwerte umrechnen. Das Ganze soll über eine gewisse Zeit laufen, wobei alle paar n-Sekunden ein Wert eingelesen wird. Am Ende soll ein wunderschöner Temperaturplot mit Temperatur über Zeit erstellt werden.

Doch zuerst zum Sensor. Ich verwende hier einen NTC-Widerstand von dem Hersteller VISHAY mit einem R25 von 2200 Ohm (s.Datenblatt). Das bedeutet, er hat bei 25°C einen ohmschen Widerstand von 2.2kOhm. Je wärmer es nun wird, umso kleiner wird der Widerstand und umgekehrt. Der analoge Eingang des Arduino hat eine Auflösung von 10Bit. Das bedeutet, er kann den Spannungshub am Eingang (eingestellt durch die ADC Referenz) in 210 , also 1024 Teile auflösen (zerlegen). Der Standard beim Arduino ist 0V bis 5V. Also 0V am Eingang bedeutet einen ADC-Wert von 0 und 5V bedeutet einen ADC-Wert von 1024. Die Auflösung, also die kleinste auflösbare Spannungsänderung  ist daher:
formelarduino01 (2)Gibt der ADC beispielsweise einen Wert von 558 aus, so entspricht dies einer Spannung am Eingang von 558*0.00488V = 2.72304V. Doch wie soll der NTC jetzt an den Eingang angeschlossen werden? Ganz einfach. Man nehme einen Spannungsteiler und dimensioniere ihn so, dass der Strom durch die beiden Widerstände nie so groß werden kann, dass er zum einen die Versorgung des Arduino gefährdet und zum anderen auch nie so groß werden kann, dass er den NTC selbst erwärmt. In der Skizze ist nun dargestellt wie der Spannungsteiler aufgebaut und angeschlossen ist. Jetzt gilt es noch herauszufinden, wie aus der Spannung am ADC der gemessene Widerstandswert berechnet werden kann. Hier hilft die Spannungsteilerregel:
formel2
In diesem Beispiel hier besteht der Spannungsteiler aus dem NTC (2k2 @ 25°C) und einem 2k2 Festwiderstand. Wenn der NTC null Ohm haben sollte (nur rein theoretisch), so fließt ein maximaler Strom von 0.002A durch die Widerstände (5V/2200Ohm). Wir lesen jetzt in Matlab den Spannungsabfall am NTC ein und können uns über den Spannungsteiler den Widerstandswert berechnen. Jetzt fehlt nur noch die Formel zur Berechnung der Temperatur. Und die ist, samt den notwendigen Konstanten A1, B1, C1 und D1, im Datenblatt angegeben:formel3Das Ergebnis dieser Berechnung ist die Temperatur in Kelvin. Um die Temperatur aber in °Celsius angezeigt zu bekommen, rechnet man: °C = °K-273,15. Mit all diesen Informationen kann man jetzt ein Matlab-Script schreiben, das dann in etwa so aussieht:
 
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Beispielscript um mit ArduinoUno einen Temperaturverlauf aufzuzeichnen
% 02/2016 by I.Bihlo
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
&nbsp;
%a = arduino('com5','Uno');
&nbsp; a = arduino('com5','Uno','TraceOn', true)
&nbsp; analogpin=0;
&nbsp; analog=0;
&nbsp;
&nbsp; %ein paar konstanten für die weiteren berechnungen
&nbsp; %
&nbsp; r=2200;&nbsp; %Spannungsteilerwiderstand
&nbsp; rt=0; %das wird der errechnete widerstand des NTC
&nbsp; urt=0; %das wird der errechnete Spannungsabfall am NTC
&nbsp;
&nbsp; % konstanten für berechnung der Temperatur aus NTC Widerstand
&nbsp; % B25=3977K
&nbsp; a1=3.354016E-03;
&nbsp; b1=3.2569850E-04;
&nbsp; c1=2.61013E-06;
&nbsp; d1=6.38309e-08;
&nbsp; rref=2200;
&nbsp;
&nbsp;
&nbsp;
&nbsp; %Lesen eines Temperaturabhängigen Widerstandes am Analog Eingang A0
&nbsp; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
&nbsp;
&nbsp; for x=1:50
&nbsp; analog(x)=readVoltage(a, analogpin) %Liest den AnalogIn von A0 und gibt in Volt aus
&nbsp; urt(x)=5-analog(x); %spannungsabfall am NTC
&nbsp; rt(x)=(r/analog(x))*urt(x); %widerstand des NTC
&nbsp;
&nbsp; %berechung der temperatur
&nbsp; rvsrref(x)=rt(x)/rref;
&nbsp; temp(x)=1/(a1+(b1*log(rvsrref(x)))+(c1*(log(rvsrref(x)^2)))+(d1*(log(rvsrref(x)^3))));
&nbsp; tempc(x)=temp(x)-273.15 %Kelin in Celsius umrechnen
&nbsp; pause(2);
&nbsp;
&nbsp; end
&nbsp;
&nbsp; clear a;
&nbsp;
&nbsp; %plot den mist
&nbsp; figure(1);
&nbsp; time=1:50;
&nbsp; plot(time,analog,'b');
&nbsp; grid on; hold on;
&nbsp; plot(time,rt/1000,'r');
&nbsp; plot(time,urt,'g');
&nbsp; plot(time,tempc,'m');
&nbsp; legend('Analogspannung des ADC','Widerstand des NTC in kOhm','Spannung am NTC','Temperatur [°C]'); 
&nbsp; %ende

 

 
temperaturgraph
So sieht der Graph mit dem Temperaturlog danach aus…

Arduino mit Matlab … Startschwierigkeiten

Loading

arduino01 (4)Heute möchte ich ein Thema vorstellen, mit dem ich mich kurz im Rahmen einer Recherche beschäftigt habe. Viele (Techniker) kennen vielleicht die Software Matlab von der Firma Matworks. Das ist ein extrem umfangreiches Softwarepaket, das bei uns in der Lehre eingesetzt wird, um Studierende in allen möglichen technischen Bereichen zu unterrichten. Sei es Signalverarbeitung, Regelungstechnik, Bildverarbeitung, etc. – Matlab ist das Tool, um all das professionell umzusetzen. Auch wenn es um Messdatenerfassung geht, muß man nicht unbedingt auf Tools zurückgreifen, mit denen ein Projekt oder Programm „gezeichnet“ wird. Das ist zwar toll für den Einstieg, kann (und wird) in späterer Folge aber aufgrund des riesen Overheads und der benötigten PC Resourcen viel zu umständlich, wenn man schnell einmal über eine externe Hardware irgendwelche physikalischen Größen aufzeichnen und verarbeiten will.

In diesem kleinen Projektchen möchte ich nun zeigen, wie einfach man mit Hilfe eines Arduino Uno Boards zusammen mit Matlab eine Temperaturmessung realisieren kann. Der Sensor soll hier ein ganz einfacher NTC Widerstand sein. Das bedeutet, der ohmsche Widerstand des Bauteils ändert sich mit der Temperatur, in dessen Umgebung sich das Bauteil befindet. Die Änderung passiert hier folgendermaßen: wenn die Temperatur steigt, so wird der ohmsche Widerstand kleiner. (Negativer Temperatur Koeffizient) (Coefficient engl. -> NTC). Einziger kleiner Haken – die Änderung passiert nicht linear wie zum Beispiel beim PT100. Das bedeutet der Verlauf  des Widerstands bei Änderung der Temperatur ist keine Gerade mit irgendeiner Steigung, sondern eine e-Funktion. Das wiederum bedeutet, dass, will man aus den gemessenen Widerstandwerten in eine Temperatur zurückrechnen, die Funktionsgleichung zum NTC gefunden werden muss. Glücklicherweise findet man diese aber fix und fertig in den Herstellerdatenblättern 😉 aber dazu später.

Man hat nun einen temperaturabhängigen Widerstand, ein Arduino Uno – Board und einen PC auf dem Matlab läuft. Wie geht´s nun weiter? Nehmen wir als Beispiel an, dass Matlab 2014b installiert ist. Nun gibt es in Matlab unter dem Tab „Home“ eine Rubrik, die sich „Add-Ons“ nennt. Klick man auf  diese, so klappt ein Menue auf, in dem man den Eintrag „Get Hardware Support Packages“ findet. Den klickt man an und es öffnet sich ein Fenster namens „Support Package Installer“.

Unter „Install from Internet“ und „Next>“ kommt man zu einem Auswahlmenue der verfügbaren Packages. Hier sucht man sich „Arduino“ aus und setzt im rechten Bereich des Fensters einen Haken – und zwar bei dem Paket „Aquire inputs and send outputs on Arduino Uno…“. Danach wieder auf „Next>“ klicken und die Installation vollenden.

Ist alles erledigt so kann man den Arduino am USB-Port anstecken. Windows sollte einen Treiber zuordnen. (Unter Systemsteuerung – Gerätemanger – Anschlüsse > sollte ein Arduino Uno (COMx) zu finden sein). Ist das der Fall, dann sollte es klappen 🙂

Jetzt kann in der Matlab Console folgender Befehl eingegeben werden:

arduino()

Folgende Antwort kommt nun zurück:

 arduino with properties:

Port: 'COM5'
Board: 'Uno'
AvailableAnalogPins: [0, 1, 2, 3, 4, 5]
AvailableDigitalPins: [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13]
Libraries: {'I2C', 'SPI', 'Servo'}

Der COM-Port unterscheidet sich natürlich und wird meist auf den nächsten freien COM gemappt. Hat das aber geklappt, so ist der erste Teil schon gewonnen. Matlab kommuniziert mit dem Arduinoboard. Es kann aber auch vorkommen, dass Fehlermeldungen auftauchen. Wie bei mir der Fall:

Cannot detect Arduino hardware. Make sure original Arduino hardware is properly plugged in. If
using unofficial(clone) hardware, specify port and board type. For more information, see the
arduino function reference page.

Das war die erste Meldung nach der Installation: Dafür gibt’s aber auch Abhilfe. Man gibt folgendes ein:

a = arduino('com5','Uno')

Wenn auch dann eine Fehlermeldung kommt, so wie natürlich bei mir, dann kann man mit folgendem commando auf Fehlersuche gehen:

 a = arduino('com5','Uno','TraceOn', true)

Jetzt kam bei mir die Meldung : Updating server code on Arduino Uno (COM5). Please wait.  Und danach gleich ein Errorfenster mit einem „avr-gcc.exe
Die Anwendung konnte nicht korrekt gestartet werden (0xc00000142)“ Fehler. Danach habe ich lange in diversen Foren gesucht, Tracelogs verglichen und nach den Fehlermeldungen gegoogelt. Hier gab es Tips von: die make.exe in den Tiefen des SupportPackages Ordner ist nicht kompatibel mit 64bit Systemen, mit Windows8.1 und Windows10 gibt es Zugriffsrechteprobleme und und und. Leider war aber nie ein Lösungsvorschlag dabei der bei mir funktionierte. Also habe ich auf einem zweiten Rechner eine jungfräuliche Installation von Matlab und dem Arduino Matlab Package durchgeführt. Und siehe da – es funktionierte. Aber wie jetzt nach dem Fehler suchen, oder ihn beheben. Also habe ich auf dem funktionierenden Rechner einen Tracelog durchgeführt, indem ich beim Aufrufen der Arduinofunktion einen Port angegeben habe, auf dem ein anderes NICHT Arudino Gerät angeschlossen ist. Und siehe da, der Errortracelog war seeehr lange und ausführlich. Man konnte ansehen was die Funktion alles aufruft. Und irgendwo ganz unten im Log las ich was von avrdude… Da kam mir die Idee. Auf meinem PC sind einige Entwicklungsumgebungen installiert. Unter anderem auch AVR-Studio und der WinAVR20100110 Compiler. Und genau der war das Problem. Den WinAVR gelöscht und schon klappte es.

Also steht dem weiteren Aufbau zur Realisierung des Projektchens nichts mehr im Weg. Aber darüber scheibe ich beim nächsten Mal in Teil 2…