Tento príspevok je súčasťou série o probléme s autoflow ModbusRTU na TouchBerry a o tom, ako som ho vyriešil. Ostatné príspevky série nájdete pod tagom touchberry. Všimnite si, že novšie príspevky môžu obsahovať aktuálnejšie informácie.
V tejto vlne horúčav je dosť ťažké robiť veľa efektívnej práce, no prinútil som sa urobiť aspoň minimum, okrem pitia vody a schávania pred slnkom. Teda pokračujem v práci na plnom využití RS485 schopností TouchBerry 10 a naučil som sa niekoľko nových vecí.
Na efektívne odosielanie dát po zbernici RS485 stačí nastaviť pin DE čipu UTRS485G na HIGH. Pin RE by mal byť nastavený na HIGH zároveň, ale pre samotný prenos to nie je striktne nutné. V praxi moje Modbus IO zariadenie skutočne zmenilo stav cievky na žiadosť riadiaceho prvku, ale nemohlo riadiacemu prvku (v tomto prípade TouchBerry) potvrdiť, že tak urobilo. Inak povedané, s pinom RE nastaveným na HIGH a pinom DE v akomkoľvek stave riadiaci prvok vidí, že príkaz Modbus vypršal, ale príkaz bol v skutočnosti prijatý a vykonaný počúvajúcim zariadením.
To nás pravdepodobne priblíži k dôvodu, prečo nefungovalo nič, čo som skúšal v súvislosti s RTS0 a autoflow. Relevantné časti z pôvodného príspevku:
| Pin RPi | GPIO | ALT3 | Pin UTRS485G |
|---|---|---|---|
| 11 | 17 | RTS0 | RE |
| 13 | 27 | SD1_DAT3 | DE |
Ako vidíme, tento návrh UPS shieldu je skutočne nešťastný, pretože by
pravdepodobne bolo lepšie, keby tieto dve cesty boli vymenené. Keby bol pin
DE pripojený k alternatívnej funkcii RTS0, mohlo by to pravdepodobne
automatické riadenie smeru RS485 (skrátene autoflow) fungovať len s
alternatívnou funkciou GPIO a možno príkazom stty, možno niečo také
jednoduché by postačilo:
sudo pigs m 17 3
sudo stty -F /dev/ttyS0 crtsctsRealita nám však zanecháva GPIO17 pripojeného k pinu RE bez možnosti automaticky riadiť pin DE pripojený k GPIO27. Som veľmi v pokušení prepojiť oba piny dohromady, aby som otestoval hypotézu autoflow RTS0. S takýmto hackom by som mohol žiť. Najmä keďže sa blíži čas finálneho produktu, kde bude panel TouchBerry namontovaný, bude musieť byť niečo urobené. Opraviteľnosť takého produktu s hackmi samozrejme prudko klesá, ale na druhej strane, prototypy sú väčšinou postavené s hackmi aj tak.
Alternatívny čip s povoleným autoflow RS485 #
Ďalšou možnosťou, ktorú som zvažoval, je nahradiť základný čip UTRS485G naspájkovaný na UPS shieldu vo vnútri TouchBerry 10 niečím pokročilejším. Náhodou som narazil na IO karty z embeddedpi.com. Prvá featured, polovičný duplexný RS485 nazývaný ISO-485, vysvetľuje, že sa môže pochváliť MAX13487. Popis tohto čipu uvádza:
Half-Duplex RS-485/RS-422-Compatible Transceiver with AutoDirection Control
Pri pohľade na jeho piny je takmer celý pin-to-pin kompatibilný s UTRS485G. Jedinou výnimkou je pin 3, kde SHDN nahrádza DE v MAX13487E. Oba čipy však možno použiť rovnakým spôsobom. Nastavenie pinov RE a SHDN na HIGH umožňuje MAX13487E plynulo prenášať a prijímať dáta cez zbernicu bez potreby akejkoľvek inej manuálnej akcie, za predpokladu, že softvér zabezpečí, aby dvaja účastníci nikdy nehovorili súčasne. To je samozrejme vyriešené vzťahom klient-server v protokole Modbus. S UTRS485G nastavenie oboch pinov RE aj DE na HIGH umožňuje len prenos dát po zbernici, pričom funkcia príjmu je zakázaná, kým oba piny RE a DE nie sú opäť nastavené na LOW.
Môj miestny distribútor má nejaké MAX13487E na sklade, ale napríklad samotný Maxim žiadne nemá, s dodacou lehotou 20 týždňov! Mohol by byť príčinou nedostatok čipov, o ktorom som tiež písal?
Toto je 93. príspevok #100daystooffload.