Mikrokontrolery ATMEL dla początkujących: Książki, zestawy i zasoby do automatyki domowej

Tue Mar 10, 2009 12:29 am   

Zbych pisze:

A po co mam zapamietywac jej stan? Skoro je blokuje to znaczy, ze
wczesniej musialo byc odblokowane, jesli z danego przerwania nie
korzystam to po co mialbym je blokowac? Taka potrzeba istnieje tylko
kiedy mam wiecej niz 1-poziomowa obsluge przerwan, zreszta to co
najwyzej 1 takt zegara.
Czasu odtworzenia nie musze liczyc, bo krytyczny jest moment do
odblokowania przerwan. Co sie dzieje potem w procedurze obslugi
przerwania dla innych przerwan jest bez znaczenia. Wiec tego nie licze.
A nawet liczac to porownaj czas RETI dla AVR i '51.


No ile? Nawet odblokowywujac kilka zrodel przerwan obsluga zajmie mniej
niz jednego dla '51.
Widze, ze sprytnie usunales moje info, ze na '51 to zajmuje 36-108 cykli
zegara!!! Dla kazdego przyjetego przerwania! W porownaniu do tego moje
nawet 12 cykli na przerwanie nic nie znaczy.


Programowo to tak samo skomplikowane jak zabawa z rejestrami, zeby
ustawic kontroler. Zreszta w ogole tego nie zauwazam, bo mi to zalatwia
klasa napisana w C++, ktora jest skladnikiem HAL w moim projekcie.
BTW, ten sam program po zmianie paru klas realizujacych abstrakcje od
sprzetu kompiluje na PC i o dziwo... dziala.


Jak mi sie zapetli? Jesli odblokuje przerwanie Rx lub Tx UARTa to
znaczy, ze chce je obsluzyc. Zostanie ono natychmiast zgloszone, a
procedura obslugi musi na poczatku je skasowac, albo poprzez
zablokowanie flagi, albo poprzez odebranie znaku. W czym problem? Nic mi
sie nie zapetli bo przerwania sa przy zgloszeniu blokowane.

Tue Mar 10, 2009 12:52 am   

Obwód zegara jest prawie identyczny tylko cyferki na obudowie inne....ale to
obojętne


z 51' to znam uPSD 10MIPsów z 40MHz....

ale też znam inny mały nowoczesny kontroler 90MIPS z kwarca 8MHz i co ty
na to? OK -
ten ma wewnątrz PLL i programem ustawiasz to co się podoba (ARM).

Powiedzmy więc że jeśli z 51 nie mogę wyciągnąć potrzebnej mocy to jej tam
nie wsadzę
a wsadzam inny kontroler i już załatwione - kto powiedział że muszę
ograniczać się tylko do jednego?
- a w zasadzie ostatnio to już ograniczyłem się tylko do jednego ale ani 51
ani AVR tylko do ARM - nawet
jak prawie nic nie robi .



NIE to nie tak, mi szybciej zadziała na 51 bo znam 51 a tobie na AVR bo
znasz AVR
a innej osobie to nawet jak rok nad nimi spędzi to i tak żaden nie zadziała
bo się na
kontrolerkach nie zna

Tue Mar 10, 2009 9:00 am   

Ale jak to wplywa np. na podlaczona zewnetrzna pamiec? Albo na zuzycie
energii?


To ciagle 3x mniej.


A znasz ARMa w obudowie SO08? Albo SO16? ARMa w wersji zuzywajacej
pojedyncze mikrowaty?


Nikt, tylko ze to bez sensu. Ponosisz koszty poznania dwoch rodzin,
jesli korzystasz z komercyjnych narzedzi to tez musisz za wszystko
placic 2x, dwie rozne elektroniki, przy komercyjnych narzedziach
praktycznie nieprzenoszalny kod, czyli piszesz wszystko 2x. Mozna i tak.


Owszem, tylko, ze ARMa wszedzie nie wsadzisz, chociazby dlatego, ze
najmniejsza wystepujaca obudowa jest TQFP64?


Oczywiscie znajomosc jest nie do przecenienia. Tylko, ze ja majac c/C++
z libc dla AVRa jestem w stanie napisac program szybciutko z minimalnym
tylko zaglebianiem sie do datasheeta. Co wiecej ten program latwo
przeniose np. na ARMa.
Pytanie czy dla '51 istnieje libc dla kazdego modelu '51? Pliki
naglowkowe chociazby tylko ze standardowymi definicjami rejestrow?

Tue Mar 10, 2009 10:04 am   

On Mon, 09 Mar 2009 20:15:58 +0100, T.M.F. wrote:

O ile pamietam to byly takie.


Nie, zrezygnowali z tego x12.

J.

Tue Mar 10, 2009 10:23 am   

T.M.F. pisze:


Bo przerwanie, które właśnie wpuściłeś w połowie obsługi innego
przerwania z powrotem ci tą flagę odblokuje.


