/ Forside / Teknologi / Udvikling / C/C++ / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
C/C++
#NavnPoint
BertelBra.. 2425
pmbruun 695
Master_of.. 501
Bech_bb 500
kyllekylle 500
jdjespers.. 500
gibson 300
scootergr.. 300
molokyle 287
10  strarup 270
Programmeringsmode på AVR
Fra : Tomas .


Dato : 21-05-07 20:19

Hejsa

Jeg er ved at lave en konstruktion med en AVR-controller (ATMega8515).
Ved hjælp af 16 kontakter (sat op i 4x4 matrice) skal brugeren kunne
stille forskellige værdier, der skal gemmes i E2PROM'en til brug
senere.
Jeg har tænkt mig det sådan at man ved at holde tasten (PINC.3) nede i
5 sekunder, vil få programmet til at gå over i programmeringsmode,
hvor programmet forbliver, indtil man igen holder samme tast nede i 5
sekunder.
Når programmet så er i programmeringsmode, kan man gemme en værdi, på
en bestemt E2PROM adresse, ved at holde en specifik knap nede 2
sekunder (PIND.0 - PIND7 matricen). Gemningen skal så markeres ved at
blinke med den tilhørende LED (eks. 2 gange) (PORTA - Ligeledes 4x4
matrice).

Jeg kunne dog godt bruge lidt hjælp til at lave programmet, i C. Hvis
der er en, der vil hjælpe mig, vil jeg blive meget glad, da jeg stadig
er lidt grøn på området

--
Mvh.

Tomas


 
 
Ukendt (21-05-2007)
Kommentar
Fra : Ukendt


Dato : 21-05-07 21:11



> Når programmet så er i programmeringsmode, kan man gemme en værdi, på
> en bestemt E2PROM adresse, ved at holde en specifik knap nede 2
> sekunder (PIND.0 - PIND7 matricen). Gemningen skal så markeres ved at
> blinke med den tilhørende LED (eks. 2 gange) (PORTA - Ligeledes 4x4
> matrice).
>

Hmm, hvad skal det bruges til ?
Ligger hardwaren helt fast ? Umiddelbart lyder det som et trælst MMI (man
machine interface), hvis jeg må være så fri.

Men jeg vil da gerne hjælpe !

Har du compiler ?, ICE ?, og har du fået hul igennem , eksempelvis bare læse
værdien af en knap, og skrive den ud på en led ?

Designmæssigt synes jeg du skal lave et input-modul, der læser knapperne,
debouncer dem, holder rede på hvor langt tid de har været holdt nede, og til
sidst sender et event videre i "systemet".
"Systemet" vil så være din hovedapplikation, der selvfølgelig skal laves som
en statemaskine. Key eventet fra PINC.3 vil så trække din hovedstate frem og
tilbage mellem "state running" og "state programming". Kun i "state
programming" laver du transitionerne for de 16 key events.
Når du så skal blinke med en bestemt diode, kan du jo passende sende et
"flash event" til et led-modul. Dette modul skal så sørge for at tænde og
slukke dioden hvert 500 ms periodisk i x sekunder.

Alle disse moduler kan laves nogenlunde uafhængigt af de andre.
Hovedstatemaskinen vil kun kommunikere med knapper og leds via events.
Det gør at du kan tage .c filen og kompilere et lille gui på pc'en for at
lege med statemaskinen. (Dette er også kanon til at vise
kunder/chefer/sælgere/testere hvordan en kommende funktionalitet kommer til
at fungere)
Desuden vil du kunne bruge knap og led modulet i dit næste projekt.

Du _kan_ selvfølgelig også bare lave det hele i main() og klare al timing
med nogle flag hist og pist. Det er dog ret svært for os andre at fejlfinde
i, selvom vi nok vil gøre et ærligt forsøg.

Nu plabrer jeg vist løs igen.
Vend tilbage når du har noget.

tpt



Tomas . (21-05-2007)
Kommentar
Fra : Tomas .


Dato : 21-05-07 22:23

Hej Troels

