On Thu, 22 Sep 2016 09:10:42 +0200, slawek <f...@f...com> wrote:
> Że zapis np. 8 bajtów kosztuje w energii tyle co zapis 512 bajtów?

Ale i tak musisz docelowo użyć nośnik flash, więc co to zmienia?

--
Marek

do góry

On Thu, 22 Sep 2016 09:22:16 +0200, slawek <f...@f...com> wrote:
> Gorzej jeżeli 10 mA miałoby płynąć non stop. I aby temu zapobiec
> myślę o jakimś sprytnym buforowaniu "kapiących" danych. Być może w
> SRAM. Tu znowu ciekawy myk: czy jest sens oddzielnej pamięci, czy
po
> prostu użyć innego MCU? Trzeba zobaczyć czy są tanie z np. 16kB.

Oczywiście. Są nawet z 128kB ram więc, w czym problem?

--
Marek

do góry

On Thu, 22 Sep 2016 09:28:06 +0200, slawek <f...@f...com> wrote:
> Wiem co powiedziałem gdy w Nikonie padła karta BASF: "mamy zdjęcia
z
> Olympusa".

A czy BASF jest jeszcze jakąś marką? Nie skończył podobnie Thompson,
Grundig czy Telefunken?

--
Marek

do góry

On Thu, 22 Sep 2016 10:09:09 +0200, Marek <f...@f...com> wrote:
> Ale i tak musisz docelowo użyć nośnik flash, więc co to zmienia?

Policz. Jeden bajt kosztuje tyle co 512 bajtów, bo nie da się go
zapisać inaczej niż przez zapis całego bloku. Jeżeli chcesz zapisać
np. 8192 próbki jednobajtowe, to zapisując je po jednym bajcie będzie
cię to kosztowało 512 razy tyle co zapis paczkami po 512 bajtow
każda. Podobnie będzie dla 513 bajtów. Owszem pierwsze 512 gładko
przejdzie. Ale ten jeden bajt będzie jeszcze.

do góry

On Thu, 22 Sep 2016 10:11:58 +0200, Marek <f...@f...com> wrote:
> A czy BASF jest jeszcze jakąś marką? Nie skończył podobnie
Thompson,
> Grundig czy Telefunken?

Nie wiem. Po prostu od wielu wielu lat nic nie kupuję od BASF. Chyba
nie muszę tłumaczyć dlaczego?

do góry

On Thu, 22 Sep 2016 09:10:42 +0200, slawek <f...@f...com> wrote:
> Że zapis np. 8 bajtów kosztuje w energii tyle co zapis 512 bajtów?

A teraz załapałem w czym problem. Zamiast dostosować mcu do zadania
próbujesz dostosować zadanie do mcu. Zamiast mieszać szpachlę łokciem
użyj mcu z odpowiednią ilością ram np. z 64kB. Ile potrzebuję ten
Twój program, z 10kB? Pozostanie ~6000 buforów 8 bajtowych do
buforowania rzadkich zapisów na sd. 6kB bufor w ram chyba Ci
wystarczy do tego zadania, nie?

Taka uwaga P.S. Na prawdę marnotrastwem jest zatrzymywanie się na
8bitowych mcu i próbowaniem na siłę ich używania tam, gdzie szkoda na
to czasu. Przejście na 32bitowce oszczędza kombinowanie.

--
Marek

do góry

On Thu, 22 Sep 2016 10:36:06 +0200, Marek <f...@f...com> wrote:
> A teraz załapałem w czym problem. Zamiast dostosować mcu do zadania
> próbujesz dostosować zadanie do mcu. Zamiast mieszać szpachlę
łokciem


> to czasu. Przejście na 32bitowce oszczędza kombinowanie.

Jeżeli 8 bitowiec kosztuje 5 PLN, extra pamięć jest poniżej 1 USD, to
jaki jest sens pchania się w 32 bitowy procesor nie mający możliwości
Intel I7 czy innego 64 bitowca?

do góry

Użytkownik "Marek" napisał w wiadomości grup
dyskusyjnych:a...@n...neos
trada.pl...
On Thu, 22 Sep 2016 09:28:06 +0200, slawek <f...@f...com> wrote:
>> Wiem co powiedziałem gdy w Nikonie padła karta BASF: "mamy zdjęcia
>> z Olympusa".
>A czy BASF jest jeszcze jakąś marką? Nie skończył podobnie Thompson,
>Grundig czy Telefunken?

