Jakiś czas temu pytałem jakich prędkości mogę się spodziewać z pic32
+ mass storage, w końcu odpaliłem Microchipowe MSD i, że tak powiem,
szału nie ma. Odczyt sektora (bez warstwy FS na razie) przy zegarze
40MHz odbywa się z prędkością ok 170kB/s.
Jak to wychodzi u konkurencji, np. stm32 ? Oczywiście chodzi mi o w
miarę porównywalne układy z pic32 a nie jakieś super "wypasione"
army.
1MB/s uznałbym za wynik zadowalający...

--
Marek

do góry

> Jakiś czas temu pytałem jakich prędkości mogę się spodziewać z pic32
> + mass storage, w końcu odpaliłem Microchipowe MSD i, że tak powiem,
> szału nie ma. Odczyt sektora (bez warstwy FS na razie) przy zegarze
> 40MHz odbywa się z prędkością ok 170kB/s.
> Jak to wychodzi u konkurencji, np. stm32 ? Oczywiście chodzi mi o w
> miarę porównywalne układy z pic32 a nie jakieś super "wypasione"
> army.
> 1MB/s uznałbym za wynik zadowalający...
>
> --
> Marek
Popatrz , co tam Ci kompilator wymyślił.
Często jest to bezsensowna praca w pętli.
Wystarczy ją namierzyć debuggerem i poprawić.
Napisz w ASM (fragment lub całość)
lub wybierz coś szybszego.
Jednak może się okazać, że na dsPIC33 zadziała znacznie lepiej.
Mam wrażenie, że kompilator nie radzi sobie w ogóle z kolejkowaniem
instrukcji i danych
w rdzeniu MIPS. Przez to powstają znaczące opóźnienia.
Te 40MHz w 32MX to nie jest tak jak w dsPIC.
S.

do góry

On Mon, 4 Nov 2013 17:35:41 +0100, Sylwester Łazar<i...@a...pl>
wrote:
> Napisz w ASM (fragment lub całość)
> lub wybierz coś szybszego.

Chyba żartujesz :-)
$ pic32mx-objdump -S -h -d --section=.text code.elf | egrep -c ^9d.*:
6560

6550 instrukcji asm, nie wiem ile miesięcy by zajęło zabawa w
optymalizację tego na poziomie asm. Z tego co udało mi się dowiedzieć
taki transfery są spowodowane cechami implementacji stosu usb
Microchipa i niekoniecznie jedynym rozwiązaniem jest poprawianie kodu
wynikowego asm.


> Mam wrażenie, że kompilator nie radzi sobie w ogóle z kolejkowaniem
> instrukcji i danych
> w rdzeniu MIPS. Przez to powstają znaczące opóźnienia.

Sugerujesz, że gcc-mips-4.5.2 jest "niedopracowany"? Brzmi to dość
wyzywająco, szczególnie, że to już raczej dojrzała architektura i gcc
raczej powinien dobrze sobie z nią radzić.

--
Marek

do góry

> Sugerujesz, że gcc-mips-4.5.2 jest "niedopracowany"? Brzmi to dość
> wyzywająco, szczególnie, że to już raczej dojrzała architektura i gcc
> raczej powinien dobrze sobie z nią radzić.
Nie jestem pewien, czy dokładnie 4.5.2, ale dokładnie tak uważam,
gdyż oglądałem kod po kompilacji. Zresztą na każdym kroku piszą, że
to użytkownik powinien wiedzieć, jak sterować kolejką i nie zakładać, że
kompilator to zrobi najlepiej.
Niestety nie powiem Ci gdzie to wyczytałem, ale jakoś tak to szło.

Przy czym ja podziękowałem za gcc i zrobiłem full in asm.
Jeśli dobrze odczytuję raport, to czytego kodu w asm wyszło ok. 4kB.
Reszta to obrazki.


Microchip PIC32 Memory-Usage Report

kseg0 Program-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.rodata 0x9d000008 0x69280 430720 Read-only
const
.text 0x9d069288 0xebc 3772 App's exec
code
.text.general_exception 0x9d06a144 0xd0 208
.text 0x9d06a214 0x28 40 App's exec
code
.dinit 0x9d06a23c 0x10 16
.text._general_exceptio 0x9d06a24c 0xc 12
.text._bootstrap_except 0x9d06a258 0xc 12
.text._on_reset 0x9d06a264 0x8 8
.text._on_bootstrap 0x9d06a26c 0x8 8
Total kseg0_program_mem used : 0x6a26c 434796 82.9% of
0x80000


--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl Systemy elektroniczne.
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB.

do góry

