Pyth0n

Dziś pierwszy mój samodzielny wpis: jak wysterować trójkolorowy wyświetlacz ePaper z Raspberry Pico. Przykłady są przeprowadzane na czarno-biało-czerwonej matrycy GDEW075Z09 (zestaw WaveShare 13505, matryca z płytką kontrolera SPI w formie shielda na Raspberry Pi), ale tak samo programuje się czarno-biało-żółtą matrycę GDEW075C21 (zestaw WaveShare 14229). Teoria Wyświetlacze typu e-papier w najczęstszej formie nazywają się wyświetlaczami elekroforetycznymi i działają tak: Wyświetlacz zawiera miliony miniaturowych, przezroczystych kapsułek zawierających dwa lub trzy pigmenty z

Teraz tylko niech ktoś załatwi, żeby doba miała - nie jestem pazerny - tak z 36 godzin i mogę pisać artykuły... A - i nie ma na zdjęciu, e-papier 7" biało/czarno/czerwony. Już działa z Pico i MicroPythonem. Jak ogarnę kod, opublikuję.

Technicznie to FIFO z bloku SIO to kolejka uint32_t. Co tam wciśniesz, to Twoja sprawa. Możesz przekazać adres pierwszego znaku tablicy (uintptr_t)&(array[0]), powinno starczyć samo (uintptr_t)array (w tym kontekście w C z definicji array jest widziane jako wskaźnik). Po odebraniu będzie to char* array=(char*)multicore_fifo_pop_blocking(); NIE [Pamiętaj o jednym: na 99% (nie czytałem jeszcze pełnej dokumentacji C-SDK ani źródła SDK) wątki od różnych procesorów rezydują w innych blokach pamięci (SRAM0...SRAM5) podpiętych pod magistralę AHB, dzięki czemu możliwy jest dostęp w pełni równ

Dziś/jutro będę wiedział z "samobieżnym" STLink/V3, jak wlutuję piny SWD do Pico. Dodatkowo jest specjalny firmware do Pico o nazwie picoprobe (cały dodatek A do "Getting started with Raspberry Pi Pico" mówi jak to konfigurować i używać), który zamienia Pico w prostą sondę USB<->SWD. Można debugować jedno Pico za pomocą drugiego. Dobrze, że kupiłem cztery ---- EDIT: STLink/V3 jak na razie odmawia współpracy. Narzędzia st-link wykazują nieznany chip (słusznie, bo są do STM32/STM8 - ale widzi chip jako taki), openocd w ogóle spuszcza na drzewo, w trybie stlink-dap jest unable t

PyCharm ma co prawda oficjalnego JetBrainsowego plugina do MicroPythona, ale obecnie obsługuje on tylko PyBoard-a, Micro:Bit-a i ESP8266. Jest duża szansa, że szybko uaktualnią. Raz, - nie potrafi zaprogramować (w każdym razie nie udało się mi go zmusić w żadnym trybie), dwa - nie rozumie Pico-wych urządzeń (na przykład nie wie, że konstruktor SPI ma pod Pico dodatkowe parametry). EDIT: podobno chodzi jako tako w trybie pyboard, ale ma problemy z resetem. Jak na razie bawiłem się IDE thonny: na chama pip install thonny pod moim Linuksem i wszystko działa.

PIO to dwa koprocesory do odczytu/sterowania nóżek. Każdy ma pamięć na 32 instrukcje napisane w dedykowanym mikroasemblerze, każdy zawiera 4 współbieżne "rdzenie" (oficjalnie "maszyny stanów") współdzielące pamięć programu. W dokumentacji RP2040 jest na to poświęcony osobny rozdział. Po co PIO? Do odciążania głównych procesorów przy obsłudze IO. Przykładowe programy dla PIO z dokumentacji to implementacje SPI, UARTów, kodowania Manchester i różnicowego Manchester, I2C, PWM i korona wszystkiego: driver diod WS2812 (cholernie upierdliwy do implementacji programowej, bo ma bardzo ciasne tole

Dwa kanały są (między innymi) dokładnie z powodu który podajesz - konflikty adresów. Jeżeli czujniki mają 2 adresy do wyboru i są pasywne (tj nigdy same nie inicjalizują transmisji), to możesz obsłużyć wszystkie 16 z jednego Pico. Jak? Proste. Są co prawda tylko dwa kontrolery sprzętowe (I2C0 i I2C1), ale każdy możesz przypiąć w jednym z 6 miejsc (popatrz na rysunek z pinoutem Pico). Czyli de-facto masz jakby dwie grupy po 6 portów I2C, ale w danej chwili możesz korzystać z jednego portu w każdej grupie. A że masz możliwe 2 czujniki na port, to w sumie z jednego Pico możesz obsłużyć do 24

Wejścia ADC mają diody zabezpieczające przed ESD - diody są podpięte do IOVDD (zasilanie IO), nie do ADC_AVDD (zasilanie ADC) i jeżeli napięcie na nóżce ADC przekroczy IOVDD+0.3V, to wszystko podpięte pod IOVDD zacznie się zasilać z tej nóżki. W przypadku Pico, tranzystor zabezpiecza w sytuacji, gdy wyłączysz przetwornicę zasilającą (SMPS EN/3V3_EN = 0, ten sygnał jest wejściowy spoza Pico, np z urządzenia, do którego Pico jest wlutowane, to jest na padzie 37): wtedy IOVDD w procesorze ma 0V (nie jest zasilany) a na VSYS jest napięcie i wtedy jest spełniony warunek V(ADC)>IOVDD+0.3V i

Według dokumentacji "RP2040 Datasheet": Dwa rdzenie to nie lipa. Część peryferiów jest bezkonfliktowa (podpięta pod AHB, pamięci, flash, PIO, USB, DMA), część jest konfliktowa (podpięta pod APB, praktycznie wszystkie peryferia). Magistrala AHB ma 4 mastery (C0, C1, DMA-Read i DMA-Write) i jak długo dobierają się do różnych urządzeń, tak długa pracują całkowicie równolegle - między innymi dlatego RAM jest pocięty na małe kawałki (po 64kB), żeby każdy master mógł chodzić na swoim "banku" bez konfliktów. [str 14, rozdział 2.1. Bus Fabric]. Rdzenie spięte są fajnym interfejsem

@Fear - ten artykuł wymienia kilka płytek innych producentów wkrótce dostępnych na bazie RP2040. Na przykład Arduino Nano RP2040 Connect ma (mieć) Wifi i BT, 9-osiowy akcelerometr/żyro/kompas, mikrofon i pełne obsadzenie 16MB FLASH. @Treker - istnieje na przykład kilka szkolnych platform robotycznych pędzonych z M:B. A co do mocy: M:B'owy nRF jest jednak mocno słabszy od RP2040. Pół zegara (64MHz), jeden rdzeń, tylko 512kB FLASHa (i chyba nie cały dostępny, nie pamiętam), tylko 128kB RAM.

Mam nadzieję, że szybko pojawi się płytka kompatybilna z Micro:Bit-em. Połączenie bazy peryferiów M:B i parametrów RP2040 może być ciekawe dla "młodszej" edukacji.

Podoba mi się ich dystans do siebie. Cytat z oficjalnego ogłoszenia:

Bardzo fajny projekt. Zaczyna się od sumatora, potem się człowiek trochę zasiedzi w nocy i wychodzi MOnSter 6502 albo Megaprocessor...

Mój absolutny #1: Gigabitowy Ethernet wyciągnięty bezpośrednio z SoC-a, a nie przez mostek USB-Eth.

W powietrzu unosi się delikatny zapach Simulinka od Matlaba...