Ogolnie to chyba nie - fabryki BASF widuje, nawet w kraju. Cos tam
robia, nawet nie wiem co.
(chyba, ze mi sie pomylilo).
Ale ... karty pamieci to oni kiedykolwiek robili ? Chyba na tasmach
magnetofonowych skonczyli, zreszta nie wykluczam, ze jeszcze jakies
resztki tasm robia ... czy juz nikt tasm nie uzywa ?

Branduja jakies karty, czy marke sprzedali ale tylko w dziedzinie
elektroniki ?

J.

do góry

Użytkownik "Marek" napisał w wiadomości grup
dyskusyjnych:a...@n...neos
trada.pl...
On Tue, 20 Sep 2016 21:23:54 +0200, "J.F."
<j...@p...onet.pl> wrote:
>> Nie - nie myl sektora "dyskowego" z tym ktory jest w rzeczywistej
>> pamieci.

>Mylisz z rozmiarem page erase, który jest wew. cechą kontrolera sd,

Raczej uzytej pamieci.

>page erase to nie sektor, nie wolno tego mylić.
>Rozmiar sektora jest _analogiczny_ z sektorem dyskowym (od 512 do
>4096) , bo inaczej nie byłoby to przezroczyste dla warstwy drivera
>fs.

Ale efekt taki, ze dobrze by bylo zapisywac w rozmiarze tej erase
page.

Chociaz ... jak tak mysle ... przeciez zawsze tych danych jakos tam
przybywa, wiec kontroler musi potrafic to "dopisywanie" obsluzyc.
Tylko ... nie zamykac pliku zbyt czesto, aby FAT i katalogu nie
zapisywac co chwila bez potrzeby ?

J.

do góry

On Thu, 22 Sep 2016 11:00:54 +0200, slawek <f...@f...com> wrote:
> Jeżeli 8 bitowiec kosztuje 5 PLN, extra pamięć jest poniżej 1 USD,
to

Ktoś tutaj podawał przykład arma za poniżej 10pln.
A swój czas zmarnowany na kombinowanie policzyłeś? Po co dokładać
n+1 urządzeń jeśli można to zrobić jednym bez kombinowania?

> jaki jest sens pchania się w 32 bitowy procesor nie mający
możliwości
> Intel I7 czy innego 64 bitowca?

Serio w swoich układach embedded potrzebujesz I 7?
Sens jest taki, że daje komfort użycia więcej ram i flash bez
zbędnego kombinowania (jeśli nie pisze się softu na konkurs p.t."ile
funkcjonalniści da się zmieścić w 1kB ram i 16kB flash").

Podam Ci bieżący przykład jak to upraszcza życie. Zbudowałem sobie
lokalizator wysłajacy pozycję do serwa w opraciu o gps+gsm. Ma też
kilka innych funkcji, których nie ma w komercyjnych rozwiązaniach,
więc zdecydowałem się, że zrobie taki jaki potrzebuję. Początkowo w
projekcie było USB na pendrive do buforowania lokacji gdy gsm jest
niedostepny z jakiś powodów. Pendrive miał być też pomocny do
aktualizacji softu gdyby doszły jakieś funkcjonalności. Później
stwierdziłem, że pen jest niewygodny bo wystaje a urządzenie ma być
na stałe w pojeździe i to w miejscu słabo dostępnym. No to może karta
sd, jest mniejsza. Ale i tak pozostaje problem jej ewntualnego jej
wyciągania. Bez sensu. W końcu doszedłem do wniosku, że po xuj zew.
nośnik jak mam w mcu 64kB ram, starczy na kilkaset zbuforowanych
pozycji. Ale pozostał problem aktualizacji. Ale moment, przecież mam
256kB flash, a używam tylko ok 60kB. Niech mcu nowy soft pobierze
sobie przez gsm, wrzuci go tymczasowo w nieużywany obszar flash a
bootloader później go przekopiuje w miejsce docelowe. I już.
Tak ewoluują pomysły gdy się ma odpowiednio dostępne zasoby.
Oczywiście taką samą funkcjonalność lokalizatora bez problemu zaszyło
by się w 8 bitowcu. Ale i tak nie starczyło by ramu na odpowiednie
buforowanie danych, więc po co kombinować??

--
Marek

do góry