Svenska ElektronikForumet

Tjena!

Jag har lite planer på ett projekt i vilket jag vill kunna styra en Arduino från flera enheter.

Ex, en Arduino för att styra olika saker och sedan kunna styra och läsa den från flera enheter.
Alltså t.ex. en dator och en bluetoothenhet och kanske fler Arduinos. Kanske även fler enheter.

Har flera Arduino Duemilanove och en Arduino Mega att labba med.
Har inget Bluetoothchip än men när allt är löst i teorin så skaffar jag ett

Frågan är hur jag bäst löser kommunikationen.
Har funderat lite på om man skulle ha en Arduino för att sköta kommunikation separat, men löser det helst med så få enheter som möjligt.

Hur hade ni gjort?

Det är inte helt tydigt, är det en Arduino som ska styra flera
olika "enheter" eller är det flera olika enheter som ska styra
en (samma ?) Arduino ?

Lösnigen blir sannolikt ganska beroende på vad du ska göra.
Just nu är det ganska generellt beskrivet och går knappast
(mer än ganska generellt) att svara på. Frågor som protokoll,
hastigheter, intervall, triggning o.s.v vet vi inget om just nu.

Om man med "flera enheter" menar att de ska kunde kommunicera på kryss och tvärs på samma buss blir det ganska knepigt!

Om man tänker seriell kommunikation kan RS485 vara svaret men då med 1 master och ett antal slavar. Det går med fler masters men det blir onödigt komplicerat.

Och i grunden är det fel! Att ha en mikroprocessor att styra en sak är bra, att ha fler i samma enhet och koppla dom ihop med kommunikation kräver mycket starka skäl! Det är helt enkelt:
* Har en processor inte nog med pinnar tar man en med fler pinnar!
* Har den inte minne nog till hela programmet tar man en med mer minne!
* Har den inte exekveringshastighet nog tar man en som kan köra snabbare!

Att öka processorkraften i ett samlat system vid att införa fler processorer och låta dom kommunicera på alla håll o kanter kommer att fungera dåligt och ha dålig upp-tid!

Om kommunikationen är utformat med en enda master och ett antal slavar som utför kommandon och svarar på frågor kan det dock fungera bra men det är ofta ett resursslöseri.

Hmm, blev lite mer generellt förklarat än vad jag tänkte

Vad jag ska göra är alltså en Arduino som styr några servon och relän.
Den Arduinon ska jag kunna skicka kommandon till att t.ex flytta ett visst servo eller slå av/på ett visst relä.
Alltså styra enkla saker som man normalt sett gör med en Arduino.

Jag vill även kunna fråga Arduinon om statusen på vissa ingångar och statusen på relän osv.

Sen ska jag med min Android telefon ansluta via Bluetooth till Arduinon för att skicka och ta emot information som kommandon osv.

Det är enkelt, det löser jag med en Arduino och en Bluetooth modul via seriell kommunikation till en Android app som jag skriver för ändamålet.

Men jag vill samtidigt kunna ha en dator ansluten för att kommunicera med Arduinon för att göra samma saker.
Datorn kommer inte vara ansluten hela tiden därför så måste Arduinon kunna styras från telefonen. Men datorn och telefonen måste kunna vara ansluten samtidigt.

Jag kan ju inte ha både datorn och andra enheter (som bluetoothmodul) ansluten på samma serieport till Arduinon.
Så vad jag klurar på är hur jag ska lösa det hela utan att ha en massa serieportar på Arduinon som styr det hela.

Funderar på om jag skulle ha en separat Arduino som är en sorts "kommunikationscentral" som sedan skickar vidare kommandona till den som första som håller i all styrning.

Alternativt så nöjer jag mig med att bara använda mobilen för att styra Arduinon, men det är inte lika roligt

Hoppas jag klarnat upp det hela lite mer!
Är ganska klart i min skalle

En lösning är ju att ha en ethernet shield med tcp/ip stack på arduinon. Android skulle då kunna ansluta via en wifi router eller AP.