>
>
>> Når programmet så er i
>>programmeringsmode, kan man gemme en værdi, på
>> en bestemt E2PROM adresse, ved at
>>holde en specifik knap nede 2
>> sekunder (PIND.0 - PIND7 matricen).
>>Gemningen skal så markeres ved at
>> blinke med den tilhørende LED (eks.
>>2 gange) (PORTA - Ligeledes 4x4
>> matrice).
>>
>
>Hmm, hvad skal det bruges til ?

Det skal bruges til bl.a. at styre en DC-motor, hvor der læses
pulser fra vha. en opto-switch. Værdierne, der skal kunne
programmeres, er værdier for forskellige positioner, som motoren
skal stoppe ud for. Disse skal, som sagt, kunne ændres af
brugeren, hvis han/hun ændrer på positionerne, fjerner eller
tilføjer nye. Dette gøres ved, at man i programmeringsmode
simpelthen aktiverer motoren ved at holde en knap nede, så kører
motoren den ene vej. Holdes en anden knap nede, kører den den
anden vej. På denne måde aktiveres motoren indtil slæden stopper
ud for den rette position. Herefter holder man den switch nede i
2 sekunder, der skal gælde for den indstillede position, og der
kviteres med 2 blink frå den respektive LED som kvittering for
fastlagt værdi i EEPROM'en. Så længe motoren kører, tælles ticks
fra optoswitchen, så man altid kender den aktuelle position for
slæden. Så er det jo bare at sammenligne værdier

>Ligger hardwaren helt fast ?
Ikke 100% - Da jeg også står for denne

>Umiddelbart lyder det som et trælst MMI (man
>machine interface), hvis jeg må være så fri.

Dog ikke. På det 16-knaps keypad vælges en bestemt hylde.
Motoren kører indtil den aktuelle værdi for hylden nås og
stopper så. Trykker man så på en ny knap, gentages processen.

En LED blinker så længe motoren er aktiv. Slukker denne, er den
ønskede position nået.

Hvorfor er den træls?
Der kommer max 16 positioner, så 1 tast pr. position er da
hurtigt og overskueligt at betjene.
>
>Men jeg vil da gerne hjælpe !

Lyder godt

>
>Har du compiler ?, ICE ?, og har du
>fået hul igennem , eksempelvis bare læse
>værdien af en knap, og skrive den ud på en led ?

Jeps, benytter CodeVision. Ja, der er hul igennem.

>
>Designmæssigt synes jeg du skal lave
>et input-modul, der læser knapperne,
>debouncer dem

debounce - læse og skrive værdien af læsningen på en anden port?
a'la
PINA = PORTB;

, holder rede på hvor
>langt tid de har været holdt nede,

How to?

og til
>sidst sender et event videre i "systemet".
>"Systemet" vil så være din
>hovedapplikation, der selvfølgelig
>skal laves som
>en statemaskine. Key eventet fra
>PINC.3 vil så trække din hovedstate frem og
>tilbage mellem "state running" og
>"state programming". Kun i "state
>programming" laver du transitionerne
>for de 16 key events.

Så stod jeg af. Har ikke prøvet at programmere en state machine
i C. I Verilog på et kursus for mange år siden, men det var jo
også i HW

>Når du så skal blinke med en bestemt
>diode, kan du jo passende sende et
>"flash event" til et led-modul.

Når du skriver modul, mener du så bare via et alm. funktionskald?

Dette
>modul skal så sørge for at tænde og
>slukke dioden hvert 500 ms periodisk i x sekunder.

Er vel bare en interruprutine med en timer?

>
>Alle disse moduler kan laves
>nogenlunde uafhængigt af de andre.
>Hovedstatemaskinen vil kun kommunikere
>med knapper og leds via events.
>Det gør at du kan tage .c filen og
>kompilere et lille gui på pc'en for at
>lege med statemaskinen. (Dette er også
>kanon til at vise
>kunder/chefer/sælgere/testere hvordan
>en kommende funktionalitet kommer til
>at fungere)

Lyder super - Jeg formoder, du så vil kommunikere med
controlleren via dens UART til pc'en, der så modtager pakker og
viser disse i GUI'en? Eller hvordan tænkte du det?