A co mnie obchodzi 51? To jest jedyny procesor z priorytetami przerwań?


A co to ma do rzeczy jeśli chodzi o czas wykonania albo o konieczność
napisania tego?


Czytaj z uwagą. Pisałeś wcześniej, że możesz odblokować przerwania na
samym, początku. Trzeci raz ci piszę, że nie możesz, bo coś z tym uartem
musisz zrobić zanim odblokujesz przerwania.

Tue Mar 10, 2009 4:03 pm   

Znowu manipulujesz. Napisalem, ze przy jednopoziomowej obsludze jest to
niepotrzebne. Przy wielopoziomowej jest to konieczne, ale tez nie
wszystkie flagi, bo moge zastosowac np. dodatowa flage, ktora wskazuje
na koniecznosc zapisania i modyfikacji innych flag. Co wiecej niektore
AVRy maja do takich celow specjalny rejestr dostepny przez sbi/cbi. W
efekcie moj prolog do przerwania ulegnie nawet skroceniu.


A o jakiej rodzinie rozmawiamy? Bo mam wrazenie, ze '51 vs. AVR.


Napisac raz i zapomniec.


Skup sie. Podalem ci przyklad jak to zrealizowac gdzie odblokowanie
przerwania nastepuje dopiero w 5/6 instrukcji. Czyli szybciej niz '51
zdazy w ogole zauwazyc, ze przerwanie wystapilo.
I co musze zrobic z UARTem? Jesli odblokuje jego przerwanie to zostanie
ono zgloszone, skoro je odblokowalem to znaczy, ze jego priorytet jest
dla mnie wystarczajacy, zeby go przyjac. Jedyna roznica bedzie taka, ze
w samej procedurze obslugi przerwania UART (i tylko w tej) musze przed
odblokowaniem zlikwidowac przyczyne, czyli np. odebrac znak.


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

Tue Mar 10, 2009 7:33 pm   

T.M.F. pisze:

Przecież rozmawiamy o emulacji priorytetów przerwań, czyli z automatu
można założyć, że są sytuacje gdy jedne przerwania przerywają drugie, a
nawet trzecie. Zresztą problem nie pojawia się tylko wtedy gdy kilka
przerwań wchodzi na siebie. Czasem trzeba wyłączyć przerwanie na czas
rekonfiguracji peryferiów, czasem potrzebna jest sekcja krytyczna z
wyłączonym konkretnym przerwaniem (a nie wszystkimi). Zakładanie z góry,
że flaga przerwania jest zawsze ustawiona, to proszenie się o kłopoty.


Nie, próbowałeś udowodnić, że priorytety przerwań nie są potrzebne, bo
je sobie możesz wyrzeźbić w sofcie.


Czy ma to wpływ na czas wykonania przez procesor?


No nareszcie za którymś razem zrozumiałeś. Czyli jednak nie możesz
odblokować przerwań na samym początku, tak jak to wcześniej proponowałeś.

Tue Mar 10, 2009 8:10 pm   

To sa konkretne sytuacje, ktore nie musza zachodzic w projekcie. Ja np.
jeszcze nigdy nie potrzebowalem kontroli priorytetu przerwania. Zapewne
nawet jesli by taka potrzeba zaszla to jednopoziomowa moglaby mi
wystarczyc, najprawdopodobniej potrzebowalbym co najwyzej jedno
nadrzedne, nieblokowane przerwanie.


No i to udowodnilem. Czyzbys uwazal, ze nie moge ich sobie softwarowo
zrobic? Pytanie retoryczne, bo musialbys obalic uniwersalnosc maszyny
Turinga, Nobel gwarantowany.


A czy twierdzilem, ze nie ma? Narzekales jaki to straszny problem dodac
pare instrukcji assemblera.



Juz 5 postow wyzej pokazalem w przykladzie, ze odblokowywuje przerwania
dopiero w ktorejstam instrukcji. Jeszcze tego nie dostrzegles?
Dla przypomnienia - chodzi o to, ze tak zachwalales kontroler przerwan w
'51. Pokazalem, ze w czasie krotszym niz '51 jest w stanie zareagowac na
przerwanie moge sobie to zrobic jesli potrzebuje programowo. Czyli o
dowolnym stopniu uniwersalnosci. Wiec w czym '51 ma byc lepsze?

Tue Mar 10, 2009 8:42 pm   

T.M.F. pisze:


Pokaż mi posta w którym to zrobiłem.

Tue Mar 10, 2009 10:39 pm   

J.F. pisze:

obliczeniowa do 100 MIPS. Od maleństw do TQFP100:
https://www.silabs.com/products/mcu/mixed-signalmcu/Pages/C8051F12x3x.aspx

Pozdrawiam
--
Arek Świerc

Tue Mar 10, 2009 10:51 pm   

In the darkest hour on Mon, 9 Mar 2009 19:13:30 +0100,
Nimitz <Nimitz@onet.eu> screamed:

