On 15.11.2015 12:30, Zbych wrote:
> On 15.11.2015 11:14, Marek wrote:
>>> i sprzętowym stosie?
>>
>> W czym to przeszkadza, skoro on jest tylko używany do call/return a
>> kompilator i tak używa własny stos, którego wielkość można dowolnie
>> ustalać? Po za tym są "shadowed registers", które sprzętowo wspomagają
>> zachowywanie/odtwarzanie rejestrów przy obsłudze przerwań.
>
> Sprzętowy stos przeszkadza w przełączaniu wątków.
> Ile jest zestawów "shadow registers"? Po jednym dla każdego wektora
> przerwania? Bo dokumentacja microchipa jest jakoś skąpa w tym zakresie.

Znalazłem odpowiedź, zestaw jest jeden:
Shadow registers can only be used with high priority interrupts - If low
priority interrupt uses shadow registers, then can be overwritten by
high priority interrupt

Czyli znowu zrobili to tak, żeby było upierdliwie.

do góry

On Sun, 15 Nov 2015 12:30:49 +0100, Zbych <z...@o...pl> wrote:
> Sprzętowy stos przeszkadza w przełączaniu wątków.

Bosh, jakie wątki, mówimy o prostej 8 bitowej architekturze.


> 8-bitowy procek nie oznacza 8-bitowej przestrzeni adresowej. Skąd
ten
> pomysł?

Wow, Atmega ma 16 bitowe rejestry ogólnego przeznaczenia (nie chodzi
o rejestr PC)?


> Normalnie, adres jest 16-bitowy (albo dłuższy).

Pytanie jak wyżej.


> PICC-18 allows RAM objects of any size to be declared, though some
> limitations exist that require balancing objects between C source
files
> in certain cases. C18 does not support RAM objects larger than 256
bytes
> by default; creating such objects requires editing linker control
files
> and adding pragmas to the C source which include hard-coded
variable
> addresses. These objects can only be accessed through pointers, not
> directly.

Moment, domyślnie przyjąłem, że mówisz o dużych tablicach we flash,
bo jeśli ktoś chce używać duże tablice w ram na tak małym mcu, to
przepraszam ale wybrał złe narządzie do realizacji swoich celów (co
jest nagminne).
Fakt, w przypadku ram jest tak jak opisujesz, natomiast nie widzę w
tym problemu o ile nie próbuje się wykorzystywać niekompatybilnego z
tym kodu.

--
Marek

do góry

On Sun, 15 Nov 2015 12:56:27 +0100, Zbych <z...@o...pl> wrote:
> Shadow registers can only be used with high priority interrupts -
If low
> priority interrupt uses shadow registers, then can be overwritten
by
> high priority interrupt
> Czyli znowu zrobili to tak, żeby było upierdliwie.

Priorytety w tak prostych mcu to tylko kwiatek do korzucha. Nigdy
nie miałem powodu ich używania, a jeśli bym miał użyłbym 32 bitowego
procka a nie bawiłbym się w furmanki na sterydach.

--
Marek

do góry

Dnia Sun, 15 Nov 2015 13:20:34 +0100, Marek napisał(a):
> On Sun, 15 Nov 2015 12:56:27 +0100, Zbych <z...@o...pl> wrote:
>> Shadow registers can only be used with high priority interrupts -
> If low
>> priority interrupt uses shadow registers, then can be overwritten
> by
>> high priority interrupt
>> Czyli znowu zrobili to tak, żeby było upierdliwie.
>
> Priorytety w tak prostych mcu to tylko kwiatek do korzucha. Nigdy
> nie miałem powodu ich używania, a jeśli bym miał użyłbym 32 bitowego
> procka a nie bawiłbym się w furmanki na sterydach.

Ale w takim procku mialbys jeszcze wiecej rejestrow do zapamietania
:-)
Albo podobny zestaw shadow :-)


J.

do góry

Marek pisze:
[..]
> Moment, domyślnie przyjąłem, że mówisz o dużych tablicach we flash, bo
> jeśli ktoś chce używać duże tablice w ram na tak małym mcu, to
> przepraszam ale wybrał złe narządzie do realizacji swoich celów (co
> jest nagminne).