>Desuden vil du kunne bruge knap og led
>modulet i dit næste projekt.
>
>Du _kan_ selvfølgelig også bare lave
>det hele i main() og klare al timing
>med nogle flag hist og pist. Det er
>dog ret svært for os andre at fejlfinde
>i, selvom vi nok vil gøre et ærligt forsøg.

Enig. Det giver vist en ret stor mainfunktion og er ikke just
god C-kode


--
Mvh.

Tomas


Jakob Bøhm (22-05-2007)
Kommentar
Fra : Jakob Bøhm


Dato : 22-05-07 11:00

Tomas . wrote:
>> Designmæssigt synes jeg du skal lave
>> et input-modul, der læser knapperne,
>> debouncer dem
>
> debounce - læse og skrive værdien af læsningen på en anden port?
> a'la
> PINA = PORTB;
>

Debounce: At bortfiltrere den støj der kommer på signalet fra knappen
når den er ved at blive trykket ned / sluppet. Uden et debounce-filter
(i software eller hardware) vil knapperne opfører sig som om de hopper,
så et enkelt tryk forveksles med 1 til flere tryk hurtigt efter hinanden.

Problemet er så udbredt at der må findes standard biblioteksroutiner
eller samples til jobbet, specielt med noget så almindeligt som et 4x4
keypad.


> , holder rede på hvor
>> langt tid de har været holdt nede,
>
> How to?
>
Brug tællere som hænger sammen med dit generelle timerinterrupt (som
også laver ting for blinkende LED-er etc.). Du skal i forvejen bruge
noget af den logik i debounce-koden.

> og til
>> sidst sender et event videre i "systemet".
>> "Systemet" vil så være din
>> hovedapplikation, der selvfølgelig
>> skal laves som
>> en statemaskine. Key eventet fra
>> PINC.3 vil så trække din hovedstate frem og
>> tilbage mellem "state running" og
>> "state programming". Kun i "state
>> programming" laver du transitionerne
>> for de 16 key events.
>
> Så stod jeg af. Har ikke prøvet at programmere en state machine
> i C. I Verilog på et kursus for mange år siden, men det var jo
> også i HW
>

Der er mange måder, klassikeren er noget i stil med

typedef enum mystates_t {
State0, State1, Statefunny, Statethinking, Statetyping, ....
} mystates_t;


mystates_t state;

for (state = State0;;) {
switch (state) {
case State0:
.....
state = Statestgelse;
break;
case State1:
.....
state = Statestgelse;
break;
....
default:
OOPS! Can't happen, bug detected, panic, panic
}
}

>> Når du så skal blinke med en bestemt
>> diode, kan du jo passende sende et
>> "flash event" til et led-modul.
>
> Når du skriver modul, mener du så bare via et alm. funktionskald?
>
> Dette
>> modul skal så sørge for at tænde og
>> slukke dioden hvert 500 ms periodisk i x sekunder.
>
> Er vel bare en interruprutine med en timer?
>
>> Alle disse moduler kan laves
>> nogenlunde uafhængigt af de andre.
>> Hovedstatemaskinen vil kun kommunikere
>> med knapper og leds via events.
>> Det gør at du kan tage .c filen og
>> kompilere et lille gui på pc'en for at
>> lege med statemaskinen. (Dette er også
>> kanon til at vise
>> kunder/chefer/sælgere/testere hvordan
>> en kommende funktionalitet kommer til
>> at fungere)
>
> Lyder super - Jeg formoder, du så vil kommunikere med
> controlleren via dens UART til pc'en, der så modtager pakker og
> viser disse i GUI'en? Eller hvordan tænkte du det?
>

Næh, compiler den samme C kode med en PC C-compiler og kør helt uden
hardwaren (som du ikke behøver at have bygget endnu). Inputmodulet
erstattes af noget kode som tegner et tastatur på skærmen, Outputmodulet
af noget som tegner et billede at hvad maskine ville gøre.

>> Desuden vil du kunne bruge knap og led
>> modulet i dit næste projekt.
>>


--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right

Tomas . (23-05-2007)
Kommentar
Fra : Tomas .


Dato : 23-05-07 07:23

