Kérdés:
Titokzatos RX impulzusok az UART connect-en az OS X Arduino Due-n
Blake Ramsdell
2016-03-15 22:17:45 UTC
view on stackexchange narkive permalink

Arduino IDE 1.6.8, Arduino Due, Mac OS 10.11.3

Nyolc titokzatos impulzust látok az RX vonalon, amikor több kliens könyvtár (Python, JavaScript mint valamint a beépített soros monitor az IDE-ben). Körülbelül 78-79 us darabonként, 1 ms / s sebességgel mintavételezve egy Logic Pro 16-tal.

Mystery pulses

Ez a nyolc impulzus 57600 baud sebességgel értelmezve dugja be a Firmata firmware-t. És minden kapcsolatnál előfordulnak.

Ez az Arduino 1.6.8 IDE új telepítését használja, és több vázlattal rendelkezik (a normál "Blink" vázlat ezt is reprodukálja).

Repro lépések a gépemen:

  1. Telepítsen bármilyen vázlatot
  2. Indítson el egy logikai elemzőt, ha el akarja érni
  3. Lépjen a Serial Monitor oldalra. Az enyémet 57600 baudra, Newline sorvégződésre konfiguráltam, de ez nem számít.
  4. Ha akarja, zárja be és ismételje meg a 3. lépést. port

Van valami javaslata ennek diagnosztizálására? Úgy hangzik, mintha valamilyen módon soros illesztőprogram-szintű lenne.

Függetlenül attól, hogy honnan származik, vegye fontolóra, hogy jót tett Önnek azzal, hogy egy kritikus hibát jelzett a futtatott firmware-ben - ez nem teheti helyrehozhatatlan állapotba. Ez egy program logikai hiba, vagy az UART kezelő kód nem foglalkozik megfelelően egy hibajelzővel?
A forrás felkutatása szempontjából hasznos lenne kipróbálni egy másik soros kliens programot, egy másik számítógépet / operációs rendszert, egy másik USB-soros eszközt stb.
Köszönöm a közreműködést, Chris. Amikor a Firmata firmware meglát egy 0xF0 [START_SYSEX] (https://github.com/firmata/protocol/blob/master/protocol.md#sysex-message-format), akkor bájtokat fog feldolgozni, amíg meg nem jelenik egy 0xF7, és ott nem rendelkezik időkorlátról. Tehát azt gondolom, hogy az történik, hogy ezek az impulzusok 0xF0-t generálnak (ezt a dekódolásomból láthatja), amely gyakorlatilag kikapcsolja a további parancsfeldolgozást, mivel nincs befejező 0xF7. Úgy gondolom, hogy a legjobb dolog, amit tehetek a Firmata érdekében, az, hogy beküldjek egy javítást, hogy időtúllépés következzen be olyan időintervallum után, amely elég hosszú a leghosszabb jogos adatcsomaghoz.
Ami a többi soros program kipróbálását illeti, több olyan könyvtár létezik, amelyek kölcsönhatásba lépnek a Firmata protokollal, és különböző mögöttes soros megvalósításokat (Python, JavaScript és a beépített Arduino IDE soros monitor) használnak, amelyek ugyanazt a viselkedést mutatják. A következő tervem az, hogy ezt kipróbálom egy Linux gépen, és megnézem, hogy látom-e ugyanazt a viselkedést, ami remélhetőleg elkülönít, ha ez OS X-specifikus.
Egyetlen impulzust kap Linuxon, amelyet 57600-nál 0xF0-ként értelmeznek
Akkor is kap egyet, amikor lekapcsol. A kapcsolat átviteli sebessége nincs hatással az impulzus hosszára. Az a gyanúm, hogy az ATMega16U2 firmware-je csinálja (vagy bármilyen chip van, bármilyen verzión).
Az Arduino veszi az áramot az USB-ről?
Amikor elindítja a soros monitort, a szoftver alaphelyzetbe állítja az arduino modult. Ha az arduino modulban van bootloader, akkor szerintem ezek az STK500 protokoll jelei.
Egy válasz:
next-hack
2017-09-01 12:04:02 UTC
view on stackexchange narkive permalink

Rövid :

Az ATMEGA16U2 firmware megtekintése ( https://github.com/arduino/ArduinoCore-sam/blob/master/firmwares/atmega16u2/arduino-usbserial/Arduino-usbserial .c) Megállapítottam, hogy amikor konfigurálja / megváltoztatja az USB emulált soros port beállításait, az USART visszaáll. Ez akkor is megtörténik, amikor megnyitja az Arduino soros monitort (konfigurálnia kell a soros sebességet stb.). Ez okozza a csúcsot.

Hosszú:

Nézze meg a függvényt:

void EVENT_CDC_Device_LineEncodingChanged (USB_ClassInfo_CDC_Device_t * const CDCInterfaceInfo)

Ott látni fogja, hogy néhány sor után visszaállítja az USART-ot a regiszterek nullázásával: 

  / * Az USART újrakonfigurálása előtt ki kell kapcsolnia az USART-ot, különben helytelen működés történhet * / UCSR1B = 0; UCSR1A = 0; UCSR1C = 0;

A jelenlegi ATMEGA16U2 adatlap 168. oldalán azt találja, hogy az UCSR1B 3. bitjének (TXEN1) beállításával engedélyezi az adót, felülírva a normál port működését (azaz kimenetivé válik). Az adatlap idézése:

Ennek a bitnek az egyikbe írása lehetővé teszi az USART adóját. Az adó felülbírálja a TxDn tű normál portjának működését, ha engedélyezve van. Az adó letiltása (a TXENn nullára írása) addig nem lép hatályba, amíg a folyamatban lévő és függőben lévő adások nem fejeződnek be, vagyis amikor az Adáseltolás-nyilvántartás és az Adáspuffer-nyilvántartás nem tartalmaznak továbbítandó adatokat. Ha le van tiltva, az adó már nem írja felül a TxDn portot.

Ezért az UCSR1B = 0; beírásával már nem írja felül a TXD1 tűt, amely működni fog bemenetként.

Az ATMEGA16U2 TXD csatlakozik az ATSAM3X8E RX vonalához. Normál üzemben, engedélyezve az UART-ot, ez a vonal magas marad, ha nem továbbítunk adatot. Ha letiltja az UART-ot, akkor az adott sor már nem az 1-es illesztőprogram. Mivel az inicializálási kód nem állítja be a felhúzást az adott csapra (és kimenetként sem van konfigurálva), a tű lebegő bemenetté válik, és az esetleges szivárgás A GND vagy akár a szonda bemeneti impedanciája (amely a tű és a GND között van) lassan 0-ra emeli a logikai szintet.

Ennek felülbírálásához a probléma az alábbiakat kell tennie: , a PIN-kód kimenetként történő beállításával, 1.2-es értékkel.) Módosítsa az ATMEGA16U2 firmware-t, engedélyezve az adott csap felhúzását.



ⓘ
Ezt a kérdést és választ automatikusan lefordították angol nyelvről.Az eredeti tartalom elérhető a stackexchange oldalon, amelyet köszönünk az cc by-sa 3.0 licencért, amely alatt terjesztik.
Loading...