Tu odrobinę poniosła Cię fantazja. Skoro miał coś robić szybciej to
powinieneś liczyć to w realnej jednostce czasu.


--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:239B ]
[ 22:51:02 user up 12007 days, 10:46, 1 user, load average: 0.63, 0.04, 0.09 ]

You don't have to know how the computer works, just how to work the computer.

Thu Mar 12, 2009 12:19 am   

A ile dokładnie MIPsów potrzebujesz?



SO16 to bardzo duża powierzchnia obudowy choć mało nóżek, zamiast tego
zmieszczę bez problemu LFBGA 144piny, albo innym razem TFBGA 64pin
(5mm x 5mm) albo jak wolisz mało nóżek VFQFPN 36 pin (6mm x 6mm)



- 2-rodziny to ja już znam a nawet więcej,
- narzędzia nie są aż tak drogie,
- kod bez problemu przenoszalny, i nie piszę "2x"; ale swoją drogą to
ja nie powielam całe życie tego samego produktu w nowych odsłonach,
więc w zasadzie to piszę częściowo kod od nowa



patrz wyżej



Jak najbardziej na 51 jest C i też skompiluje się na ARM


z.

Thu Mar 12, 2009 7:21 pm   

zbyszek pisze:

Skad mam wiedziec ile bede potrzebowal w nastepnym projekcie?


Jasne, tylko, ze to juz nie na 2-warstwowy tani laminat. A jaki jest
sens isc w koszty jesl mozna to zrobic na 2- lub nawet 1-warstwowym
laminacie za grosze.


Ok, to teraz uzasadnij po co tak robic. Po co ponosic koszty na
poszikawania kogos kto zna dwie rodziny, koszty zdublowania sprzetu i w
sumie niemale koszty licencji na komercyjne oprogramowanie, skoro mozna
to zalatwic jednym procesorem. Nie mowie, ze nie mozna, po prostu sens
ma to niewielki.


Tylko uzasadnij mi prosze po co mam ladowac np. 36 nozkowy procesor i
inwestowac w drozsze wykonanie plytki jesli wystarczy mi cos w SO08?


A na PC? Na AVR32?

Ile bedziesz mial sekcji #ifdef __ARM__, albo #ifdef specific_compiler ?

Thu Mar 12, 2009 9:27 pm   

Skoro nie wiesz to bierzemy Intela C2D 3GHz - tak na zapas aby na pewno
starczyło


C2D nie posadzisz na 2-warstwach - zapomnij


Ale jak inaczej robić? Bo ja nie rozumiem, dobieram elektronikę do projektów
a nie
projekty do jedynego procesora który znam. Ja siebie nie muszę szukać . A
jeśl
zatrudnisz dwie osoby zajmujące się uP to i tak komercyjne to 2-licencje
kupisz -
chyba że na lewo robisz - ale wtedy to nie ma i tak problemu ...


Policz wszelkie koszty projektu - jeśli mała seria to cena elektroniki nie
gra
żadnej roli.
Skoro zajmujesz się tylko i wyłacznie jednym uP i to tylko w obudowie SO08
to masz problem - ja nie, dla mnie nie robi różnicy wsadzić raz pica albo 51
albo arm albo cokolwiek innego.




program
tak aby był bez #ifdef albo #define i np kompilował sie pod wszystkimi
kompilatorami C/C++ jakie istnieją i jeszcze z wszystkich platform na
wszystkie inne
platformy i systemy operacyjne itd - nie mam na to czasu.

Fri Mar 13, 2009 11:13 am   

zbyszek pisze:

Zastanawiam sie nad przyczyna tak idiotycznej odpowiedzi.
Niezrozumienie, czy glupota?


Glupota.


Owszem, dobiera sie elektronike do projektu. Ale rodzina AVR jest na
tyle bogata, ze pokrywa mi wiele roznych potrzeb. Ma sens poznac np. AVR
i ARM/AVR32, bo te rodziny istotnie sie roznia i sluza po prostu do
innych zastosowan. A jaki jest sens poznawac AVR/'51, skoro ta druga nie
ma zadnej przewagi nad AVR? Bezsensowne dublowanie.


Widze, ze nie rozumiesz. AVRy mam w kazdej mozliwej obudowie. ARMy nie.
Wiec ten sam rdzen moge wykorzystac w roznych projektach nie zmieniajac
ani narzedzi, ani softu. ARMy sluza po prostu do czegos innego, jesli
tego nie rozumiesz to trudno.


Znowu nie rozumiesz. Wlasnie wybierajac gcc wiem, ze program sie bez
problemu skompiluje na wszystkie platformy. Mam to gratis bez wysilku.
Wprowadzanie sekcji #ifdef/#endif tylko podraza koszty, bo musisz
program niezaleznie testowac z kazdym mozliwym warunkiem.

Na koncu pytanie kontrolne - jestes wlascicielem firmy, czy pracownikiem?