ECOM-comm méthode read de InputStream non conforme sur ESP32

MicroEJ SDK
,
1

Bonjour,

J’utilise le module ECOM-comm pour piloter un port série sur une carte ESP32. Le souci est le suivant : après avoir ouvert une CommConnection et récupéré son InputStream, j’appelle la méthode read(byte[]) sur ce flux. Si des données sont déjà disponibles, elles sont récupérées sans problème. En revanche, s’il n’y en a pas, le read bloque indéfiniment, même si des données sont reçues par la suite. D’après la documentation de la méthode, elle devrait se débloquer : “This method blocks until input data is available”.

Je ne rencontre pas ce bug sur le simulateur ou sur d’autres plateformes. J’ai essayé de cast le flux de lecture en BitsInput et d’utiliser la méthode readBits(byte[], boolean). Les résultats sont identiques. Ma version de ECOM-comm est la 1.1.4. Pour ce qui est de l’architecture utilisée, la voici :
architecture

Dans mon BSP, j’ai développé une implémentation personnalisée (LLCOMM_CUSTOM_CONNECTION_IMPL) pour communiquer en UART. J’ai pris pour base celle fournie avec l’ESP32 WROVER (Index of /packages/referenceimplementations/HDAHT/1.5.1). Je vois qu’il y a deux fonctions utilisées pour la lecture : LLCOMM_CUSTOM_CONNECTION_IMPL_isRXDataAvailable et LLCOMM_CUSTOM_CONNECTION_IMPL_getNextRXData. En mettant des traces, je vois que avant chaque getNextRXData, un appel à isRXDataAvailable est effectué. Si isRXDataAvailable retourne 0, aucun appel à getNextRXData n’est effectué.

Dans le cadre de mon bug, je vois que isRXDataAvailable retourne 0 à un read, car il n’y a pas de données à ce moment-là, puis j’en reçois, mais isRXDataAvailable n’étant pas rappelée, on reste bloqué. Pour corriger le problème, j’ai utilisé un sémaphore qui bloque la fonction isRXDataAvailable tant qu’il n’y a pas de données à lire. En soit, cela corrige le problème, mais la JVM entière se retrouve bloquée, car il n’y a visiblement pas de retry pattern sur les méthodes SNI de lecture.

Pour résumer : je souhaite que la méthode read soit conforme à sa documentation et se débloque quand on reçoit une trame depuis la liaison série.

Cordialement,
Yoann Jézégou, développeur chez Otodo

2

Bonjour,

Après avoir reçu de l’aide, j’ai trouvé ce qui manquait. Dans mon code en C, j’ai ajouté un appel à LLCOMM_CUSTOM_CONNECTION_dataReceived(LLCOMM_CUSTOM_CONNECTION*) quand je reçois un message en UART. Cela débloque la méthode read du Java et mon message y est bien remonté. Le sujet peut donc être clos.

Cordialement,
Yoann Jézégou, développeur chez Otodo