Bra idé, det hade jag inte ens tänkt på.
Men tyvärr så är det en mobil lösning så strömförbrukningen skulle bli för hög.

Passar nog bra till andra framtida projekt, men inte för det här.

Josasp: enkelt att fixa om det finns 2 st UART i arduinon. Den ena används till BT och den andra till PC. Sedan är det bara att låta varje UART samla ihop var sin kommandosträng och exekvera dom i samma rutin.

Blir som jag misstänkte då, att jag får ta min Arduino Mega till det hela. Den har bla 4st UARTs.

Vad tror ni om att använda Software Serial annars? http://www.arduino.cc/en/Reference/SoftwareSerial

Nja... det är alltid skit med dessa funktioner! Kolla noga, det står att den bara kan klara upp till 9600 baud - vilket är helt OK.

MEN - Den väntar i "hämta" rutinen till det kommer data och det finns ingen möjlighet att ha den körande i bakgrunden.

Om din programmering tillåter att allt avstannar (även interrupts...) i väntan på en byte är det väl OK - men då har du helt andra problem...

I min värld finns dessa funktioner inte alls!

(Det låter ju riktigt kasst! Fattar inte att folk orkar hålla på med Arduino (men jag har inte testat iofs.) - jag tycker det verkar smidigare och mer flexibelt att bara ha en ren ATmega-processor utan jox. Nåja... det var bara en parentes)

Gör egna UART-rutiner som går helt på interrupt och som kan ha en tillräckligt lång buffert. (Jag har gjort några för ATmega644, men de är så specialiserade för sin uppgift att de knappast går att använda generellt utan att bygga om ganska mycket. (Jag hade på sikt tänkt göra ett generellt UART-bibliotek för ATmega, får se när det kommer... allt tar ju sin tid )

Du får ha dubbla buffertar för de olika kanalerna. I alla fall in. Du får ha något som avgör när ett kommando kommit in, t.ex return=ascii(13) som sätter en flagga att nu finns ett kommando att hämta. Sedan läser du av dessa flaggor i lugn och ro i main-loopen och utför det som kommer in först. På så vis blandar du inte ihop data. Där emellan har du oändligt med tid att kommunicera med övrig utrustning, SPI eller vad det är.

När det gäller andra externa enheter som reläer, sensorer mm så är det smartast att Arduino är Master och bestämmer när saker ska skickas eller läsas av istället för att dessa enheter ska kalla på uppmärksamhet och själva bestämma när de vill skicka data. Endast om det är extremt tidskritiskt finns det anledning att låta en extern enhet avbryta processorn för att skicka sina signaler. Risken är stor att du avbryter en pågående kommunikation med något annat och det kan bli lite bökigt att implementera.

Jesse, problemet är att SoftwareSerial över huvudtaget inte läser någonting
alls om man inte har anropat Serial.read(), och då kan man inte göra
någonting annat under tiden.

Se även :
http://www.arduino.cc/cgi-bin/yabb2/YaB ... 76181152/0

och : http://arduiniana.org/libraries/NewSoftSerial/.

Vad gäller mjukvarulösningar för seriekommunikation är "original"-SoftwareSerial inget att bry sig om. Sök efter NewSoftSerial, den gör vad den skall.

Bättre såklart med hårdvaru-UART.

Var lite försiktig med NewSoftwareSerial-libbet. Det är rackarns bra, men jag fick något slags mystiskt interrupt-problem som gjorde att min robot gjorde ganska oväntade saker när det kombinerades med lite andra bibliotek. Det hela löstes genom att flytta runt kodsnuttar tills det fungerade

Använd din Mega så är problemet löst?
Jesse: Det som gör att man orkar hålla på med Arduino är att det finns så mycket färdigt. Lätt att hitta kodexempel, lätt att programmera. Man slipper uppfinna hjulet flera gånger och kan lägga tiden på huvudlogiken i programmet.

Precis, man kör Arduino av samma anledning som stora maskintillverkare kör på ex. Simatic.
Bygga att från grunden kostar tid och ork som man kan lägga på annat.

Sen är det ju så att Arduino är billigare än Pic om man inte har utrustningen.