Re: Obs?uga kart SDHC przez uC który pracowa? z k

Ja właśnie dodawałem obsugę SDHC do swojego projektu. Opierałem się na źródłach stąd:

ładnie rozpisane 'co i jak'.

Marcin

Kolejna "biblioteka" bez pojecia interfejsów :/ Doprowadzenie tego do stanu abstrakcyjności to ciężki kawałek chleba. Wlasnie to obejrzalem i chyba moze się przydać tylko jako przykład bo ciężko to wsadzić bez grzebania w swój projekt.

Zna ktos może cos _zaprojektowanego_ co pozwala latwo odpinać fs, urządzenie blokowe, komunikację spi i nie zależy do zbędnych implementacji? Tez musze napisać cos pod SDHC a że nie mam nic chwilowo to mogę się dopasować.

Sebastian Biały pisze:

Jeżeli potrzebujesz takiej modułowości i poziomu abstrakcji to może po prostu przeportuj sobie zestaw sterowników z Linuxa i już. A gdy do w pełni komercyjnego projektu - poszukaj w źródłach FreeBSD/OpenBSD. Licencja BSD jest piękna pod względem "pożyczania" sobie kodu. :)

Już oglądałem, to nie na uC. Projektowane z myślą o niekończonych zasobach RAM. Chodzi o coś, co ma cechy pozwalające wypełnic przeze mnie interfejsy różnymi implementacjami i potrafi sobie radzić przy małym RAM, idealnie bez malloc. Ba, może nawet ja dostarcze warstwę operowania na RAM (i zrobię kompaktujący heap). No dobra, wystarczy że nie bedzie zależało od 100 funkcji i zmiennych globalnych i juz bedzie lepiej ;).

A piszesz na GPLu? Jesli tak to zobacz moje repo. Co prawda SDHC jeszcze nie zaimplementowalem, ale z urzadzen "blokowych" mam FLASH/FRAM na I2C i FLASH z mikrokontrolera. Dodanie SDHC (co planuje zreszta uczynic) to stworzenie klasy dziedziczacej po abstrakcyjnej klasie TMFStorage. BTW, moze jet tu jakis gcc-guru, ktory chcialby mi pomoc w spathowaniu avr-gcc tak, zeby trzymal vtables w pamieci FLASH?

Nie :(

Pisanie w nie-GPLu w niczym nie przeszkadza w zerknieciu :D

O. I już lepiej.

A nie da się tego zrobić skryptem linkera? Od razu mówie, ze nie wiem, bo na razie RAMu jeszcze troche mam i mnie bardzo nie boli, ale za chwile dokladnie ten problem będę musiał rozwiązać, u mnie tez chyba trzyma w RAM.

Nie, bo w AVR dostep do FLASH jest realizowany za pomoca innych instrukcji (LPM) niz dostep do SRAM (LD). A niestety metody wirtualne niezle jada po pamieci.

T.M.F. pisze:

Od zawsze myślałem, że AVRy nieszczególnie nadają się do C++, właśnie utwierdziłeś mnie w tym przekonaniu.

Na ARMach natomiast (926EJ-S dokładniej mówiąc) C++ śmiga jak burza. Akurat w takich prockach pamięci rzadko kiedy brakuje.

W dniu 03.07.2009 00:05, Adam Dybkowski pisze:

Na AVR C++ tez smiga jak burza. To, ze gcc trzyma vtables w SRAM wynika raczej z samego ograniczenia kompilatora - w tym przypadku braku wsparcia dla roznych segmentow pamieci. Inne komercyjne kompilatory nie maja chyba tego problemu. No ale gcc nie byl projektowany na architekture harwardzka.

:D Ja nie mówię o AVRach. Ja potrzebuje na ARM7/9 a tam jest architektura von Neumanna.

I oczywiście nie doczytalem nazwy kompilatora podanego przez T.M.F., sorry ;)

T.M.F. pisze:

Co nie znaczy, że tak będzie zawsze :-). Na jesieni zeszłego roku pojawiły się pierwsze łaty na gcc wprowadzające przestrzenie adresowe. Wersja 4.5 ma to już chyba zaimplementowane, ale brakuje oczywiście backendu na avr.

Tak, laty juz sa:

pisales wprowadza w gcc 4.5, kiedy doczekamy sie portu na AVR trudno powiedziec, kiedy to bedzie realnie do wykorzystania to wrozenie z fusow, w koncu jeszcze nawet nie mamy gcc 4.4 na AVR. Znaczy formalnie jest, ale nikt nie gwarantuje, ze bedzie dzialal:)

Sebastian Biały pisze:

No to popatrz na poprzednie odpowiedzi. Jeżeli twoje magiczne tablice C++ wpadają do jakiejś wyróżnionej sekcji (a nie np. ".text") - to żaden problem kazać linkerowi umieścić je we Flashu. ARMowi wszystko jedno w gruncie rzeczy, skąd je pobierze, o ile dostanie właściwy adres (tyle że z Flasha np. w AT91SAM7 odczyty idą nieco wolniej niż z wewnętrznego SRAMu bo potrzebny 1ws przy zegarze powyżej 33MHz a do tego Flash jest

16-bitowy).

Tak, ja wiem, że linker to może zrobic, po prostu jak zwykle skrypty linkera które mam "z internetu" są spieprzone i trzeba bedzie je poprawiać tyle że najpier muszę trochę jednak o tym poczytać. Co do prędkości jest ok, nie robie nic super wydajnego.

Sebastian Biały pisze:

No cóż, co by tu dodać. Poczytaj.

No to na podstawie powyzszego dopasuj sie do swojego swietnie zmodularyzowanego programu, a potem opublikuj :-P

J.

Dokładnie to samo chciałem napisać, tylko się jakoś powstrzymywałem :) Chesz używać 'super uniwersalnych' bibliotetek na GPL, wszystkie uważasz za marne, a sam robisz projekty zamknięte i nie chcesz podzielić się swoimi bibliotekami.

Marcin

Panowie. Jestem jednym z niewielu ludzi ktorzy promują (L)GPL gdzie tylko ma to sens. Jednak proponowalbym nie wypuszczać tego typu głupawych wniosków na podstawie jednego przypadku. Czasami musze zrobić coś CS i nic na to nie mogę poradzić. Takie życie.

Ponadto potrzebuje gotowca aby samodzielnie napisać wlasny. Bo na taki jak potrzebuje nadzieje straciłem już dawno. Ale na taki na podstawie ktorego można się czegoś _nauczyć_ jeszcze mam resztki nadziei.

Po drugie: mam pełne prawo krytykowac następny badziewny kod pisany w sposób który pokazuje totalne olewanie wszelkich zasad wypracowanych przez ostatnie 20 lat. Po prostu mogę. I nie oznacza to wcale że od razu musze pokazać lepsze. To że jest to badziewie projektowe widac od pierwszego zerkniecia w kod. Oczywiście tak wygląda całkiem spora ilość softu na uC (stara szkoła pisania w C). Fajnie by było jak by cześć młodego pokolenia niekoniecznie się na tym wzorowała i moze warto to głośno powiedzieć pokazując wady.