RPi Pico Wymiana danych między rdzeniami Raspberry Pi Pico (kolejka FIFO)

[FeeJay]

Poniższe pytanie zostało wydzielone z tematu: https://forbot.pl/forum/topic/19365-premiera-raspberry-pi-pico-za-4-z-nowym-ukladem-rp2040/
______

@Pyth0n Dzięki za odpowiedź, ciekawa sprawa swoją drogą, teoretycznie to jest jeden standard ARM SWD.

Kombinuje cały czas z płytką i spotkałem się dzisiaj z ciekawym jak dla mnie problemem. W kolejce fifo między rdzeniami można przekazywać tylko int'y, w examplu multicore_runner przekazano funkcje za pomocą

multicore_fifo_push_blocking((uintptr_t) &factorial);

i

int32_t (*func)() = (int32_t(*)()) multicore_fifo_pop_blocking();

Walczę z tym jak przekazać w jakiś sposób arraya charów (char[]) w podobny sposób, lecz póki co bez skutku, co podejrzewam wynika z mojej niewielkiej wiedzy o C. Macie może jakieś pomysły na przekazywanie w taki sposób takiego arraya? Lub może jakieś inne sposoby na to?

[Pyth0n]

11 godzin temu, FeeJay napisał:

@Pyth0n Dzięki za odpowiedź, ciekawa sprawa swoją drogą, teoretycznie to jest jeden standard ARM SWD.

Kombinuje cały czas z płytką i spotkałem się dzisiaj z ciekawym jak dla mnie problemem. W kolejce fifo między rdzeniami można przekazywać tylko int'y, w examplu multicore_runner przekazano funkcje za pomocą

multicore_fifo_push_blocking((uintptr_t) &factorial);

i

int32_t (*func)() = (int32_t(*)()) multicore_fifo_pop_blocking();

Walczę z tym jak przekazać w jakiś sposób arraya charów (char[]) w podobny sposób, lecz póki co bez skutku, co podejrzewam wynika z mojej niewielkiej wiedzy o C. Macie może jakieś pomysły na przekazywanie w taki sposób takiego arraya? Lub może jakieś inne sposoby na to?

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ównoległy.  Jak prześlesz adres tablicy do drugiego procesora, to dostępy do niej zaczną powodować konflikty i arbiter magistrali będzie miał dodatkową robotę.] Nie, według dokumentacji nie ma takiego rozdzielenia. Muszę przegrzebać źródło SDK, żeby zobaczyć, czy jest jakikolwiek sposób wymuszenia umieszczenia zmiennej w konkretnym bloku pamięci.

Dodatkowo uważaj, żeby nie wysłać zmiennej lokalnej jakiejś funkcji, bo to będzie zniszczone przy jej zakończeniu i druga strona po pewnym czasie będzie miała wskaźnik na śmietnik.

EDIT: Dobra, wiem więcej o pamięci...

• System ma w sumie 264kB SRAM podzielonego na 4 bloki po 64kB (SRAM0..3) i 2 bloki po 4kB (SRAM4..5)
• Każdy rdzeń i DMA ma niezależny kanał do każdego bloku pamięci. Jak długo sięgają do różnych, tak długo działają w pełni równolegle.
• Jest śmieszna jazda z mapowaniem bloków do przestrzeni adresowej 🙂 Szczegóły w dokumentacji RP2040 rozdział 2.2
• Od adresu 0x20000000 dostępne jest 256kB RAM zorganizowanego jak RAID0 po blokach SRAM0..3. Czyli kolejne słowa 32-bitowe skaczą po kolejnych blokach (mapowanie adresów w tej przestrzeni na adresy fizyczne w blokach ładnie pokazano w tabelce na str. 143). Dostępy mają mniejsze prawdopodobieństwo konfliktów na magistrali. W tym obszarze runtime Pico-SDK umieszcza swoje dane, czyli przy pracy dwuprocesorowej jest mniej konfliktów.
• Od adresów  0x21000000, 0x21010000, 0x21020000, 0x21030000 każdy blok SRAM0..3 jest widoczny indywidualnie (pamiętając, że każdy aliasuje się na co czwarte słowo obszaru od 0x20000000)
• Bloki SRAM4..5 są od adresów 0x20040000 i 0x20041000 i są dostępne tylko indywidualnie. W skrypcie linkera z SDK są do nich przypisane sekcje odpowiednio .scratch_x i .scratch_y. Są zdefiniowane makra __scratch_x(group) i __scratch_y(group), do przypinania zmiennych do tych sekcji. Group to podgrupy sekcji, ale widzę, ze i tak linker miesza, więc można zostawić puste.

