Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Pepa3000 27. 04. 2017, 18:41:39
-
Jake vhodne rozhrani/protokol zvolit pro komunikaci dvou Arduin na vzdalenost 10M?
-
dva draty a TTL urovne by mohly stacit, ne?
-
dneska jsou kůl ty blůtůty, běž s dobou! dráty jsou out
-
dráty jsou out
Správně. Já doporučuju morseovku přes pcspeaker. 8)
-
baba pohlova by tydlecty blututy a pc speakery zakazala :-)
na bluetooth potrebujes uz jiny modul, sledovani a audioanalyza pipaku ze speakeru je jeste horsi.
k arduinu trandaky na zesileni signalu ve dvou dratech, pripadne trech dratech na multiplex a dalsi arduino s trandakem.
staci posilat jednou za uherskou mikrosekundu nejaky stav, ze druhe arduino zije?
zadne srani se slozitosti, nebo si snad potrebuje predavat slozitejsi data?
co vyzkouset blikani diodou na jednom arduinu a fototrandak na druhem arduinu?
-
sledovani a audioanalyza pipaku ze speakeru je jeste horsi.
Zvládala to kybernetická želva se dvěma elektronkami před padesáti lety ;-)
-
TTL bude fungovat na stole na deset metrů v pohodě. Pokud to chcete někam do tvrdého nasazení, tak je třeba něco diferenciálně vedeného, nejlépe dostatečně galvanicky odděleno.
Volil bych RS485. Budič s IO MAX485, ten je dobrý. Laciné náhražky se kazí a když technika chcípne tak vždy v tu nejhorší možno chvíli.
-
Jake vhodne rozhrani/protokol zvolit pro komunikaci dvou Arduin na vzdalenost 10M?
Asi by bylo dobré říct zhruba co od toho očekáváš. Komunikace 2 Arduin na 10 m je dost vágní informace.
-
Chci si postavit alarm. 1 arduino je v roli ustredny a druhe v roli klavesnice. Klavesnice obsahuje i display pro zobrazovani stavu z ustredny. Klavesnice si bude s ustrednou vymenovat zadane kody a stavy ustredny.
-
ZigBee
-
Musíš li se na toto ptát na fóru, nedělej to !!!
-
Chci si postavit alarm. 1 arduino je v roli ustredny a druhe v roli klavesnice. Klavesnice obsahuje i display pro zobrazovani stavu z ustredny. Klavesnice si bude s ustrednou vymenovat zadane kody a stavy ustredny.
Keď to myslíš s ochranou objektu vážne, tak si tam daj nejaký Paradox, Jablotron, alebo niečo také. Arduino môže zbierať údaje o vlhkosti v kvetináči, ale život, zdravie a majetok by som mu nezveril.
-
Je to jen na hrani. Od rozblikane ledky, teplomeru, ctecek RFID chci trosku pokrocit. Tohle mi prijde zajimave.
chtel sem pouzit SPI vzhledem k moznosti pridani vice klavesnic, ale to neni na takovou dalku bez prevodniku urcene.
-
Na 10 metrů bude fungovat normální serial, I2C a 1Wire. SPI na 10 metrů by se muselo vyzkoušet, a asi nastavit raději nižší rychlost. Pozor na rušení a indukci napětí, to RS485 (jak radí kolega výše) by bylo nejrozumnější.
Pokud to má být bez drátů, tak na 10 metrů budou fungovat bezdrátové moduly v ceně malého balíčku žvýkaček na 433 MHz i 2,4 GHz. Oboje může být zarušeno vetřelcem, tak na to pozor.
-
Na 10 metrů bude fungovat normální serial, I2C a 1Wire. SPI na 10 metrů by se muselo vyzkoušet, a asi nastavit raději nižší rychlost. Pozor na rušení a indukci napětí, to RS485 (jak radí kolega výše) by bylo nejrozumnější.
Pokud to má být bez drátů, tak na 10 metrů budou fungovat bezdrátové moduly v ceně malého balíčku žvýkaček na 433 MHz i 2,4 GHz. Oboje může být zarušeno vetřelcem, tak na to pozor.
Urcite nechci bezdrat. Na RS485 akorat budu muset vyresit, ze pokud bezi interakce mezi klavesniciX a ustrednou tak jina klavesnice bude "mlcet". Spis teda I2C
-
Na 10 metrů bude fungovat normální serial, I2C a 1Wire. SPI na 10 metrů by se muselo vyzkoušet, a asi nastavit raději nižší rychlost. Pozor na rušení a indukci napětí, to RS485 (jak radí kolega výše) by bylo nejrozumnější.
Pokud to má být bez drátů, tak na 10 metrů budou fungovat bezdrátové moduly v ceně malého balíčku žvýkaček na 433 MHz i 2,4 GHz. Oboje může být zarušeno vetřelcem, tak na to pozor.
Urcite nechci bezdrat. Na RS485 akorat budu muset vyresit, ze pokud bezi interakce mezi klavesniciX a ustrednou tak jina klavesnice bude "mlcet". Spis teda I2C
To nemusíš řešit. Stačí použít MASTER - SLAVE komunikační protokol a mít ústřednu jako master a klávesnice jako slave.
-
já ke spokojenosti používám
bezdrátové modulky NRF24L01
na ebay tak za 20kč
https://www.youtube.com/watch?v=kPJ9wPWJJhY
ale...
drát je drát :))
-
... NRF24L01 ...
Na jaké rychlosti ti to běží? Budu potřebovat něco podobného a zatím jsem plánoval dražší HC12. Díky.
-
... NRF24L01 ...
Na jaké rychlosti ti to běží? Budu potřebovat něco podobného a zatím jsem plánoval dražší HC12. Díky.
To nevím, mám to jako domovní zvonek + vrátný + chipové otevírání dveří, aby děcka nemusely mít klíče.
Dělal jsem to podle tohoto
https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo
o rychlosti možná bude něco ve specifikaci
http://www.nordicsemi.com/eng/content/download/2730/34105/file/nRF24L01_Product_Specification_v2_0.pdf
Mě se na tom líbí cena poměr/výkon + dostupné informace a knihovna s examples přímo v IDE Arduina.
-
Mam skoro hotovo...
Pres i2c dostava klavesnice informace pro zobrazovani na LCD + dalsi stavove informace v CSV formatu.
Narazil sem ovsem na rozdeleni csv do patricnych promennych.
retezec
String retezec="STAVA;STAVB;STAVC";
potrebuji rozdelit pomoci oddelovace ; do promennych
Muze nekdo pomoct?
-
Jedine kabel, protoze problemy zacinaji tam, kde konci kabel. Kabel a RS485 - mam odzkouseno v praxi vzdalenost +- 30m a jede kraasne. Podle ruznych clanku to jde i na delsi trasu napr http://www.arduino8.cz/lekce-35-arduino-komunikace-pres-rs485-az-na-vzdalenost-1200m/ (http://www.arduino8.cz/lekce-35-arduino-komunikace-pres-rs485-az-na-vzdalenost-1200m/)
-
potrebuji rozdelit pomoci oddelovace ; do promennych
Muze nekdo pomoct?
sscanf http://stackoverflow.com/a/35168657
-
Mam skoro hotovo...
Pres i2c dostava klavesnice informace pro zobrazovani na LCD + dalsi stavove informace v CSV formatu.
Narazil sem ovsem na rozdeleni csv do patricnych promennych.
retezec
String retezec="STAVA;STAVB;STAVC";
potrebuji rozdelit pomoci oddelovace ; do promennych
Muze nekdo pomoct?
Takže jsi se nakonec rozhodl pro I2C? Na 10 metrů? A I2C děláš jen přes piny Arduina a nebo používáš nějaký posilovač sběrnice (buffer)? Třeba P82B96?
A k tomu dotazu na parsování řetězce: proč to řešíš takhle složitě? Proč nevyužiješ vlastnosti I2C komunikace a nepošleš STAVA s jednou adresou, STAVB s další adresou a STAVC s úplně jinou adresou? Nemusíš nic parsovat, jen přijatou zprávu uložíš do různých proměnných v závislosti na adrese.
-
potrebuji rozdelit pomoci oddelovace ; do promennych
Muze nekdo pomoct?
sscanf http://stackoverflow.com/a/35168657
Proboha, jen to ne!!! Proč používat na jednočipu pro tak triviální záležitost obludné funkce z rodiny ?printf /?scanf??? To není to samé jako PC nebo server. Je třeba trochu přemýšlet.
-
A ještě k té I2C. Tohle je její stručná charakteristika:
I²C (Inter-Integrated Circuit), pronounced I-squared-C, is a multi-master, multi-slave, packet switched, single-ended, serial computer bus invented by Philips Semiconductor (now NXP Semiconductors). It is typically used for attaching lower-speed peripheral ICs to processors and microcontrollers in short-distance, intra-board communication. Alternatively I²C is spelled I2C (pronounced I-two-C) or IIC (pronounced I-I-C).
Není to úplně to pravé pro daný účel...
-
Mam skoro hotovo...
Pres i2c dostava klavesnice informace pro zobrazovani na LCD + dalsi stavove informace v CSV formatu.
Narazil sem ovsem na rozdeleni csv do patricnych promennych.
retezec
String retezec="STAVA;STAVB;STAVC";
potrebuji rozdelit pomoci oddelovace ; do promennych
Muze nekdo pomoct?
Takže jsi se nakonec rozhodl pro I2C? Na 10 metrů? A I2C děláš jen přes piny Arduina a nebo používáš nějaký posilovač sběrnice (buffer)? Třeba P82B96?
A k tomu dotazu na parsování řetězce: proč to řešíš takhle složitě? Proč nevyužiješ vlastnosti I2C komunikace a nepošleš STAVA s jednou adresou, STAVB s další adresou a STAVC s úplně jinou adresou? Nemusíš nic parsovat, jen přijatou zprávu uložíš do různých proměnných v závislosti na adrese.
JJ, pomoci I2C, nekdo tu psal, ze to je na 10M ok. V pripade problemu mam resit snad frekvenci na ktere to pojede.
Proč nevyužiješ vlastnosti I2C komunikace a nepošleš STAVA s jednou adresou, STAVB s další adresou a STAVC s úplně jinou adresou?
Neco takoveho?
+potreboval bych poslat i string ne jenom byte. STAVC je string
Master:
Wire.beginTransmission(88);
Wire.write(STAVA);
Wire.write(STAVB);
Wire.write(STAVC);
Slave:
void receiveEvent(int howMany) {
STAVA = Wire.read();
STAVB = Wire.read();
STAVC = Wire.read();
}
-
Zaprvé, nejdříve kritika:
- I2C na komunikaci mezi 2 zařízeními (procesorovými jednotkami) na cca 10 m je pěkná zhovadilost. Ano, ono to nakonec nějak bude fungovat, třeba sundáš hodiny jak píšeš. Nejspíš. Většinou. Ale není to na to stavěné. Když už, použít nějaký I2C bus buffer na proudové posílení. Ale nechápu proč do toho jít u úplně nového systému, kde si můžeš vybrat co chceš.
- Posílat si přes I2C zprávy v řetězcích oddělených středníkem je další blbost. Ne že by to nakonec nešlo, ale je strašná krávovina
- na embedded zařízeních a speciálně těch s AT Mega a podobně výkonnými procesory nemá funkce sscanf a jí podobné co dělat. A to z více důvodů. Ne že by to nějak nefungovalo, ale žere příliš zdrojů a (podle implementace) může být náročná na paměť na zásobníku. Všechno špatně pro systém s omezenými zdroji.
A teď má doporučení:
1. Komunikace: RS-485 (nemáš peer-2-peer, ale spojuješ více zařízení, takže RS-232 nejde). I2C je pro komunikaci mezi součástkami na jedné desce, případně více deskách, ale v rámci stejného zařízení.
2. Neposílej zprávu, kterou pak musíš složitě parsovat, najednou. Využij nějaký standardní protokol (třeba modbus s otevřenou implementací - www.modbus.org). A pro každý řetězec si zadefinuj zprávu (kód). Takže když budeš posílat data, pošleš v hlavičce adresu zařízení (na který displej to posíláš), za ní kód zprávy (0: Stav A, 1: Stav B, 2: Stav C, ...), a následně řetězec. U Modbusu budeš mít jasně dané mantinely implementací protokolu. Modbus přes RS-485 je ověřené, stabilní a spolehlivé řešení.
3. Nepoužívej sscanf - pro "malé" procesory v embedded systémech je to žrout zdrojů a zabiják výkonu.
Pokud se i přesto rozhodneš zůstat u I2C, najdi si datasheet nějaké součástky, která I2C používá a inspiruj se tím, jak ho používají. Třeba nějaký LED displej kontrolér (např. http://www.ti.com/lit/ds/symlink/tpic2810.pdf - podívej se na Slave address, sub-address, data). A doporučím ti osadi nějaký I2C buffer na těch 10 m. Jaký vlastně máš kabel? UTP? Na jaké vodiče jsi zapojil SDA a SCL? Doufám že ne do jednoho páru.
-
Proč nevyužiješ vlastnosti I2C komunikace a nepošleš STAVA s jednou adresou, STAVB s další adresou a STAVC s úplně jinou adresou?
Neco takoveho?
+potreboval bych poslat i string ne jenom byte. STAVC je string
Master:
Wire.beginTransmission(88);
Wire.write(STAVA);
Wire.write(STAVB);
Wire.write(STAVC);
Slave:
void receiveEvent(int howMany) {
STAVA = Wire.read();
STAVB = Wire.read();
STAVC = Wire.read();
}
Vůbec nerozumíš tomu, jak I2C funguje.
Wire.beginTransmission(slave_address); // Adresa slave zařízení
Wire.write(subadr); // Kód zprávy (0 = STAVA, 1 = STAVB, ...)
Wire.write("Blábol"); // String
Wire.endTransmission(); // stop transmitting
[/quote]
Ve slavu (klavesnice) si přečteš první byte (0-2) a podle jeho hodnoty potom použiješ přijatá data jako STAVA, STAVB nebo STAVC...
-
Na 485 si musíš napsat sám formát paketů, adresování, řízení slave nodů (aby odpovídal jen ten správný..)..., pokud bude komunikace jednosměrná, tak ti stačí vymyslet pakety s adresou a použít jednodušší RS422. Obojí se dá připojit k UART periferii toho Arduina.
Další možností je pak třeba CAN. ARM Cortex M kontrolery (jako třeba ten v Arduino Due) ho dost často obsahují a stačí jen dodat transceivery a kabeláž. Je to složitější protokol na nastavení než jen sériová linka, ale zase ti už přímo řeší pakety a jejich kolize. Klasické Arduino (Uno) CAN neumí, ale MCP2515 je typicky používaná součástka (existuje dost knihoven), která ho přidá.
-
Tak radeji teda Rs485 s modbus
-
Ale jinak co se týká zarušení útočníkem.. DoS znamená, že se nikdo nedostane dovnitř příp. neodblokuje alarm že? Možná by mohlo být zajímavé přemýšlet i o tom co se stane, když do klávesnice chrstne vodu. Je to totiž mnohem levnější a blbější typ 'útoku' :)
Se zarušeným SPI (zařízení byl vzdáleně řízený tuner pro anténu, takže pekelné prostředí..) mám zkušenost na vzdálenost víc jak 30m, ale chtělo to nižší rychlost a diferenciální páry. Nová verze téhož bude používat CAN (protože senzory s asynchronním posíláním zpráv). I2C je v tomhle nechutné kvůli clock stretching (ty oficiální budiče jsou celkem drahé). RS485 je super, stačí málo drátů, ale chce to dobře napsat software.
A musím souhlasit s Mirkem. Mikrokontroléry o téhle velikosti komunikují textově maximálně s uživatelem. Mezi sebou jedině binárně!
S Modbusem přes RS485 mám osobně dva problémy:
- pořád neřeší linkovou vrstvu (tj multi master kolize), což jde pokud ty zprávy nejsou asynchronní a řídící jednotka se na všechno doptává (pak doporučuju mít jeden drát/pár v pull-up open collector konfiguraci na signalizaci přerušení)
- implementace zabírá místo a někdo ji musí udělat (knihovny asi jsou), což je nevýhoda oproti CANu, který v těch mikrokontrolerech už často je zabudovaný
A obecně alarm, dvě klávesnice a pár senzorů (a RFID/NFC?) je pořád dost vágní. I jako hračka by to asi nemělo být úplně snadno obejitelné obzvláště pokud to bude u vstupu do domu... Bacha třeba na replay attack (odposlechnutí a pozdější zopakování komunikace).
-
Zkousim to ted cvicne pomoci RS485 vlastnim protokolem.
Mam gsm modul a pro seriovy port smerem ke klavesnicim pouzivam SoftwareSerial.
Mam, ale situaci kdy mi muze master uvaznout.
Na zacatku odesilani stavu ustredny a doptavani se na heslo zadane na klavesnici je klavesnice prvne adresovana a ceka se jestli je dostupna.
Odzabezpecit tak zonu v pripade mrtve klavesnice by neslo ani prostrednictvim druhe.
Pokud v ten moment nic neprijde, master uvazne. U SoftwareSerial sem nenasel nic pro timeout.
-
mozna funkce portOne.available()?
-
Proboha, jen to ne!!! Proč používat na jednočipu pro tak triviální záležitost obludné funkce z rodiny ?printf /?scanf??? To není to samé jako PC nebo server. Je třeba trochu přemýšlet.
[/quote]
Máš nějaké linky ohledně vyšší výpočetní náročnosti oproti jiným řešením? Nic se mi najít nepodařilo.
-
Na 485 si musíš napsat sám formát paketů, adresování, řízení slave nodů (aby odpovídal jen ten správný..)..., pokud bude komunikace jednosměrná, tak ti stačí vymyslet pakety s adresou a použít jednodušší RS422. Obojí se dá připojit k UART periferii toho Arduina.
Další možností je pak třeba CAN. ARM Cortex M kontrolery (jako třeba ten v Arduino Due) ho dost často obsahují a stačí jen dodat transceivery a kabeláž. Je to složitější protokol na nastavení než jen sériová linka, ale zase ti už přímo řeší pakety a jejich kolize. Klasické Arduino (Uno) CAN neumí, ale MCP2515 je typicky používaná součástka (existuje dost knihoven), která ho přidá.
Nechci rejpat, ale už jsi někdy opravdu programoval něco multislave s RS485? Ve skutečnosti je to strašně jednoduché a vůbec bych to nesrovnával s CAN.
RS485 je, dá se říct, složitostí v podstatě na úrovni I2C implementace ve Wiring.
-
S Modbusem přes RS485 mám osobně dva problémy:
- pořád neřeší linkovou vrstvu (tj multi master kolize), což jde pokud ty zprávy nejsou asynchronní a řídící jednotka se na všechno doptává (pak doporučuju mít jeden drát/pár v pull-up open collector konfiguraci na signalizaci přerušení)
- implementace zabírá místo a někdo ji musí udělat (knihovny asi jsou), což je nevýhoda oproti CANu, který v těch mikrokontrolerech už často je zabudovaný
Ale podle mne tazatel nepotřebuje Multi-master. Má řídicí jednotku (master) a několik klávesnic (slave). Nevidím v tom naprosto žádný problém.
Implementace Modbusu pro mikrokontroléry je tady: https://sourceforge.net/projects/freemodbus.berlios/
Spousta free nástrojů zde: http://www.modbus.org/tech.php
-
Proboha, jen to ne!!! Proč používat na jednočipu pro tak triviální záležitost obludné funkce z rodiny ?printf /?scanf??? To není to samé jako PC nebo server. Je třeba trochu přemýšlet.
Máš nějaké linky ohledně vyšší výpočetní náročnosti oproti jiným řešením? Nic se mi najít nepodařilo.
[/quote]
Opravdu se ptáš na porovnání náročnosti sscanf() a jednoduché fce, která kopíruje znaky do prvního stringu, když narazí na ";" začne do druhého a po dalším ";" do třetího a skončí?
Napiš si krátký prográmek s implementací obojího a změř si čas + paměťovou náročnost.
printf/scanf knihovny mívají i pár kB kódu - podle rozsahu implementace. Opravdu má smysl plýtvat pamětí? Je běžné, že libc mívá 2 verze - základní bez printf/scanf, a rozšířenou s jejich podporou.
-
Nechci rejpat, ale už jsi někdy opravdu programoval něco multislave s RS485? Ve skutečnosti je to strašně jednoduché a vůbec bych to nesrovnával s CAN.
Multi-slave ano, to je dost primitivní. Hodně se snažím minimalizovat spotřebu a tam navíc pomůže mít ten interrupt signál.
V tom úplně původním dotazu byly zmíněné senzory / RFID, a proto jsem nabyl dojmu, že by to mohl chtít rozšířit o čtečku karet, pohybové čidlo a podobně (když ne hned, tak hned potom). A tam už multi master může mít svoje opodstatnění (alarm funkční i bez hlavní jednotky...).
Samozřejmě souhlasím, že CAN implementace je složitá, když si ji člověk musí napsat sám. Jenže proč bych to dělal, když už to dneska má kde co jako zabudovanou periferii.. 8 bit Arduino už totiž nepatří mezi moje platformy první volby, za stejnou (nebo spíš nižší - $13) cenu mám třeba Tiva C Launchpad, která se dá programovat úplně stejně (mno 99%) jako to Arduino (pomocí Enerigia IDE).
Nemá cenu diktovat Pepovi co má použít. Ale má cenu mu ukázat, že se to dá lepit i jinak. Jen musí vědět co chce vlastně vytvořit a jak spolehlivé to má být. Přístup typu "jediný můj nástroj je kladivo, tak se budu tvářit, že všechno je hřebík" totiž není zrovna ideální.
-
Nechci rejpat, ale už jsi někdy opravdu programoval něco multislave s RS485? Ve skutečnosti je to strašně jednoduché a vůbec bych to nesrovnával s CAN.
Multi-slave ano, to je dost primitivní. Hodně se snažím minimalizovat spotřebu a tam navíc pomůže mít ten interrupt signál.
V tom úplně původním dotazu byly zmíněné senzory / RFID, a proto jsem nabyl dojmu, že by to mohl chtít rozšířit o čtečku karet, pohybové čidlo a podobně (když ne hned, tak hned potom). A tam už multi master může mít svoje opodstatnění (alarm funkční i bez hlavní jednotky...).
Samozřejmě souhlasím, že CAN implementace je složitá, když si ji člověk musí napsat sám. Jenže proč bych to dělal, když už to dneska má kde co jako zabudovanou periferii.. 8 bit Arduino už totiž nepatří mezi moje platformy první volby, za stejnou (nebo spíš nižší - $13) cenu mám třeba Tiva C Launchpad, která se dá programovat úplně stejně (mno 99%) jako to Arduino (pomocí Enerigia IDE).
Nemá cenu diktovat Pepovi co má použít. Ale má cenu mu ukázat, že se to dá lepit i jinak. Jen musí vědět co chce vlastně vytvořit a jak spolehlivé to má být. Přístup typu "jediný můj nástroj je kladivo, tak se budu tvářit, že všechno je hřebík" totiž není zrovna ideální.
Chápu tě. Já jsem z Pepových dotazů pochopil jedno - potřebuje jednoduché a srozumitelné řešení. V komunikacích a v embedded je nováček a jeho hlavní požadavek na ten alarm je aby se na něčem praktickém naučil dělat s Arduinem i trochu složitější věci a měl nakonec radost že to funguje. Komplikovanější věci až na dalších projektech... To je alespoň můj názor.
-
Nejlevnější arduino (klon, mega328, ale zatím mi vždy fungovalo na 100%) vyjde na 40 Kč s dopravou https://www.aliexpress.com/item/Free-shipping-2pcs-lot-New-pro-mini-electronic-building-blocks-Interactive-Media-ATMEGA328P-5V-16M-for/1982267942.html
-
Chapu nadseni vsech pro rs485. I kdyz jeste pred tim bych se zamyslel, jestli mu na 10 metru nestaci obycejny ttl uart. Jestli ma tech vysilaci nebo prijemcu jenom par, tak by to mozna stacilo pres nejake odpory nebo diody proste zapojit do sebe, ale asi by to byla prasecina, rs485 je spravnejsi reseni.
Co se tyka protokolu, tak nez resit, odkud opsat dobre udelanej modbus, tak bych se vubec nebal si znovu vymyslet vlastni kolo a na modbus bych se vykaslal. Preci jenom zrovna na Arduinu mi vadi, ze nektere knihovny na netu jsou dost amaterske a zrovna tohle je fakt trivialni uloha, kde hledani spravne knihovny muze zabrat zbytecne moc casu.
Za jeden vecer to vymysli, za druhy vecer naprogramuje a za treti vecer odladi. To uz jsme tady prodiskutovali mnohem vic casu.
-
Jen poznámka na okraj: na rozsekání podle středníků bych použil strtok (https://linux.die.net/man/3/strtok) (všichni zkritizovali sscanf, ale rozumnou náhradu nikdo nezmínil).
char *prvni = strtok(zprava, ";");
char *druhy = strtok(NULL, ";");
char *treti = strtok(NULL, ";");
-
Nahradu tady nekdo zminil - neposilat stredniky.
-
Chapu nadseni vsech pro rs485. I kdyz jeste pred tim bych se zamyslel, jestli mu na 10 metru nestaci obycejny ttl uart. Jestli ma tech vysilaci nebo prijemcu jenom par, tak by to mozna stacilo pres nejake odpory nebo diody proste zapojit do sebe, ale asi by to byla prasecina, rs485 je spravnejsi reseni.
Prosím, postni sem schéma jak si to přesně představuješ + vysvětlení toho, co Pepa3000 přesně získá tím, že nepoužije standardní RS485 v katalogovém zapojení (1 malý IC), ale nějaký bastl ve kterém bude RS232 budič (1 IC) + blíže nespecifikované množství dalších součástek s pochybnou šancí na úspěch.
Co se tyka protokolu, tak nez resit, odkud opsat dobre udelanej modbus, tak bych se vubec nebal si znovu vymyslet vlastni kolo a na modbus bych se vykaslal. Preci jenom zrovna na Arduinu mi vadi, ze nektere knihovny na netu jsou dost amaterske a zrovna tohle je fakt trivialni uloha, kde hledani spravne knihovny muze zabrat zbytecne moc casu.
Za jeden vecer to vymysli, za druhy vecer naprogramuje a za treti vecer odladi. To uz jsme tady prodiskutovali mnohem vic casu.
Chápu tvé nadšení. Ale znovu si projdi Pepovy dotazy. Možná se pletu, ale myslím že tohle by pro něj představovalo opravdu hodně práce s relativně malou šancí na úspěch. Já bych mu doporučil jít cestou implementace standardního, ověřeného řešení. Pokud si bude chtít pohrát s programováním, ať vezme Modbus ASCII protokol a podle specifikace ho naprogramuje sám. Je to poměrně jednoduché.
-
Jen poznámka na okraj: na rozsekání podle středníků bych použil strtok (https://linux.die.net/man/3/strtok) (všichni zkritizovali sscanf, ale rozumnou náhradu nikdo nezmínil).
char *prvni = strtok(zprava, ";");
char *druhy = strtok(NULL, ";");
char *treti = strtok(NULL, ";");
Rozumnou náhradu nikdo nezmínil?
"Opravdu se ptáš na porovnání náročnosti sscanf() a jednoduché fce, která kopíruje znaky do prvního stringu, když narazí na ";" začne do druhého a po dalším ";" do třetího a skončí?"
-
Nahradu tady nekdo zminil - neposilat stredniky.
Přesně tak. Pro danou platformu je řešením navrhnout lépe komunikační protokol a odstranit nutnost parsovat string.
-
V tom úplně původním dotazu byly zmíněné senzory / RFID, a proto jsem nabyl dojmu, že by to mohl chtít rozšířit o čtečku karet, pohybové čidlo a podobně (když ne hned, tak hned potom). A tam už multi master může mít svoje opodstatnění (alarm funkční i bez hlavní jednotky...).
V informacích od Pepik3000 je, že dříve dělal se senzory, RFID, ... a teď chce udělat něco složitějšího.
"Je to jen na hrani. Od rozblikane ledky, teplomeru, ctecek RFID chci trosku pokrocit. Tohle mi prijde zajimave. "
Za mně je to poměrně jednoduché - ústředna jako master a v pravidelných intervalech (třeba 100 ms) "oblizuje" všechny slave, jestli pro ni nemají něco nového. Pokud ano, přečte si to a zareaguje. Následně do všech slave odešle příslušné výsledky (zprávy na display, ...) a jede se dál. Prostě klasika.
A navíc, i s těmi senzory to stále jde realizovat se single master. Netvrdím že Modbus je optimální, ale je jednoduchý na pochopení a implementace jsou normálně k dispozici.
-
Chapu nadseni vsech pro rs485. I kdyz jeste pred tim bych se zamyslel, jestli mu na 10 metru nestaci obycejny ttl uart. Jestli ma tech vysilaci nebo prijemcu jenom par, tak by to mozna stacilo pres nejake odpory nebo diody proste zapojit do sebe, ale asi by to byla prasecina, rs485 je spravnejsi reseni.
Prosím, postni sem schéma jak si to přesně představuješ + vysvětlení toho, co Pepa3000 přesně získá tím, že nepoužije standardní RS485 v katalogovém zapojení (1 malý IC), ale nějaký bastl ve kterém bude RS232 budič (1 IC) + blíže nespecifikované množství dalších součástek s pochybnou šancí na úspěch.
No, jak rikam, byla by to prasecina, ale vubec bych se nedelal s urovnema rs232. Proste master by mel Tx rozvedeny primo na Rx vsech slavu. Snad by to ubudil. (Kdyby neubudil, tak pres tranzistor a odpor.) A druhym smerem bych se inspiroval ve schematu pro Arduino Nano. Uvidis tam 1k odpor z USB prevodniku do Rx ATmegy. Podle me to je z toho duvodu, ze autori predpokladaji, ze nekdo nebude chtit komunikovat pres USB, ale primo (respektive pres svuj spravne velky odpor) na Rx. Jednou jsem to zkousel (ovsem na vzdalenost 10 cm) a fungovalo to. Ale spis bych dal ke kazdemu slavu k jeho Tx diodu v zavernem smeru a master beztak uz ma na Rx uvnit atmegy zapnuty pullup.
Doufam, ze jsem alespon pobavil, a ted hrrr do me... :)
-
Mam nasledujici test:
Slave:
called=mySerial.read();
if (called==ID){
mySerial.write(123);
armState = mySerial.read();
}
Serial.println(armState);
Master:
void loop() { // run over and over
mySerial.write(88);
while (mySerial.available() > 0){
inByte = mySerial.read();
Serial.println(inByte);
}
mySerial.write(armState); // posila pouze jeden byte
}
Na vystupu slave, ale dostavam:
5
5
5
5
-1
-1
-1
5
5
5
5
Nevim proc tam skace ta -1. Je to nejakym zpozdenim?
-
Jenom prvni napad: nemuze slave ten armState zkouset precist driv, nez ho master zapise?
-
Chlape, čti dokumentaci než se budeš ptát:
"Returns: the first byte of incoming serial data available (or -1 if no data is available) - int"
Zdroj: https://www.arduino.cc/en/Serial/read
-
Chapu nadseni vsech pro rs485. I kdyz jeste pred tim bych se zamyslel, jestli mu na 10 metru nestaci obycejny ttl uart. Jestli ma tech vysilaci nebo prijemcu jenom par, tak by to mozna stacilo pres nejake odpory nebo diody proste zapojit do sebe, ale asi by to byla prasecina, rs485 je spravnejsi reseni.
Prosím, postni sem schéma jak si to přesně představuješ + vysvětlení toho, co Pepa3000 přesně získá tím, že nepoužije standardní RS485 v katalogovém zapojení (1 malý IC), ale nějaký bastl ve kterém bude RS232 budič (1 IC) + blíže nespecifikované množství dalších součástek s pochybnou šancí na úspěch.
No, jak rikam, byla by to prasecina, ale vubec bych se nedelal s urovnema rs232. Proste master by mel Tx rozvedeny primo na Rx vsech slavu. Snad by to ubudil. (Kdyby neubudil, tak pres tranzistor a odpor.) A druhym smerem bych se inspiroval ve schematu pro Arduino Nano. Uvidis tam 1k odpor z USB prevodniku do Rx ATmegy. Podle me to je z toho duvodu, ze autori predpokladaji, ze nekdo nebude chtit komunikovat pres USB, ale primo (respektive pres svuj spravne velky odpor) na Rx. Jednou jsem to zkousel (ovsem na vzdalenost 10 cm) a fungovalo to. Ale spis bych dal ke kazdemu slavu k jeho Tx diodu v zavernem smeru a master beztak uz ma na Rx uvnit atmegy zapnuty pullup.
Doufam, ze jsem alespon pobavil, a ted hrrr do me... :)
Pobavil, nepobavil. To je jedno. Zajímá mně jediná věc: proč bys to dělal? Co ti to přinese? Ve skutečnosti to jde udělat i snáz (https://www.maximintegrated.com/en/app-notes/index.mvp/id/723), ale proč? Mimo jiné např budeš potřebovat navíc jeden RS232 budič na zařízeních "uvnitř" sítě.
Tak tedy znovu - proč by Pepa3000 měl, namísto RS485 určeného pro připojení velkého množství zařízení použít RS232 určený pro point-to-point? Nebo dokonce snad i jen TTL úrovně přímo z pinů MCU?
Co mu to přinese?
-
A ještě dodám, jednoduchý SN75176 pro RS485 (vím, má své mouchy, ale na uvedený účel bohatě stačí), stojí 10-15 Kč. RS232 budiče jsou výrazně dražší.
-
Nebo dokonce snad i jen TTL úrovně přímo z pinů MCU?
Jo, presne tak jsem to myslel. :)
Co mu to přinese?
Spoustu zabavy.
(Nez se na to vykasle a udela to po rs485. Evidentne to je nejaky student, ktery ma spoustu casu na pokusy a objevovani, kudy ne. Tohle mu neublizi.)
Jinak dekuji za doplneni vzdelani, SN75176 jsem neznal. Vzdycky jsem v prumyslu pracoval pouze s celymi hotovymi prevodniky "RS485 na neco", napr. od Papoucha. Na ebayi je tech brouku dokonce 5 kusu za dolar.
-
Spoustu zabavy.
Přesně, pokud ho opravdu nechcete zatěžovat komplikacema, tak ať se vykašle na diferenciální vedení, rozchodí si to na stole přes čisté "TTL" (klidně s vlastním protokolem) a pak tam "jen" vloží RS485 driver, přidá nějakou XOR kontrolu, případně naimplementuje modbus. Stejně musí nejdříve přijít na to jak navrhnout aplikační logiku. Dekompozice problému na jednodušší celky ho naučí mnohem víc, než když to nějak slepí a nebude vědět proč.
(Nez se na to vykasle a udela to po rs485. Evidentne to je nejaky student, ktery ma spoustu casu na pokusy a objevovani, kudy ne. Tohle mu neublizi.)
Taky si myslím. Než se dostane k 10m vzdálenosti nodů v zarušeném prostředí nebo dvěma klávesnicím, tak přijde ještě na hodně dalších otázek.
-
A taky dostal...
Ustredna:
void loop() { // run over and over
keypad();
}
void keypad(){
// Send base information and password request
mySerial.write(88);
if (mySerial.available() > 0){
int status=mySerial.read();
if (status==1){
while (mySerial.available() > 0){
int intByte= mySerial.read();
password+=(int)intByte;
}
mySerial.write(armState);
mySerial.write(passwordState);
}
}
}
Klavesnice:
void loop() { // run over and over
called=mySerial.read();
if (called==ID){
serialInterrupt();
}
Serial.println(armState);
}
void serialInterrupt(){
mySerial.write(1);
mySerial.write(passwd);
if (mySerial.available() > 0){
armState = mySerial.read();
}
if (mySerial.available() > 0){
passwordState = mySerial.read();
}
}
Problem je ze v kodu klavesnice dostavam do promennych "armstate" nebo "passwordState" hodnotu 88, tedy oznaceni startu komunikace s pozadovanou klavesnici.
-
No to je divny, vid. :)
Kdyz podle ukazky tam ustredna porad tlaci 88. Ovsem nekdy se skutecne muze stat, ze pred dokoncenim odeslani 88 z ustredny prijde z klavesnice jednicka a v takovem pripade ustredna klavesnici posle i neco jineho nez 88.
Hele, mas vubec tuseni, co se ti tam odehrava?
Jak vubec to posilani a prijem probiha a jak dlouho to trva?
Co takhle nejake timeouty?
Co takhle neco jako nejake pakety s nejakym uvozovacim znakem, delkou, kontrolnim souctem, atd.?
Nechces si treba prohlednout, jak vypada komunikace modbusem? Nemyslim nejakou knihovnu, myslim ten protokol. Zrejme to pro tebe bude docela objevne.
-
void loop() { // run over and over
keypad();
}
void keypad(){
// Send base information and password request
mySerial.write(88);
Je ti jasné, že to 88 posíláš ve smyčce pořád dokola? Ta odpověď nestihne přijít včas na to, aby ten následující if hned něco provedl. Takže se zamysli nad časováním.
if (mySerial.available() > 0){
int status=mySerial.read();
if (status==1){
while (mySerial.available() > 0){
Tady počítáš s tím, že ten přenos bude dost rychlý na to, aby celé heslo bylo v paměti dřív, než proběhne ten tvůj while. No a ono nebude. Pošli si nejdřív délku, ať víš kolik znaků čekat. available() ti jenom řekne, jestli čekají přijatá data v bufferu.
int intByte= mySerial.read();
password+=(int)intByte;
Plus? Cože si to posíláš? Co je password? String? Takhle se totiž stringy v C nespojují..
Klavesnice:
void loop() { // run over and over
called=mySerial.read();
if (called==ID){
serialInterrupt();
}
Serial.println(armState);
}
A co když to ID nesedí? To je pak zpráva pro někoho jiného a měl bys ji celou ignorovat než zase začneš čekat na ID. Další důvod proč posílat i délku.
void serialInterrupt(){
mySerial.write(1);
mySerial.write(passwd);
if (mySerial.available() > 0){
armState = mySerial.read();
}
Zase available(). Ono to opravdu udělá něco jiného než čekáš. Tady by asi mělo být spíš while(!mySerial.available());
if (mySerial.available() > 0){
passwordState = mySerial.read();
}
A tady taky.
Problem je ze v kodu klavesnice dostavam do promennych "armstate" nebo "passwordState" hodnotu 88, tedy oznaceni startu komunikace s pozadovanou klavesnici.
Tomu se vůbec nedivím. To Arduino běží na 16Mhz, TTL UART je tam typicky nastavený na 115200 baud (nebo dokonce jen 9600), tj nepočítej s tím, že ti přijde odpověď hned v čase pro další instrukci. Synchronizaci ti musí dělat ty zprávy a to Arduino na ně musí počkat. Druhá věc je to, že posíláš výzvu 88 pořád dokola místo čekání na odpověď a neznáš délku odpovědi, abys rozhodl, že už ji máš celou.
-
Dejte už pokoj s MODBUSem. To jste si nevšimli, že studovat strukturu jeho rámců (a důvod pro ni) je poněkud víc než zvládne? Trocha googlení mi ale našla třeba celkem slušné pojednání tady: http://eli.thegreenplace.net/2009/08/12/framing-in-serial-communications/
-
Ale když už o něm mluvíte, zajímá ho sekce 2.5.1.1 z http://www.modbus.org/docs/Modbus_over_serial_line_V1.pdf
A je to ten framing typ 1) z toho článku výše.
-
Zase available(). Ono to opravdu udělá něco jiného než čekáš. Tady by asi mělo být spíš while(!mySerial.available());
V momente kdy je klavesnice adresovana a zacnou se vymenovat data s utrednou mi prave neprislo jako dobrej napad pouzit
while(!mySerial.available())V pripade, ze budou klavesnice dve a ustredna bude cekat na tu prvni a ta neodpovi, tak ustredna zustane v cyklu toho while.
-
Spoustu zabavy.
Přesně, pokud ho opravdu nechcete zatěžovat komplikacema, tak ať se vykašle na diferenciální vedení, rozchodí si to na stole přes čisté "TTL" (klidně s vlastním protokolem) a pak tam "jen" vloží RS485 driver, přidá nějakou XOR kontrolu, případně naimplementuje modbus. Stejně musí nejdříve přijít na to jak navrhnout aplikační logiku. Dekompozice problému na jednodušší celky ho naučí mnohem víc, než když to nějak slepí a nebude vědět proč.
(Nez se na to vykasle a udela to po rs485. Evidentne to je nejaky student, ktery ma spoustu casu na pokusy a objevovani, kudy ne. Tohle mu neublizi.)
Taky si myslím. Než se dostane k 10m vzdálenosti nodů v zarušeném prostředí nebo dvěma klávesnicím, tak přijde ještě na hodně dalších otázek.
A právě proto by měl použít osvědčenou základní technologii - RS485 - která je určená přesně na tyto věci a zvládne je levou zadní. Prostě vezme kroucený pár, 2 zakončovací odpory a zapojí. K tomu se přečte např. toto a zařídí se podle toho: http://www.ti.com/lit/an/snla049b/snla049b.pdf
Experimenty s TTL na 3+ zařízení a > 10m délky bych opustil.
-
A právě proto by měl použít osvědčenou základní technologii - RS485 - která je určená přesně na tyto věci a zvládne je levou zadní. Prostě vezme kroucený pár, 2 zakončovací odpory a zapojí. K tomu se přečte např. toto a zařídí se podle toho: http://www.ti.com/lit/an/snla049b/snla049b.pdf
Experimenty s TTL na 3+ zařízení a > 10m délky bych opustil.
Až na to, že v tuhle chvíli bych z tohohle soudku doporučil spíš plně duplexní 2x RS422, protože on s tím zápasí na úrovni pochopení jak tu sériovou linku vůbec používat. RS485 mu přidělá komplikace s tím, jak přepínat příjem/vysílání na obou stranách. Ty dva RS422 páry by ho nenutily opustit pohodlí Serial třídy v Arduinu za cenu dvou drátů (a to doufám, že tam má společnou zem). Proto je to TTL v tuhle chvíli úplně dostačující, on se na 10 metrů totiž hned tak nedostane.
-
Zase available(). Ono to opravdu udělá něco jiného než čekáš. Tady by asi mělo být spíš while(!mySerial.available());
V momente kdy je klavesnice adresovana a zacnou se vymenovat data s utrednou mi prave neprislo jako dobrej napad pouzit
while(!mySerial.available())V pripade, ze budou klavesnice dve a ustredna bude cekat na tu prvni a ta neodpovi, tak ustredna zustane v cyklu toho while.
V každém případě, ti to přeskočí ten read(), protože odpověď ještě nestihla přijít. Samozřejmě se tam pak hodí přidat timeout. Ale zkus zatím zapomenout na dvě klávesnice a vymysli jak spolehlivě komunikovat alespoň s jednou.
-
A taky dostal...
Prosímtě, neber to nijak zle, ale abych věděl kam tě dále směrovat, uvítal bych nějakou informaci o tvém backgroundu z programování a číslicové elektroniky. Co máš za vzdělání, kolik praxe a v čem, programoval jsi i něco mimo ty uváděné jednoduché aplikace v Arduinu?
-
A právě proto by měl použít osvědčenou základní technologii - RS485 - která je určená přesně na tyto věci a zvládne je levou zadní. Prostě vezme kroucený pár, 2 zakončovací odpory a zapojí. K tomu se přečte např. toto a zařídí se podle toho: http://www.ti.com/lit/an/snla049b/snla049b.pdf
Experimenty s TTL na 3+ zařízení a > 10m délky bych opustil.
Až na to, že v tuhle chvíli bych z tohohle soudku doporučil spíš plně duplexní 2x RS422, protože on s tím zápasí na úrovni pochopení jak tu sériovou linku vůbec používat. RS485 mu přidělá komplikace s tím, jak přepínat příjem/vysílání na obou stranách. Ty dva RS422 páry by ho nenutily opustit pohodlí Serial třídy v Arduinu za cenu dvou drátů (a to doufám, že tam má společnou zem). Proto je to TTL v tuhle chvíli úplně dostačující, on se na 10 metrů totiž hned tak nedostane.
Proč ne. RS422 klidně může použít taky. A samozřejmě že pro začátek, když bude psát komunikaci jen pro 2 zařízení na stole na pár desítek cm, může použít TTL bez budičů. Až mu to bude chodit, může to doplnit o RS-422 / 485 budiče.
Pro upřesnění: RS422 (full duplex) potřebuje 2x tolik budičů než RS485 (half-duplex - musí se přepínat směr vysílání/příjem).
-
A obecně alarm, dvě klávesnice a pár senzorů (a RFID/NFC?) je pořád dost vágní. I jako hračka by to asi nemělo být úplně snadno obejitelné obzvláště pokud to bude u vstupu do domu... Bacha třeba na replay attack (odposlechnutí a pozdější zopakování komunikace).
Jaky protokol vlastne pouzivaji officialni zabezpecovacky jako Jablotron, DSC, Paradox mezi ustrednou a klavesnici a jak je takovy prenos chraneny proti odposlechu?
Celkem casto dnes vidam v provozu DSC PC1550 a tam ocividne neni problem odposlechnout stisknuta tlacitka.