Dlaczego złe narzędzie? Jeśli mam w kości dostępny 1 czy 2kB to chcę
mieć swobodę jego użycia a nie ograniczenia.
Dostałem w prezencie szynę nowych PICów (16F877), ucieszyłem się
kombinując co ja z nich nie wystrugam, ale jak zacząłem się wgryzać w
temat to mi się odechciało po napisaniu może 1/10 kodu, wcześniej
robiłem na *51, teraz dostałem trochę atmeg, już widzę że to będzie to,
właśnie strugam do nich prymitywny programator.

--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

do góry

On Sun, 15 Nov 2015 13:11:29 +0000, AlexY <a...@i...pl> wrote:
> Dostałem w prezencie szynę nowych PICów (16F877), ucieszyłem się

Daj sobie spokój z 16F.

--
Marek

do góry

On Sun, 15 Nov 2015 13:40:18 +0100, "J.F."
<j...@p...onet.pl> wrote:
> Ale w takim procku mialbys jeszcze wiecej rejestrow do zapamietania
> :-)
> Albo podobny zestaw shadow :-)

Argument typu "a Porshe więcej pali".
Nic nie muszę pamiętać, to problem kompilatora.

--
Marek

do góry

On 15.11.2015 13:17, Marek wrote:
> On Sun, 15 Nov 2015 12:30:49 +0100, Zbych <z...@o...pl> wrote:
>> Sprzętowy stos przeszkadza w przełączaniu wątków.
>
> Bosh, jakie wątki, mówimy o prostej 8 bitowej architekturze.

Na tak, przecież przełączanie wątków można robić na minimum na
16-bitach, sorry zapomniałem. Dobrze, że w innych firmach o tej zasadzie
nie słyszeli.

>> 8-bitowy procek nie oznacza 8-bitowej przestrzeni adresowej. Skąd
> ten
>> pomysł?
>
> Wow, Atmega ma 16 bitowe rejestry ogólnego przeznaczenia (nie chodzi o
> rejestr PC)?

A co ma długość rejestrów do możliwości _liniowego_ adresowania?
8080 to potrafił, Z80 to potrafił, ale widać geniusze z microchipa na to
nie wpadli. Za to nie przeszkodziło im to opatentować mikrokontrolery,
które mają mniej nóżek niż bitów.

>> PICC-18 allows RAM objects of any size to be declared, though some
>> limitations exist that require balancing objects between C source
> files
>> in certain cases. C18 does not support RAM objects larger than 256
> bytes
>> by default; creating such objects requires editing linker control
> files
>> and adding pragmas to the C source which include hard-coded
> variable
>> addresses. These objects can only be accessed through pointers, not
>> directly.
>
> Moment, domyślnie przyjąłem, że mówisz o dużych tablicach we flash, bo
> jeśli ktoś chce używać duże tablice w ram na tak małym mcu, to
> przepraszam ale wybrał złe narządzie do realizacji swoich celów (co
> jest nagminne).

Czyli mam uC z 4kB RAMu na pokładzie i zrobienie w nim "wielkiej"
tablicy przekraczającej 256B to przegięcie? Dobrze się czujesz?

do góry

W dniu 2015-11-15 o 13:20, Marek pisze:
> On Sun, 15 Nov 2015 12:56:27 +0100, Zbych <z...@o...pl> wrote:
>> Shadow registers can only be used with high priority interrupts -
> If low
>> priority interrupt uses shadow registers, then can be overwritten
> by
>> high priority interrupt
>> Czyli znowu zrobili to tak, żeby było upierdliwie.
>
> Priorytety w tak prostych mcu to tylko kwiatek do korzucha. Nigdy nie
> miałem powodu ich używania, a jeśli bym miał użyłbym 32 bitowego procka
> a nie bawiłbym się w furmanki na sterydach.
>
Bez przesady, piorytety to jest właśnie to czego mi brakuje w avr-ach.
jak masz do obsłużenia więcej niż 2 przerwania to się przydają.

--
Pozdr

Janusz_K

do góry

Dnia Sun, 15 Nov 2015 14:19:36 +0100, Marek napisał(a):
> On Sun, 15 Nov 2015 13:40:18 +0100, "J.F."
> <j...@p...onet.pl> wrote:
>> Ale w takim procku mialbys jeszcze wiecej rejestrow do zapamietania
>> :-)
>> Albo podobny zestaw shadow :-)
>
> Argument typu "a Porshe więcej pali".
> Nic nie muszę pamiętać, to problem kompilatora.

I kompilator obsluzy Ci przerwanie szybko i bezpiecznie ...

J.

do góry