[serial] performances de l'uart

Version imprimable

Salut,

J'ai un problème assez inattendu. J'utilise un interface can sur USB qui crée une uart virtuelle. En clair, tout les messages circulant sur le bus can sont envoyés sur cette uart sous forme de chaines, il faut ensuite les décoder. On peut aussi envoyer des messages sur le bus can, mais il faut d'abord les réencoder sous forme de chaines.

Le driver en python marche plutôt bien, mais quand la communication est très chargée, je perds des octets en réception. L'uart est à 115200 bauds, le driver est une encapsulation de la classe serial avec un thread pour la réception, et dans ce thread j'ai un time.sleep(0.001) à chaque fois que le tampon de réception est vide. Sans le sleep, je ne perds aucun octet, mais la conso du thread est quasiment 20% de la cpu.

Et là, je m'aperçois dans le gestionnaire de périphériques que la taille max du buffer en réception est 4096 et que j'y suis par défaut. Quelqu'un à une idée pour augmenter ce buffer ou diminuer le temps minimum du sleep?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def canReceiver(self): """ this is a thread dedicated to messages reception""" while self.running: if self.gateway.inkey(): car = self.gateway.getchar() if car == '': # a timeout has occured self.incoming = '' else: self.incoming += car if car == miStick_uart.UART_NEWLINE: # line completed self.parseIncoming(self.incoming.strip()) self.incoming = '' time.sleep(0.001) self.can_reader._Thread__stop() self.stopping = False
A+

Pfeuh

14/11/2012, 17h59
wiztricks

Salut,

Techniquement pour ne pas "pooler" en attendant que le caractère suivant arrive et bouffer du CPU inutilement, on fait une attente passive via "select" sur le fd associé au keyboard (sous Unix).

Reste à voir comment a été codé "self.gateway" pour y ajouter un select avec timeout.

- W

Ps: il y a des méthodes plus efficaces que "select" mais comme il n'y a pas des milliers d'UART, çà suffira.
14/11/2012, 19h52
wiztricks

En supposant que self.gateway.getchar() attend indéfiniment l'arrivée d'un caractère, pourquoi ne pas encapsuler la lecture caractère/caractère dans
un sous-thread: les caractères lus pourraient aller dans une Queue partagée.
Queue dispose de méthodes pour attendre avec timeout.
C'est un peu "luxe" mais plus simple que d'aller dépiauter le driver/OS.
- W

En fait, je suis sous windows, je ne vois pas ce qu'est une attente passive via "select". Je ne fais un getchar que si un caractère a été reçu, grâce à la méthode inkey. Du coup, je me rends compte que le thread de réception n'est pas bon. Une fois qu'un octet a été détecté, il faudrait boucler sur du getchar jusqu'à la fin de la réception de la chaine. Tel que c'est là, je n'ai pas la moindre chance de détecter un timeout!

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
    def canReceiver(self):
        """ this is a thread dedicated to messages reception"""
        while self.running:
            if self.gateway.inkey():
                while 1:
                    car = self.gateway.getchar()
                    if car == '':
                        # a timeout has occured
                        self.incoming = ''
                        break
                    else:
                        self.incoming += car
                    if car == miStick_uart.UART_NEWLINE:
                        # line completed
                        self.parseIncoming(self.incoming.strip())
                        self.incoming = ''
                        break
            time.sleep(0.001)
        self.can_reader._Thread__stop()
        self.stopping = False

Bon, effectivement, modifié comme ci-dessus, ça marche mieux! :aie:

A+

Pfeuh