On Thu, 7 Nov 2013 09:31:29 +0100, Sylwester Łazar<i...@a...pl>
wrote:
> > 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?

Nie wiem, age chyba kris w tym wątku o top pytał, może jest odpowiedź.

> 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.

Zrobiłem poprawkę zgodnie z uwagami Tsuneo, dodałem extra cache z
czymś w rodzaju read-ahead i zadziałało, uzyskałem ponad 2x większy
transfer, który mnie satysfakcjonuje. Nie widzę dalej potrzeby aby w
to wnikać. Moim celem była implementacja mass storage i już. Bez
wnikania jak to działa, pod warunkiem, że spełnia moje oczekiwania.
Darowanemu koniowi w zęby się nie zagląda :).

> Nie wiem, czy w trybie Bulk nie działałoby to lepiej.

To jest w tym trybie, inaczej chyba msd nie działa.

> 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.

Ale co ty z tym SD cały czas, tu chodzi o usb. Obsługa SD (w trybie
spi) jest tak banalna, że nawet sobie wyrażam ją zrobioną w asm,
żaden cymes. Aczkolwiek nie sądzę że z powodu jej prostoty w ams
będzie szybsza/mniejsza (co kto woli) niż w C.

Na brak RAMu jeszcze nie narzekam: tcpip + ethernet + httpd (obsługa
10 połączeń na raz) + telnetd z microshell + obsługa usb pendrive
(doc root) z 4k cache + obsługa 1wire + obsługa rfm12b zajmuje 24 kB
RAM (w tym jest 2k stosu i 1k sterty na malloc). Flasha zajmuje 127kB
z 128kB w pic32mx250.
Wiadomo, że raki mcu to jest taka popierdułka, jest pewnym
kompromisem między wydajnoscią a zużyciem energii. Jakbym chciał
szybki usb czy ethernet to postawilbym jakieś raspbbery pi i w ogóle
pisaniem softu bym sobie głowy nie zwracał tylko użył gotowce.



> 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ę.

I co z tego że gigabajty? Rozwiązanie ma się dobrze sprzedać, nie
ważne ile gigabajtów ma przerzucać. Jeśli będzie popyt na 12
rdzeniowe smartfony z dwu gigabajtowymi ikonkami to będzie to
produkowane i producent nie będzie się naprężał, żeby ikonki były
jedyno gigabajtowe.

--
Marek