Adam Dybkowski wrote:
> 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.

do góry

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.

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

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

http://sources.redhat.com/binutils/docs-2.15/ld/Scri
pts.html
http://www.bilmuh.gyte.edu.tr/gokturk/introcpp/gcc/l
d_3.html

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

On Thu, 2 Jul 2009 04:42:21 -0700 (PDT), slawek7 wrote:
>Powiedzcie mi proszę, jak jest różnica w obsłudze przez uC np AVR kart
>SD zwykłych od SD High Capacity SDHC?
>Jeśli mam napisane funkcje działające na kartach np 512M i podłącze do
>uC kartę oznaczona SDHC to czy aby została ona obsłużona?
>Jeśli nie to co należy zmienić w oprogramowaniu, aby zadziałało?

Oprocz wielu drobnostek, masz jeszcze taka sprawe ze mniejsze karty
moga miec FAT16, a HC to juz FAT32.

http://en.wikipedia.org/wiki/Secure_Digital_card#SDH
C

J.

do góry

On Thu, 02 Jul 2009 22:29:20 +0200, Sebastian Biały wrote:
>> http://www.roland-riegel.de/sd-reader/
>
>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ć.

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

J.

do góry

>>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ć.
>
> No to na podstawie powyzszego dopasuj sie do swojego swietnie
> zmodularyzowanego programu, a potem opublikuj :-P
>

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

do góry

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

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

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.

do góry

Sebastian Biały pisze:

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

A ja myślę, że po prostu marudzisz. W firmie, w której pracowałem jeden
gość napisał kod potrzebny do obsługi SD/HC w ciągu tygodnia (włączając
w to czytanie dokumentacji i testowanie kart różnych producentów). Na
stronie SD Association jest dokumentacja, są opisane różnice w
inicjalizacji kart sd i sdhc. Na tej stronie też jest całkiem fajny opis:

http://elm-chan.org/docs/mmc/mmc_e.html

--
przeciez moje rozumowanie bylo bez skazy,
no sam bym wskoczyl do tego wulkanu,
ale kto by tak pieknie gwizdal...

do góry

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

To nie tak do konca, ze ludzie pisza badziewny kod. Pisanie na male
procki ma swoja specyfike, m.in. brak zasobow. Napisanie uniwersalnej
biblioteki jest fajne, ale niekoniecznie optymalne. W efekcie musisz
korzystac np. z wiekszego procka, niz gdybys napisal kod "badziewny" ale
za to krotszy/szybszy i lepiej dostosowany do konkretnej sytuacji.
Inna sprawa, ze ludzie czesto udostepniaja po prostu to co im dziala, w
ich konkretnym zastosowaniu.

--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

do góry

Zbych wrote:
>> 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.

> A ja myślę, że po prostu marudzisz.

Masz do tego prawo.

> W firmie, w której pracowałem jeden
> gość napisał kod potrzebny do obsługi SD/HC w ciągu tygodnia

Pozostaje mi pogratulować. Tylko czego to dowodzi? Napisanie tego jest
_trywialne_. Mniej trywialne jest takie zaprojektowanie calości aby
zredukować malloc/free a jednocześnie np. zapewnić synchronizację
międzywatkową SPI i pare innych duperelek ważnych w danym projekcie.
Więc może i bym był w stanie napisać SDHC w 3 dni tylko może
niekoniecznie działające zgodnie z koncepcjami innych elelementów
systemu? Najpierw z chęcią obejrze inne projekty aby nie popelniać
błędów które już ktoś popełnił.

Robie coś większego niż grajek mp3. SPI jest współdzielone z innymi
elementami systemu. Napisanie calosci jest troche bardziej skomplikowane
niż wynika z "opini jakiegoś gościa".

do góry

T.M.F. wrote:
> To nie tak do konca, ze ludzie pisza badziewny kod. Pisanie na male
> procki ma swoja specyfike, m.in. brak zasobow.

Nie tłumaczy to nijak wewnętrznej potrzeby generowania zmiennych
globalnych i ustawionych na sztywno niby-interfejsów.

> Napisanie uniwersalnej
> biblioteki jest fajne, ale niekoniecznie optymalne.

Czekaj, bo zaczyna się nastepna bez sensu dyskusja. Ja jestem
zwolennikiem C++ na uC (włacznie z 8-bitowcami) wiec obawiam się ze za
chwile zacznie się jakiś flame. Tak więc EOT.

do góry