UART switch ?

ik kom voor een project een UART te kort, op mijn raspberry pico (2 stuks aan boord).
omdat mijn 3 UART toepassingen nooit tegelijk gebruikt worden, vroeg ik mij af of ik niet 2 toepassingen op 1 UART kan zetten ?
dan heb ik denk ik een UART switch nodig, bestaat zoiets ?

Als je de PICO programmeert in Arduino kun je nog een aantal serial ports maken met de PIO pins:
https://arduino-pico.readthedocs.io/en/latest/piouart.html

Kan je geen softserial oid gebruiken dus een software gestuurde uart die elke 2 normale io pinnen kan gebruiken.

ja dat denk ik wel, maar dat lijkt me wel lastig.

pico word trouwens geprogrameerd met thonny (python)

[Bericht gewijzigd door trix op (52%)]

Ik denk dat iets als een 4053 het minste denkwerk vereist. Vergeet de pullups niet.

Heb je TTL niveau UART nodig, of RS232? In dat laatste geval zou je line drivers kunnen gebruiken met transmitter enable en receiver enable ingangen, en er dan altijd naar één aan zetten.

Je kunt gewoon de pinnen remappen, UART 0 kan op 1+2, 16+17 en 21+22 draaien. Dan kun je dus 3 apparaten aan UART 0 koppelen, en er steeds 1 gebruiken. Zoek even hoe dat in Python moet, ik vind enkel Arduinocode hiervoor.

[Bericht gewijzigd door blanka op (20%)]

ja dat denk ik wel, maar dat lijkt me wel lastig.

Ik zou niet weten waarop dat lastig zou moeten zijn. Je moet er eventueel wel een extra library voor downloaden, maar die library doet al het werk voor je.

Ik zie dat Rolo ook zoiets als voorbeeld meestuurt

https://arduino-pico.readthedocs.io/en/latest/piouart.html

Software serial is een smerige oplossing die niet zou moeten bestaan. Het vreet CPU cycles, zelfs op een lage baudrate, en als de CPU nog andere interrupts af te handelen heeft, moet je niet verbaast zijn als het af en toe mis gaat met de timing, vooral bij het ontvangen.

Als je een Pic gebruikt, kun je bijna net zoveel UART's ports maken als er pinnen zijn... :+
(meeste hebben 3 of 4 uarts en die kun je met PPS remappen naar de gewenste pin.)

dat "remappen" zou inderdaad een optie kunnen zijn, eens uitzoeken hoe dat gaat.

Op maandag 13 mei 2024 00:31:39 schreef SparkyGSX:
Software serial is een smerige oplossing die niet zou moeten bestaan. Het vreet CPU cycles, zelfs op een lage baudrate, en als de CPU nog andere interrupts af te handelen heeft, moet je niet verbaast zijn als het af en toe mis gaat met de timing, vooral bij het ontvangen.

Dat was vroegah misschien wel zo maar de huidige processortjes, zeker die op een Pico of ESP32 zijn zo snel dat een interruptje meer of minder niet uitmaakt. Je kunt vaak ook de routine vastpinnen op een bepaalde core zodat de andere core er geen last van heeft.

Ik heb op de RP2040 toch echt last van een interrupt die kennelijk m'n main onderbreekt voor een paar microseconden zodat mijn timing niet meer klopt.

Andere CPU stuurt een puls van 100 microseconden, ik kijk gedurende 200 microseconden of er ook maar IETS gebeurt en... soms mis ik de puls! Dan ben ik dus onderbroken tussen "en nu kan de andere cpu een signaal gaan geven" en de start van mijn 200 microseconden, zodat ik die hele 100 microseconden mis.

Die puls langer maken zou werken, maar dat kost tijd (want het moet vaker gebeuren). Interrupts uit is lastig omdat de "aanloop" ook best lang is, en eigenlijk hoeft het pas zeg maar net voor het laatste byte. Maar dat is natuurlijk een beetje lastig te realiseren in de software want ik heb een "stuur heel pakket" functie.

Als je interrupts gebruikt kun je in Main sowieso geen nauwkeurige timing doen, daarom heet 't ook 'interrupt' (onderbreking)... ;)

In dit geval is remappen van de UART naar een andere pin-set de meest handige oplossing. (zie tip van 'blanka')
Maar dat moet je natuurlijk wel op het juiste moment doen (fifo's leeg etc).

En op de pinnen van de CPU de juiste pull-ups/-downs zetten zodat je pinnen inactief zijn als je de UART eraf mapt. Of je doet dit:
Je kunt ook de output als GPIO output programmeren op 1 of 0 afhankelijk welk niveau je nodig hebt (hoeft maar een keer bij de init).
Dan de oude TX pin in GPIO output mode zetten, dan heb je geen glitch op je output signaal. En dan de UART mappen naar de andere pinset.

een van de UART's die ik nodig heb, is om data naar de laptop te sturen (niet terug), is dat ook mogelijk met SPI ?
mischien kan ik er daar 1 van vrij maken.

[Bericht gewijzigd door trix op (16%)]

SPI is een bus met clock en niet compatible met UART...

maar is er dan niet iets van een SPI --> USB convertor ?

https://www.microchip.com/en-us/product/mcp2210

domme vraag wellicht, maar is dit dan ook SPI --> USB ? (de andere kant op)

edit:
ik ga toch dat "remappen" bekijken zoals blanka aanhaalde, lijk me de netste oplossing.

[Bericht gewijzigd door trix op (40%)]

Ik gebruik dat bij pic's ook vaak, werkt heel handig als je meer uart/spi of i2c nodig hebt als dat er beschikbaar is...

dan bedoel je denk ik de MCP2210 ?

Nee, remappen...

https://nl.aliexpress.com/item/32807821217.html?src=google

Op maandag 13 mei 2024 14:21:42 schreef henri62:
Dan de oude TX pin in GPIO output mode zetten, dan heb je geen glitch op je output signaal. En dan de UART mappen naar de andere pinset.

De makkelijkste manier om de pin weer GPIO, niet UART te maken is om

 gpio_init (pinnr)

aan te roepen. Dat werkt dan niet, want dat maakt hem weer input en laag.

Je moet het dus met gpio_set_function gebruiken.

Veel GPIOs beginnen met een pulldown. Die blijft normaliter aanstaan, maar als je die voor de niet-actieve pin op pullup zet, dan blijft eea goedgaan ook als je het niet helemaal perfect doet.

Op maandag 13 mei 2024 17:54:46 schreef trix:
een van de UART's die ik nodig heb, is om data naar de laptop te sturen (niet terug), is dat ook mogelijk met SPI ?
mischien kan ik er daar 1 van vrij maken.

DAN is de makkelijkste oplossing om USB te gebruiken.

Gewoon bij het opzetten van het project aangeven dat je USB console wil hebben en alles wat je met printf print wordt via USB naar de host computer gestuurd.

[Bericht gewijzigd door rew op (27%)]