Jakob Bøhm <jb@danware.dk> skrev:
>Tomas . wrote:
>>> Designmæssigt synes jeg du skal lave
>>> et input-modul, der læser knapperne,
>>> debouncer dem
>>
>> debounce - læse og skrive værdien
>>af læsningen på en anden port?
>> a'la
>> PINA = PORTB;
>>
>
>Debounce: At bortfiltrere den støj
>der kommer på signalet fra knappen
>når den er ved at blive trykket ned
>/ sluppet. Uden et debounce-filter
>(i software eller hardware) vil
>knapperne opfører sig som om de hopper,
>så et enkelt tryk forveksles med 1
>til flere tryk hurtigt efter hinanden.
>
>Problemet er så udbredt at der må
>findes standard biblioteksroutiner
>eller samples til jobbet, specielt
>med noget så almindeligt som et 4x4
>keypad.

Nåå, det er bare kontaktprel, der menes. Det klares da vist
normalt bare ved at lægge et delay ind efter at et tastetryk
detekteres, så der kun fås een impuls.
>
>
>> , holder rede på hvor
>>> langt tid de har været holdt nede,
>>
>> How to?
>>
>Brug tællere som hænger sammen med
>dit generelle timerinterrupt (som
>også laver ting for blinkende LED-er
>etc.). Du skal i forvejen bruge
>noget af den logik i debounce-koden.
>
>> og til
>>> sidst sender et event videre i "systemet".
>>> "Systemet" vil så være din
>>> hovedapplikation, der selvfølgelig
>>> skal laves som
>>> en statemaskine. Key eventet fra
>>> PINC.3 vil så trække din
>>>hovedstate frem og
>>> tilbage mellem "state running" og
>>> "state programming". Kun i "state
>>> programming" laver du
>>>transitionerne
>>> for de 16 key events.
>>
>> Så stod jeg af. Har ikke prøvet at
>>programmere en state machine
>> i C. I Verilog på et kursus for
>>mange år siden, men det var jo
>> også i HW
>>
>
>Der er mange måder, klassikeren er
>noget i stil med
>
>typedef enum mystates_t {
> State0, State1, Statefunny,
>Statethinking, Statetyping, ....
>} mystates_t;
>
>
>mystates_t state;
>
>for (state = State0;;) {
> switch (state) {
> case State0:
> .....
> state = Statestgelse;
> break;
> case State1:
> .....
> state = Statestgelse;
> break;
> ....
> default:
> OOPS! Can't happen, bug
>detected, panic, panic
> }
>}


Det er da en mulighed.
>
>>> Når du så skal blinke med en bestemt
>>> diode, kan du jo passende sende et
>>> "flash event" til et led-modul.
>>
>> Når du skriver modul, mener du så
>>bare via et alm. funktionskald?
>>
>> Dette
>>> modul skal så sørge for at tænde og
>>> slukke dioden hvert 500 ms
>>>periodisk i x sekunder.
>>
>> Er vel bare en interruprutine med en timer?
>>
>>> Alle disse moduler kan laves
>>> nogenlunde uafhængigt af de andre.
>>> Hovedstatemaskinen vil kun kommunikere
>>> med knapper og leds via events.
>>> Det gør at du kan tage .c filen og
>>> kompilere et lille gui på pc'en for at
>>> lege med statemaskinen. (Dette er også
>>> kanon til at vise
>>> kunder/chefer/sælgere/testere hvordan
>>> en kommende funktionalitet kommer til
>>> at fungere)
>>
>> Lyder super - Jeg formoder, du så
>>vil kommunikere med
>> controlleren via dens UART til
>>pc'en, der så modtager pakker og
>> viser disse i GUI'en? Eller
>>hvordan tænkte du det?
>>
>
>Næh, compiler den samme C kode med
>en PC C-compiler og kør helt uden
>hardwaren (som du ikke behøver at
>have bygget endnu). Inputmodulet
>erstattes af noget kode som tegner
>et tastatur på skærmen,
>Outputmodulet
>af noget som tegner et billede at
>hvad maskine ville gøre.

OK. Det er selvfølgelig en mulighed at gøre det på denne måde.
Er selv HW-mand, så er ikke så vandt til at tænke i SW


--
Mvh.

Tomas


Søg
Reklame
Statistik
Spørgsmål : 177554
Tips : 31968
Nyheder : 719565
Indlæg : 6408857
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste