Pico2040 V2.0.0

pour ceux qui s'interessent aux pico240

freertos vient d'etre intégré au portage réalisé par earlephilower sur la V2.0.0

2 Likes

Merci Philippe !

Je vois également une prise en charge de SoftwareSerial() qui peut rendre des services.

bonjour al1

sachant qu'il y a déjà 2 uart "hard" + CDC USB, ça repousse un peu le besoin de software sérial.

l'AD sur 12 bits est bien agréable même si restreint à 3 canaux .

il y a aussi cette possibilité qui devrait plaire @J-M-L

  • 8 × Programmable I/O (PIO) state machines for custom peripheral support

Pas vu comment concrètement cela se met en œuvre :shushing_face:

j'avais jeté un oeil sur ces machines d'état en assembleur spécifique PIO et ai laissé tombé faute de comprendre assez vite comment gérer les ressources . Même les exemples les plus simples me déconcertaient !

Un jour peut être il y aura un "PIO Pico2040 state machines pour les nuls".....

:wink: trop bien

Un aperçu ici : https://learn.adafruit.com/intro-to-rp2040-pio-with-circuitpython

Dans le portage effectué par Earl Phillower on peut voir un exemple de mise en oeuvre dans la librairie servo avec sa partie bas niveau en assembleur PIO : https://github.com/earlephilhower/arduino-pico/tree/master/libraries/Servo/src

+divers exemples ici chez Raspberry :
https://github.com/raspberrypi/pico-examples/tree/master/pio

1 Like

bonjour
reçu çà, de chez liligo TTGO, intéressant avec son petit oled 1.14"

ça a l'air sympa. la consommation en veille est comment ?

Bonjour @J-M-L
pour l'instant c'est juste sorti de sa pochette antistatique ! :sweat_smile:

je vais faire qq manips "un de ces jours"

ok :slight_smile:

@Artouste Il y a une erreur dans la description des I/Os sur le site de banggood
J'étais surpris qu'ils n'aient pas sorti les entrées analogiques et que les I/Os des boutons soient utilisées 2 fois, du coup je suis allé voir ailleurs.
Voilà ce que l'on trouve dans la boutique lilygo sur aliexpress.

Bonjour
Merci pour la recherche , je note précieusement çà :smiley:

Des choses utiles sur leur dépot github. En particulier dans les programmes de démo et sur le schéma de la carte on découvre que GPIO22 est nécessaire pour activer l'alimentation de l'écran.

ben moi j'ai vu, bonjour
j'ai en projet un truc qui nécessite bézef d'uarts en réception (non , Artouste , c'est pas un concentrateur midi)
alors j'ai fait le test suivant : le tx de l'uart0 (serial1 chez Earl) relié à 8 broches quelconques du pico
// on prend l'api d'Earl ; d'abord on instancie (je ne montre que la moitié)

SerialPIO pio1rx( SerialPIO ::NOPIN , 2 ); // pio rx sur pin 2
SerialPIO pio2rx( SerialPIO::NOPIN , 3 ); // pio rx sur pin
SerialPIO pio3rx( SerialPIO::NOPIN , 4 ); // pio rx sur pin
SerialPIO pio4rx( SerialPIO::NOPIN , 5 ); // pio rx sur pin

puis on setup : (vous avez vu la vitesse)

pio1rx.begin(250000); pio2rx.begin(250000); 
pio3rx.begin(250000); pio4rx.begin(250000);

et on met ça dans la loop :

  if (Serial.available()) {
    int inByte = Serial.read();
    Serial1.write(inByte); // uart0 = Serial1
  }
  // read from pio1rx, send to usb (port 0)
  if (pio1rx.available()) {
    int inByte = pio1rx.read();
    Serial.write(inByte); // usb (port 0)
  }
  else if (pio2rx.available()) {
    int inByte = pio2rx.read();
    Serial.write(inByte + 1); // usb (port 0)
  }
  else if (pio3rx.available()) {
    int inByte = pio3rx.read();
    Serial.write(inByte + 2); // usb (port 0)
  }
  else if (pio4rx.available()) {
    int inByte = pio4rx.read();
    Serial.write(inByte + 3); // usb (port 0)
  }

et ça marche si j'entre "a" au moniteur, j'obtiens abcdefgh
si j'entre 12, j'obtiens 1223344556677889
bien entendu, j'ai utilisé les 8 périphériques pio, plus dispo pour autre chose, mais quel mcu offre 10 uart en rx en + de lusb ?
.
et que c'est pas fini
par ailleurs, comme j'avais la bête sous la main, je lui ai fait passer un test de latence d'interruption (externe), quelque chose qui m'avait fait maudire l'esp32 et ses effroyables 4us
bon, ça a donné 2.6us, je m'en suis plaint à Earl , qui m'a dit d'aller voir du côté du sdk ; je suis tombé sur ce topic :
C SDK irq latency is only ̶1̶.̶0̶6̶u̶s̶ 200ns - Raspberry Pi Forums
j'ai recopié le code sans autre mise en forme, et ça marche, j'ai obtenu les 200ns, ce qui me parait normal pour un ARM
j'ai aussi vu que les functions du sdk peuvent être simplement utilisées pour des entrées sorties rapides, voire simultanées (avec un mask)
Edit : s'agissant d'un ARM, on peut aussi choisir la priorité des interruptions, cad. une interruption + prioritaire viendra interrompre l'isr en cours de l'interruption moins prioritaire ; il y a 4 niveaux , du + prioritaire au moins prioritaire
0 valeur 0x00 : priorité absolue ; je pense à réserver au système
1 valeur 0x40 : haute priorité , si vous avez des interruptions qui doivent être prioritaires
2 valeur 0x80 : priorité ordinaire , valeur par défaut pour le pi pico
3 valeur 0xC0 : priorité basse , si vous avez besoin de prioriser , mettre ce qui peut attendre ici
.
en conclusion, je dois revenir au temps : j'avais toisé , ici même , le pi pico, ne lui trouvant aucun avantage par rapport à l'esp32
une fois de + se vérifie la formule , que le meilleur mcu , c'est celui qui correspond le mieux aux besoins ...
je suis donc amené à migrer vers le pi pico (au besoin sa version W , qui a le même brochage)
(zut, je dois redessiner mes pcb (heureusement que j'aime ça))
ça serait sympa que la fondation nous sorte une version + velue , avec le même brochage , please

et si la fondation pouvait :
-donner accès au Bluetooth des puces radio présentes sur la carte PIco W
-amener la consommation en deep-sleep vers la dizaine de µA

1 Like

le problème, c'est le chip radio , qui utilise des broches dédiées pour le bluetooth, et yen a plus de dispo au niveau du pi pico
par ailleurs, ce chip doit souffrir de la pénurie actuelle, ce qui rend le pi pico W économiquement innatractif vis à vis du tout chinois esp32
(pour les rpi, c'est pire, les prix sont deliriants, entièrement hors des ambitions de la fondation)

aîe ! mes deux Pico W attendaient sagement la prise en charge du BLE, je comptais sur la puce Broadcom / Infineon (conçue à l'origine pour smartphone) pour obtenir une meilleure cohabitaion WiFI. BT/BLE que celle des ESP32

le meilleur mcu , c'est celui qui correspond le mieux aux besoins ...

On ne peut pas mieux dire !
C'est ce qui fait que mes Pico et PicoW n'ont pas encore trouvé chez moi d'emploi , une fois dépassée la découverte.....Ils attendent leur heure au fond d'un tiroir et je n'ai pas prévu de spéculer
Je commande encore des ESP32 des diverses variantes, le prix n'étant pas le critère unique

attention, ça, c'est ce que j'ai vu en regardant le schéma électrique : les lignes bluetooth sont spécifiques, mais on peut peut-être y accéder via les lignes wifi ... mais rien ne se passe , sauf le temps ... la réponse d'aallan donne un espoir ...
"
The wireless chip is connected via SPI to the RP2040. If we do get around to adding Bluetooth support for Pico W then communication will be via the same SPI connection. The CYW43439 BT pins aren't needed and aren't connected. In other words, adding Bluetooth support is a software thing, not a hardware thing
"
que les réactions des autres , et les faits , douchent un peu
"
Interesting, the CYW43439 datasheet doesn't suggest such a possibility, probably because it describes the default version of the firmware. (or I missed something)

on peut lire ça dans la Data Sheet du CYW43439 -chap 8=

External patches may be applied to the ROM-based firmware to provide flexibility for bug fixes or feature additions. These patches may be downloaded from the host to the CYW43439 through the UART transports.

8.1 RAM, ROM, and Patch Memory
The CYW43439 Bluetooth core has 160 KB of internal RAM which is mapped between general purpose scratch-pad memory and patch memory, and 576 KB of ROM used for the lower-layer protocol stack, test mode software, and boot ROM. The patch memory is used for bug fixes and feature additions to ROM memory code.

Espérons qu'il y ait par là un moyen pour rendre accessible le BLE avec le design actuel de la carte PicoW (chargement dans la puce radio d'un patch au firmware en ROM)

Bonjour @trimarco232

Il reste pas mal de travail pour la version 1.5 du sdk initialement programmée au 31 janvier 2023:wink:

quelques rares infos sur le BT