UART switch ?

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%)]

gaat dat dan met de zelfde USB verbinding als waar ik de raspberry pico mee programmeer ?

ik mag hoop ik wel 1x kicken :)

Op woensdag 15 mei 2024 16:12:18 schreef trix:
ik mag hoop ik wel 1x kicken :)

Nee! :-) (officieel pas na 24 uur... Nu een uurtje te vroeg... zien we door de vingers :-) )

Op dinsdag 14 mei 2024 17:42:09 schreef trix:
gaat dat dan met de zelfde USB verbinding als waar ik de raspberry pico mee programmeer ?

Jep!

Als jij klaar bent met programmeren, dan verdwijnt die "usb stick' wat dat ding pretendeert te zijn, toch?

Bij mij komt er dan altijd een "virtuele com poort" voor terug.

Ipv met dat boot knopje te freubelen en dan een power cycle (of reset: Draadje er aan doen, GND aantikken)... zorg ik voor een "rbl" commando die reset to bootloader doet. is gewoon een functie voor in de API. (Dat was VEEL moeilijker om te maken bij STM).

bedankt, ga ik bekijken.

is dit nou nog ateeds voor die mysterieuze XY tafel dinges waar je al 3x van controller bent veranderd? ;)
Gaan we het resultaat ooit nog zien?

klopt.....je mag wel komen kijken als je dat wil (geld eigenlijk wel voor iedereen van hier) die mij regelmatig helpt.
ik werk er vaak een hele tijd niet aan, druk met andere dingen. nu dus een poosje terug de "raspberry pi pico" "ontdekt". bevalt me wel, simpele IDE zonder veel toeters en bellen, micro python is ook een simpele taal, die ruim voldoet voor de dingen die ik er mee wil doen. wat ik aan het maken ben is programmeer technisch echt niet moeilijk (maar voor mij soms wel :)).

ik ben ondertussen aan het bekijken of ik de USB waarmee ik de pico programmeer ook kan gebruiken om data van de pico naar de laptop te sturen.
nu kom ik regelmatig tegen dat je dan de pico moet resetten (spanning er af en weer terug erop(kan dacht ik ook met een hardware drukknop)), omdat de USB verbinding thonny --> pico moet worden onderbroken (er kunnen ten slotte maar 2 devices op 1 USB verbinding).
de data die ik van de pico naar de laptop wil sturen, wil ik uiteindelijk in excel bekijken, en heel mischien daar berekeningen doen, en weer heel mischien de uitkomst van die berekeningen terug sturen naar de pico, dus in dat geval wel bi-directioneel (dit in tegenstelling tot wat ik eerst zei).