On Mon, 4 Nov 2013 21:03:52 +0100, Sylwester Łazar<i...@a...pl>
wrote:
> Nie jestem pewien, czy dokładnie 4.5.2, ale dokładnie tak uważam,
> gdyż oglądałem kod po kompilacji. Zresztą na każdym kroku piszą, że
> to użytkownik powinien wiedzieć, jak sterować kolejką i nie
zakładać, że
> kompilator to zrobi najlepiej.
> Niestety nie powiem Ci gdzie to wyczytałem, ale jakoś tak to szło.

A jakie optymalizacje miałeś włączone (-O)?

--
Marek

do góry

> A jakie optymalizacje miałeś włączone (-O)?
>
> --
> Marek
Nie manipulowałem przy opcjach kompilacji.
Po prostu, zobaczyłem efekt przy domyślnych wartościach firmowego przykładu
Microchipa (!!!) *.mpc i stwierdziłem, że skoro wypieszczony przykład nie
działa,
to co tam będę "grzebał śrubokrętem w Rubinie 714".
Dodam, że projekt został rozpoczęty i ukończony w asm, spełniając moje
oczekiwania bez zbędnych kompromisów, które będą z pewnością konieczne przy
Twoim problemie.
S.

do góry

On Mon, 4 Nov 2013 23:13:33 +0100, Sylwester Łazar<i...@a...pl>
wrote:
> Dodam, że projekt został rozpoczęty i ukończony w asm, spełniając
moje
> oczekiwania bez zbędnych kompromisów, które będą z pewnością
konieczne przy
> Twoim problemie.

Ale zdajesz sobie sprawę z złożoności problemu, który wymaga w moim
przypadku implementacji następujących warstw:
- usb host
- mass storage
już nie wspominam, że musi to być połączone z:
- filesystem driver (fat32)
- ethernet driver
- tcp/ip

Celem jest zamiana w działającym już projekcie karty sd, na pendrive
bo jest wygodniejszy i zajmuje mniej pinów do komunikacji.
I rozumiem, że Ty taki projekt zaczął byś w asm pisać zamiast pójść
na kompromis i skorzystać z gotowego i przetestowanego softu?

Uruchomienie usb msd zajęło mi godzinkę: przeniesienie kodu
potrzebnych driverów usb msd do drzewa projektu, korekta kilku
linijek kodu usb msd aby dostosować je do współpracy z driverem fat,
który używam zamiast tego, który używa msd Microchipa, mała korekta
Makefile.
Gdyby nawet te future drivey były tylko w asm zamiast w C, to
włączenie ich w istniejący projekt na pewno zajęłoby więcej niż tą
godzinę.

--
Marek

do góry

> Uruchomienie usb msd zajęło mi godzinkę: przeniesienie kodu
...
> Gdyby nawet te future drivey były tylko w asm zamiast w C, to
> włączenie ich w istniejący projekt na pewno zajęłoby więcej niż tą
> godzinę.
>
> --
> Marek
Wiesz dobrze, tak jak ja, że czas jaki na to poświęciłeś, aby to uruchomić,
był znacznie dłuższy.
Samą godzinkę, to może zajęło Ci skompilowanie i dostosowanie.
Droga opracowania projektu składa się z wielu dodatkowych kroków, które są
niezależne
od asm czy C np. instalacja MPLABA na nowszym komputerze, przeczytanie
manuala do DevBoard'a, poszukanie, którą procedurę musisz wywołać,
zrozumienie co autor miał na myśli itp.

Jednak to co następuje teraz, to faza wymiany hardware'u na konkurencję (jak
napisałeś).
W związku z powyższym trochę tak uciekasz i ... znów kilka godzin.

Jeżeli Twój projekt wydaje Ci się duży, to rozbij go na mniejsze.
W szczególności możesz użyć np. dwóch procesorów z gotowym C-codem:
a) do szybkiego internetu
b) do obsługi karty SD
Jednak to jest jeszcze większa ucieczka.

Tak czy inaczej napisz do jakich prędkości doszedłeś i na czym, bo chyba nie
zdecydujesz się na asm.

Miałem taki przypadek, gdzie była prosta pętla w C na odczytywanie portu
równoległego i wysyłanie po Ethernecie.
Chłopak napisał to w C, używając stosu Microchipa na 18Fxxxx
Sama pętla wysyłania danych była prosta jak drut.
Nalegałem, aby zobaczyć gdzie biega w pętli mikrokontroler.
Wstawka została zrobiona w asm i transfer podskoczył kilkakrotnie.
Czasem naprawdę niewiele potrzeba.
S.

do góry

