Darkac pisze:

>> http://www.nongnu.org/avr-libc/user-manual/pgmspace.
html

> Dzięki za linka. Prawdopodobnie to rozwiąże ten problem. Szkoda tylko że
> trzeba odwoływać się do różnych chytrych sztuczek żeby uzyskać, tak
> wydaje się, podstawowe i częste pożądane działania.

Szczerze polecam: przesiądź się na procesory ARM.
Tam przestrzeń adresowa jest wspólna (adresowanie 32-bitowe), co
rzeczywiście w porównaniu z AVRami znacząco ułatwia życie. W ARMach z
wewnętrznym Flashem stałe trzymane są w pamięci Flash i zwykłe napisanie
"const" nie zjada RAMu. No i można wykonywać program z RAMu (np.
załadowany z pliku), co w AVRach jest po prostu niemożliwe.

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

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

do góry

Darkac pisze:

> Kompilator robi miliony różnych automatycznych operacji, mógłby robić
> również i to. Wszystko powinno być podporządkowane wygodzie człowieka.
> Po co zaśmiecać głowę i treść programu operacjami które może zrobić
> maszyna.
> Szybkość, łatwość i wygoda, to powinny być priorytety w pracy programisty.

Pomyliłeś języki, zacznij pisać raczej w Javie.

Tam kod wynikowy wykonywany przez procesor jest znacząco oddalony od
tego, co napisał programista (oprócz kompilatora po drodze jest maszyna
wirtualna tłumacząca bytecode na asembler danego procka). Nawet
skomplikowane akcje pisze się szybciej i krócej niż w C, ale wynikiem
tego jest kod działający znacznie wolniej niż napisany od razu w języku
C no i przy tym znacznie dłuższy (po kompilacji w JRE, bytecode może być
nawet krótszy). No ale jeżeli przedkładasz koszt developmentu nad
wydajność aplikacji to Java będzie w sam raz dla Ciebie.

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

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

do góry

> Masz dokument opisujący OCD w ATMega?

Datasheet procesora sekcja "Using the on-chip debug system".

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

do góry

>> Masz dokument opisujący OCD w ATMega?
>
>
> Datasheet procesora sekcja "Using the on-chip debug system".
>

Możliwości OCD wyglądają nader skromnie.
K.

do góry

W dniu 15.10.2009 00:17, John Smith pisze:
>
>>> Masz dokument opisujący OCD w ATMega?
>>
>>
>> Datasheet procesora sekcja "Using the on-chip debug system".
>>
>
> Możliwości OCD wyglądają nader skromnie.

Mozliwe, a czego konkretnie ci brakuje?

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

do góry

>>>> Masz dokument opisujący OCD w ATMega?
>>>
>>>
>>>
>>> Datasheet procesora sekcja "Using the on-chip debug system".
>>>
>>
>> Możliwości OCD wyglądają nader skromnie.
>
>
> Mozliwe, a czego konkretnie ci brakuje?
>

Popatrz w SLAA263B na pułapki warunkowe.
Typowo jak piszę program naraz używam 4 do 6 pułapek. Jest do 8.
K.

do góry

> W kwestii ogólnej:
>
> To przeciez przesyła się do procedury wskaznik na strukturę i po sprawie.
> Zamiast kilkudziesięciu zmiennych tylko jeden parametr, nic nie trzeba
> zwracać, procesor nie musi mielić danych etc
> Strukturę też mozna banalnie powielać - same plusy.
>
> A zwracać procedura powinna tylko char lub int syknalizującego OK lub
> ERROR
>
> Pozdrawiam
> MiSter

Zgadzam się że to może być dobry sposób, ale brak mu poważnej zalety jaką ma
moje rozwiązanie. Mianowicie możliwość porównania wpływu poprawek w
programie na skuteczność działania procedury. Ta procedura to coś w rodzaju
filtru zakłóceń i wydobycia z sygnału właściwej informacji, wymagająca
znalezienia satysfakcjonującego punktu równowagi pomiędzy skutecznością
filtracji a brakiem zniekształcenia lub likwidacji istotnych informacji
sygnału. Wymagało to wielu prób i błędów.
A tak na oba kanały podawało się ten sam sygnał, poprawki wnosiło się do
jednego kanału i porównywało wpływ na wynik. Jak dobry ruch to powielało się
do drugiego kanału i pracowało nad następnym problemem.

do góry

Użytkownik "John Smith" <d...@b...pl> napisał w wiadomości
news:hb5khn$det$1@217.76.112.12...
>>>>> Masz dokument opisujący OCD w ATMega?
>>>>
>>>>
>>>>
>>>> Datasheet procesora sekcja "Using the on-chip debug system".
>>>>
>>>
>>> Możliwości OCD wyglądają nader skromnie.
>>
>>
>> Mozliwe, a czego konkretnie ci brakuje?
>>
>
> Popatrz w SLAA263B na pułapki warunkowe.
> Typowo jak piszę program naraz używam 4 do 6 pułapek.

Bo ściebie doopa nie pisasz.

>Jest do 8.

Ojej to straszne, ze mega nie ma 8. Zwykle malkontectwo. Kurna co za
czlowiek, nastepny ktory stosuje jedynie sluszne rozwiazania, jaroslaw
rozsiewa jakiegos wirusa czy co?

do góry

Użytkownik "Adam Dybkowski" <a...@4...pl> napisał w wiadomości
news:hb5got$sgc$1@news.onet.pl...
> Darkac pisze:
>
>>> http://www.nongnu.org/avr-libc/user-manual/pgmspace.
html
>
>> Dzięki za linka. Prawdopodobnie to rozwiąże ten problem. Szkoda tylko że
>> trzeba odwoływać się do różnych chytrych sztuczek żeby uzyskać, tak
>> wydaje się, podstawowe i częste pożądane działania.
>
> Szczerze polecam: przesiądź się na procesory ARM.
> Tam przestrzeń adresowa jest wspólna (adresowanie 32-bitowe), co
> rzeczywiście w porównaniu z AVRami znacząco ułatwia życie. W ARMach z
> wewnętrznym Flashem stałe trzymane są w pamięci Flash i zwykłe napisanie
> "const" nie zjada RAMu. No i można wykonywać program z RAMu (np.
> załadowany z pliku), co w AVRach jest po prostu niemożliwe.

Ja tam radze przesiadke na Turbo Pascala.

do góry

> Oj, jednak pola bitowe sa czytelniejsze. No i jesli zmienisz ich
> kolejnosc to nie pociaga to potem zazwyczaj uperdliwej zmiany we
> wszytkich plikach.

Z kolejnością się nie zgodzę!! Tworzę jeden plik nagłówkowy i tam
umieszczam wszystkie definicje - nie ma problemu ze zmianą kolejności ;D...
Jest jedno "za" tą metodą (i z tego względu tego też używałem). Z tego,
co gdzieś kiedyś czytałem [potrzebne źródło ;)] to kompilator ma prawo
dowolnie rozmieścić pola bitowe w bajcie. Niekoniecznie będą więc one
umieszczone w kolejności wpisywania... w momencie, w którym chce się
potem taki bajt gdzieś "wyświetlić", to koniecznie trzeba wiedzieć który
bit co oznacza, a używając pól bitowych (dwukropka ;)), możemy tego nie
wiedzieć...

Pozdrawiam
Konop

do góry