Poniższy przykład to modyfikacja pico-examples/hello_world/usb:

 

#include <stdio.h>
#include "pico/stdlib.h"
  
int X __scratch_x();
int Y __scratch_y();
int Z;

int main() {
	stdio_init_all();
	while (true) {
		printf("X=%p Y=%p Z=%p\n",&X,&Y,&Z);
		sleep_ms(1000);
	}
	return 0;
}

Po uruchomieniu:

X=20040000 Y=20041000 Z=20001650

Czyli zmienna X jest na początku obszaru SRAM4, zmienna Y na początku SRAM5 a Z gdzieś w SRAM z przeplotem. A konkretnie, dla adresu 20001650:

1. 0x20001650 to 0x1650 bajtów w głąb SRAM "przeplatanego", czyli
2. 0x1650/4 = 0x594-te słowo pamięci
3. 0x594 mod 4 = 0, czyli w banku SRAM0
4. 0x594/4 = 0x165, czyli w słowie 0x165 tego banku.
5. Czyli adres 0x20001654 będzie w słowie 0x165 ale banku SRAM1 a 0x2000164C będzie w słowie 0x164 banku SRAM3

To samo Z będzie widoczne też bezpośrednio w banku SRAM0, pod adresem  0x21000000 + 0x165*4

Edytowano Luty 2, 2021 przez Pyth0n

[FeeJay]

@Pyth0n Dzięki za odpowiedź, w sumie podobnie kombinowałem, trochę potem pomieszałem z ampersandami, wszystko już pięknie działa i prosty kalkulator pracuje sobie na dwóch rdzeniach 😄

Co do pamięci, ciekawa sprawa, sprawdziłem już wcześniej, że oba rdzenie mają dostęp do całej pamięci, więc nie przejmowałem się zbytnio tym, ale nie myślałem o tym czy zmienne są w innych blokach, żeby mogły całkowicie równolegle pracować.

Z tego co rozumiem w tym co napisałeś, skoro bloki są zorganizowane jako Stripped, prawdopodobieństwo pracy dwóch rdzeni na tych samych blokach w tym samym czasie zmniejsza się, więc konflikt na magistrali jest mniej prawdopodobny, ale wciąż możliwy.

Przy krytycznych danych chyba warto wymusić wtedy ich umieszczenie w oddzielnych SRAM4 i SRAM5.

 

Im bardziej zagłębiam się w tę płytkę, tym bardziej mi się ona podoba. Wcześniej moja przygoda opierała się głównie na Arduino, trochę na Raspberry PI. Próbowałem już PIC, STM8 i STM32, ale brak takiego wsparcia z przykładami i dużej społeczności sprawił, że była to dla mnie ciężka droga i z czasem sobie odpuściłem.

Z PICO siedzę kolejny dzień i nadal nie mam dość 😄 Wszystko jest przejrzyste i nauka jest przyjemna i daje dużo satysfakcji.

Póki co testuję różne możliwości, ale projektem będzie zrobienie gry, gdzie do PICO będzie podłączony wyświetlacz IPS 240x240. Być może uda się jego obsługę wyrzucić do PIO, a jeśli nie to drugi rdzeń by się zajmował obsługą i wyświetlaniem.