On Tue, 5 Nov 2013 10:49:48 +0100, Sylwester Łazar<i...@a...pl>
wrote:
> od asm czy C np. instalacja MPLABA na nowszym komputerze,
przeczytanie

Nie używam mplabl'a.

> manuala do DevBoard'a, poszukanie, którą procedurę musisz wywołać,


Nie używam jakiegoś konkretnego devboarda, płytka stykowa jedynie.

> Jeżeli Twój projekt wydaje Ci się duży, to rozbij go na mniejsze.
> W szczególności możesz użyć np. dwóch procesorów z gotowym C-codem:
> a) do szybkiego internetu
> b) do obsługi karty SD
> Jednak to jest jeszcze większa ucieczka.

Projekt wydawałby mi się duży, gdyby był w asm, wręcz nie do
ogarnięcia, jakbym miał co chwilę coś zmieniać, bo dłubać lubię :). W
asm to byłby kompletny nonsens. W C całość jest czytelna, podzielona
na poszczególne liby robiące konkretne rzeczy, spokojnie do
ogranięcia jeśli uwzględnić stosunek liczby funkcji do objętości
kodu, szczególnie przez takiego amatora jak ja.

> Tak czy inaczej napisz do jakich prędkości doszedłeś i na czym, bo
chyba nie
> zdecydujesz się na asm.

Wąskie gardło jest w Microchipowej implementacji komend scsi read10
(write10), w jednej transakcji jest odczytywany tylko 1 blok 512
bajtów (bo pokrywa się to w większości przypadków z wielkością
sektora), Każda transakcja idzie w określonej ramce czasowej usb,
czytanie w jednej ramce tylko 512 jest tym wąskim gardłem. Jednym ze
sposobów jest zwiększenie ilości bloków per trans. w read10, jak
zwiększyłem liczbę bloków w read10 transfer skoczył do ~1 MB/s.
Oczywiście aby to działo na poziome fs to taka manipulacja (zmiana
wielkości sektora/liczby bloków per read) musi być uwzględniona w
warstwie drivera fs. Drugi sposób oraz więcej info na ten temat można
przeczytać tutaj:

http://www.microchip.com/forums/tm.aspx? high=&m=524271&mpage=1#524504

--
Marek

do góry

> http://www.microchip.com/forums/tm.aspx? high=&m=524271&mpage=1#524504
>
> --
> Marek
Ładny rysunek gość załączył.
Wiesz może z jakiego to analizatora?
Tak czy inaczej problem jest szerszy. Opóźnienia są w wielu źródłach:
a) procedury zapisu/odczytu USB
b) overhead / stata czasu na obsługę zbędnego protokołu USB.
Nie wiem, czy w trybie Bulk nie działałoby to lepiej.
c) mało pamięci RAM
d) pojęcie stosu -zupełnie nieadekwatne do naszych czasów.
Wynika moim zdaniem, tylko z braku RAM.
e) przekazywanie parametrów/ wzajemne wywoływanie procedór dla obsługi SD
itp.

Złożenie tego w profesjonalną całość jest trudne.
Wiedzą o tym producenci Smartfonów.
Okazuje się, że taki smartfon ma 4 rdzenie. Linux działający na tym ma za
zadanie
zrobić zdjęcie, przesłać, pokazać. To to samo z filmem.
Moja znajoma nosi takiego smartfona w tylniej kieszeni spodni.
Bardzo sobie chwali, bo ma wszystko w jednym: telefon, zdjęcia, filmy,
storage itp.
Nie musi wozić ze sobą aparatu, albumów.
Problem jest jednak inny.
Wygląda na to, że jedynym rozwiązaniem w wykonaniu prostych rzeczy staje się
rozbudowa programowa, polegająca na dodawaniu bibliotek i wypuszczaniu
kolejnych wersji systemu z poprawkami.
Realizację tego powierza się multiplikowanym procesorom, choć nie chodzi tu
o wydajność matematyczną, tylko o szybkość przerzucania megabajtów
instrukcji, aby dwoma palcami powiększyć zdjęcie.
Dojdziemy do gigajtowych bibliotek wyświetlających ikonki (teraz widgety się
to chyba nazywa. Kiedyś ghosty czy sprites?) na 256-bitowych procesorach
zmultiplikowanych w postaci 2000 pinowego BGA (ups... też już nie pinowego,
tylko plackowego?), który mieści w sobie 64 rdzenie.
Lepiej już od razu ustalić, że PCB to będzie obudowa BGA, do której dokleja
się baterię, głośnik, LCD i antenę.

--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl Systemy elektroniczne.
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB.

do góry