Tania płytka z procesorem ARM ale zgodna programowo z 32bitowym kodem ARM (nie tylko Cortex-M)

Szukam taniej płytki z procesorem ARM ale zgodnym z kodem ARM
Czyli nie Cortex-M coś tam. Musi wykonywać 32-bitowy kod ARM a nie tylko Thumb
Ktoś coś słyszał, wie, może podać nazwę.

Hmm, raspberry pi jedynka. Pi zero ma tem sam procesor.

Już nie wiem, czy to ja nie umiem szukać, czy jest jakaś inna przyczyna? Jeśli coś jest, to albo na starszych rdzeniach ARM7TDMI tak do 60 MHz albo odloty z zegarem GHz. Najlepiej pasowałoby mi jakiś ARM z częstotliwością 120 do max 200 MHz.
Ten 180 MHz ARM926EJ-S CPU core np. w NXP3xxx wygląda ciekawie, ostatecznie mogłbym zaprojektować sobie PCB, ale te obudowy TFBGA180 u nich to jakiś koszmar. Widzę, że u Microchipa podobnie. Ktoś jeszcze produkuje procesory w tym stylu ale w obudowach możliwych do polutowania w domu?

Jakie zagadnienie realizujesz, że tak stawiasz temat ?

Pytanie z ciekawości "do kawy".

gregor124 napisał:

Ktoś jeszcze produkuje procesory w tym stylu ale w obudowach możliwych do polutowania w domu?

Może warto się przyjrzeć seriom RZ/A1L i RZ/A1H z Renesas na rdzeniach Cortex-A9 z umiarkowanymi taktowaniami. Mniejsze typy są oprócz BGA oferowane też w obudowach QFP.
Ciekawostką jest to że na tych kostkach powstała chyba jedyna na świecie płytka Arduino na Cortex-A:
https://os.mbed.com/platforms/Renesas-GR-PEACH/
.

JacekCz napisał:

Jakie zagadnienie realizujesz, że tak stawiasz temat ?

To taki hobby project. Tworzę go już z przerwami od dłuższego czasu. Generalnie chodzi o sprzętowy symulator układów/modułów. Chodzi o to, aby reakcje systemu były jak najszybsze, ale i aby były z tym samym, a przede wszystkim znanymi opóźnieniem, co pozwala np. układowi dostosować się do różnych częstotliwości taktowania z zewnątrz. Program ma być z czasem rozbudowywany, aby mógł symulować różne układy. Właśnie dlatego wybrałem ARM32 i jego assembler. Mam już praktycznie ukończony program. Aby spełnić te warunki, cały program korzysta tylko z rejestrów procesora i ma ograniczoną liczbę skoków. ARM najbardziej mi pasował ze względu na to, że ma funkcję warunkowego wykorzystania każdej instrukcji, więc nie muszę robić skoków wewnątrz programów, a podprogram niezależnie od danych wejściowych zawsze wykona się w tej samej ilości taktów, czego już niestety w Cortexie-M nie ma i trzeba mocno kombinowac . Próbowałem przenieść to na Cortex-M, ale okazuje się, że jedną instrukcję muszę zastępować kilkoma i wychodzi z tego potworek.
@rb401
Ta płytką z Arduino jest nawet ciekawa, ale do mojego projektu nieco za duża i ma za mało I/O. No i chyba nie wspiera 5V dla I/O.
W każdym dzięki za info o Renesans, sprawdzę, co mają w ofercie.
Ten https://os.mbed.com/platforms/Renesas-GR-LYCHEE/
wygląda lepiej chociażby ze względu na liczbę I/O, ale to nie do końca to czego szukam.
Teraz zauwazylem ze wersja Full GR-PEACH ma wiecej I/O.

@gregor124

Dzięki za objaśnienie.
Jak patrzenie aseblerowe i już napisany kod asm , to tak ... patrzyłem C i wyższym poziomem
(rzeczywiscie te warunkowe skoki maja urodę)

Dodano po 3 [minuty]:

gregor124 napisał:

a podprogram niezależnie od danych wejściowych zawsze wykona się w tej samej ilości taktów,

Cache nie będzie kopało ?

JacekCz napisał:

rzeczywiscie te warunkowe skoki maja urodę

Miałeś chyba na myśli warunkowe instrukcje. Bo warunkowe skoki to są praktycznie wszędzie Co do CACHE to właśnie dlatego program nie korzysta z RAM. Przynajmniej w tych wolniejszych ARM cache działa chyba tylko z RAM.

gregor124 napisał:

To taki hobby project

Ciekawy pomysł. Dałoby się to zasymulować w FPGA? Możesz podać przykład układu który chcesz symulować?

gregor124 napisał:

Przynajmniej w tych wolniejszych ARM cache działa chyba tylko z RAM.

? Skąd takie informacje? - możesz podać źródło

gregor124 napisał:

Co do CACHE to właśnie dlatego program nie korzysta z RAM

To co to za program? Nie ma żadnych zmiennych? To po co się wykonuje?

@michal.zd
Dałoby się, ale byłoby to trudne ze względu na zasoby. Choć gdyby rozbić na wiele wsadów, to byłoby to możliwe, chociaż chyba mniej funkcjonalne. No i jeszcze jedno, moim zdaniem przy FPGA dostępnych dzisiaj symulacja/emulacja jest najczęściej tańsza i szybsza niż implementacja w FPGA i ten trend prawdopodobnie się jeszcze długo utrzyma.
No i jeszcze jedno taka symulacja programowa daje możliwość używania różnych rdzeni na różnych magistralach także
w tej chwili pracuję nad rdzeniem 65816 (jest już większość instrukcji gdzie np. w trybie emulacji procesora będzie można np. korzystać z wariantów 6502NMOS i 65816) i i8080.
Zrobienie tego w FPGA moim zdaniem byłoby karkołomne.
@oscil1
Już nie pamiętam skąd, ale nawet jeśli się mylę to z drugiej strony w ARM7TDMI które jest wciąż dostępne CACHE w ogóle nie jest zaimplementowane, z ARM7 jest chyba tylko w ARM7x0T (wspiera pamięć wirtualną) ale i tam pamięć cache jest domyślnie wyłączona.
https://en.wikipedia.org/wiki/List_of_ARM_processors
Oczywiście że są zmienne, wszystkie mieszczą się w rejestrach procesora.

W każdym razie jak byłoby zainteresowanie to mógłbym w innym temacie nieco napisać jak programować ARM czy np. taki stm32f103c8t6 czy podobny stm32F4.. . w asemblerze.

gregor124 napisał:

w tej chwili pracuję nad rdzeniem 65816 (jest już większość instrukcji gdzie np. w trybie emulacji procesora będzie można np. korzystać z wariantów 6502NMOS i 65816) i i8080.

Rozumiem, emulujesz procesory, poprzednio zrozumiałem że będą to układy peryferyjne a nie CPU.

@michal.zd
Najpierw może napiszę jak dla potrzeb projektu należy rozróżnić emulacje i symulacje.
Emulacja to wg. mnie układ, który całkowicie zastępuje emulowany element tj. można np. bezpośrednio wstawić go w jego miejsce i jeśli chodzi o użytkownika będzie dokładnie zachowywał się jak układ oryginalny. Czyli powinien być w 100 proc. elektrycznie, sygnałowo i logicznie zgodny z oryginałem.
Symulacja to z kolei układ zapewniający przede wszystkim zgodność na poziomie oprogramowania z mniejszym naciskiem na zgodność sprzętową.

Raczej chodzi mi o symulacje, chociaż emulacja ma być także możliwa.
Co do emulacji czy symulacji układów peryferyjnych jak najbardziej będzie to możliwe. Np. w takich cyklach układ synchronizuje się z magistralą, odbiera dane wejściowe, teraz przekazuje je do programu symulującego użytkownika (który ma np. okno czasowe na wykonanie funkcji układu, i po wykonaniu niezbędnej procedury zwraca sterowanie do programu obsługującego daną magistralę. W ten sposób program użytkownika ma się jedynie skupić na obsłudze logiki danego układu, a sprawy interfejsu pozostawić układowi.
Nie wiem czy wyjaśniłem to wystarczająco jasno.

gregor124 napisał:

W każdym razie jak byłoby zainteresowanie to mógłbym w innym temacie nieco napisać jak programować ARM czy np. taki stm32f103c8t6 czy podobny stm32F4.. . w asemblerze.

Myślę, że ci co potrafią nie dotykają, a Ci co nie potrafią i tak nie potrzebują. Pisanie programow w ASM dla tych platform to sztuka dla sztuki, bez jakiegokolwiek zastosowania praktycznego.

Jak masz czas i ochotę to napisz coś z czego mogą ludzie skorzystać - to tutorial jak używać inline assembly z gcc. Bo to jest współcześnie jedyne miejsce gdzie ludzie używają (sporadycznie) asemblera. Taki porządny tutorial myślę, że byłby przydatny dla wielu.

gregor124 napisał:

Nie wiem czy wyjaśniłem to wystarczająco jasno.

Tak.
W zasadzie rozumiem termin emulacja, dokładnie tak jak opisałeś. Symulacja trochę inaczej traktuję, jako wirtualny hardware w wirtualnym świecie. Coś jak lt-spice albo virtualBox .symulacja nie wymaga utrzymania zależności czasowych, dlatego pisałem o emulacji.

oscil1 napisał:

tutorial jak używać inline assembly z gcc.

Lepiej całkowicie napisać potrzebne funkcje w całości w asm, skompilować asm, dopiero złączyć w całość linkerem. Tak robiłem i tak polecam. Używanie kodu asm w funkcji napisanej w c jest męką.
Ale również nie widzę potrzeby korzystania z asm.

michal.zd napisał:

Używanie kodu asm w funkcji napisanej w c jest męką.

Dlaczego? Wymaga odrobinę więcej wiedzy jak to działa. Ma właśnie sens bo masz dostęp do zmiennych lokalnych parametrów itp - co zapewnia Ci kompilaror C "rrozkodowując" tą specyficzną składnie. Dodatkowo nie musisz pisać całej funkcji, tylko wstawiasz to co z musu musi być w ASM (a jest tego coraz mniej). To co ja widzę - ludzie unikają inline assembly bo go nie rozumieją, a jest to potężne narzędzie.

@oscil,
Jako że asembler to mój pierwszy 'język' od którego zaczęła się moja przygoda, to taki sposób dla łatwiej zrozumieć.
Kod asm wklejany w kodzie programu c nie jest uniwersalny, kompilatory c mają ińne skladnie

Nie jest tak źle. Z racji, że większość kodu jest w makrach, wygląda na to, że uda się go przerobić na Cortex-M4.
Ostatecznie jest dostępny LPC2148, jest nawet płytka (była używana do flashowania Xboxa 360), choć cena za nią jest wyższa niż myślałem, ale w razie czego zaprojektuję swoją albo użyję standardowej przejściówki z LQFP64 do DIL.
Najbardziej brakuje mi konstrukcji z ARM32 typu:

Ale coś wykombinuję
Cortex-M4 ma podobną instrukcję, ale ograniczoną tylko do zastosowania przesunięcia w lewo LSL#n i do tego tylko o maksymalnie 3 bity, więc wygląda, że będę potrzebował dodatkowego rejestru.
Wyglada ze to daje ten sam efekt: