STK500 / ATmega32 - Interrupt

Mag ik vragen wat je beweegredenen zijn om een atmega in assembly te programmeren? (gewoon nieuwsgierigheid).

Op 9 april 2013 14:54:32 schreef pinky-t:
Mag ik vragen wat je beweegredenen zijn om een atmega in assembly te programmeren? (gewoon nieuwsgierigheid).

Daar kan ik je denk ik wel antwoord op geven:

a) Dan weet je precies wat je doet
b) Als je een C compiler gratis hebt zegt men dat die niet optimaliseert, dus trage werking laat zien.
c) Als ik op dit forum kijk zie je dat een te hoog abstactieniveau leidt tot totaal onbegrip en de status: Handen in het haar, vragen maar. Men is het verband kwijt tussen dataconstructies en de werkelijke realisering. (Hoe moet ik een array via een uart verzenden?)
d) Als zaken tijdkritisch zijn kun je de door een C compiler gemaakte assembly listing ter plekke optimaliseren, eerst assembly leren dus en als je ermee vertrouwd bent pas over naar een compiler.
e) ook met assembler kun je libraries gebruiken (zo gebeurt het ook trouwens via een compiler)
f) Het gros van de libraryfuncties is geoptimaliseerde assembly.

Dan de vraag van de TS

Als je een interrupt hebt zou die genest kunnen worden met een andere interrupt die je een hoge prioriteit gunt. Dat kun je bij AVR regelen met het I bit in SREG en dat kun je setten met sei en resetten met cli mnemonics.

Tijdens een interrupt staat het af. Wil je nesten moet je het zelf aanzetten in de interuptservice routine.

Bij het einde van de interrupt herstel je de gebruikte registers door die van de stack te poppen, daar hoort uiteraard het SREG bij zodat na de interrupt je I bit weer aanstaat, als het aanstond en dat stond het anders was hij de int niet gaan uitvoeren.

Na de interrupt voert hij minstens een instructie uit van het hoofdprogramma.

Dat betekent dus dat als je de boel wilt ophouden door te interrumperen op niveau (niet op flank) dat hij steeds opnieuw de interrupt ingaat mear elke keer weer een instructie uitvoert. Je hoofdprogramma gaat dus toch verder maar traag.

Je kunt het eventueel doen door in je interruptroutine de programmacounter op de stack te verlagen, maar dat raad ik af.

Je moet het dus anders aanpakken. De pen die je bedient moet je pollen, en dat pollen herhaal je na elke uitwendig merkbare stap van het programma.

edit: Je zou je externe interrupt op laag niveau kunnen zetten, en in de inteeruptafhandeling een poll routine zetten die blijft hangen zolang de interruptpen laag is en daarna pas de interrupt verlaat. Moeilijkheid is bounce van mechanische schakelaar.
Allemaal oplosbaar.

Je programma verder niet bekeken dan oppervlakkig, ziet er nogal chaotisch uit. Bijvoorbeeld:

 
      rjmp led_loop
      led_loop: 

Je programma moet op 0 beginnen met een jump list die bevat namelijk de vectoren waarnaar wordt toegesprongen bij de diverse soorten interrupts. Ik kijk er verder niet naar.

Wat er in ieder geval, lijkt mij, fout is, is dat in de onderste interruptafhandelingsroutine er meer pops dan pushes staan, en dat de reti nooit bereikt wordt omdat er naar loop: die blijkbaar een soort nulproces is en als hoofdprogramma functioneert, wordt gesprongen.

[Bericht gewijzigd door Henry S. op vrijdag 12 april 2013 19:12:10 (5%)]

Op 9 april 2013 21:13:58 schreef Druiloor:
b) Als je een C compiler gratis hebt zegt men dat die niet optimaliseert, dus trage werking laat zien.

Onzin. Je heb je zeker laten indoctrineren door MicroChip? Ook veel van de rest van je argumenten zijn niet valide. Gewoon in C programmeren. En als je begrip van de assembly wil kweken de uitvoer van de compiler zo nu en dan bekijken.

Onzin. Je heb je zeker laten indoctrineren door MicroChip? Ook veel van de rest van je argumenten zijn niet valide.

Jammer,

Ik zie dat U geen argumenten aandraagt om uw stelling "Onzin" te onderbouwen en dat u tevens niet het inzicht toont bij de verwoording van uw gedachtengoed, dat "veel van de rest" taalkundig enkelvoud is, hetgeen een indicatie is betreffende de kwaliteit van de semantiek van uw overige opmerkingen.

Onder indoctrineren versta ik het manipulatief overbrengen van gedachten met uitschakeling van een kritisch filter dat afgestemd is op de eigen persoonlijkheid van de gemanipuleerde persoon.

Als u mij conform deze definitie denkt te kunnen toespreken vergist u zich schromelijk.

Heb je echt argumenten nodig om te onderbouwen dat het onzin is dat de gratis avr-gcc niet kan optimaliseren? Leg eens uit wat -Os doet die AVR Studio standaard meegeeft?

Druiloor, ik vroeg naar de beweeg redenen van de topic starter, niet naar jou gedachten goed over dit punt.

Daarnaast is het trouwens ook maar uit de lucht gegrepen dat c taal veel al verwarrende situaties op leveren en dat het een hoog abstractie niveau heeft. Je kan het namelijk in C zelf zo abstract maken als je het zelf wil, Als jij in c geen pointers en dergelijke gebruikt is het redelijk "straight forward", daarbij, waarom dacht je dat bijna de hele wereld c gerelateerde talen gebruikt? Waarschijnlijk niet omdat het abstractie niveau te hoog is. Ik bedoel te zeggen, eigen ervaringen zijn niet altijd een feit. Ook vind ik het vreemd dat je iemand zijn post "afkraakt" op zijn taalgebruik en daardoor de informatie afdoet als zijnde "onzin". Niet iedereen kan hoogleraar of drs in de Nederlandse taal zijn.

Dan wil ik nog even quoten dat je zelf ook maar gist, en niet basseerd op feiten:

Quote van Druiloor: "Als je een C compiler gratis hebt zegt men dat die niet optimaliseert"

Vooral het "zegt men" getuigd echt van een betrouwbare bron. Niet dus, bijna alle gratis compilers hebben een optimaliseer optie. De restrictie zit hem bij gratis compilers veel al in het aantal KB's wat je kan code'n bijvoorbeeld 2kb of 4kb. Dit gezegd hebbende zijn er altijd nog gratis alternatieven die wel alle mogelijkheden gratis beschikbaar stellen, neem hiervoor bijvoorbeeld eclipse in combinatie met een atmel compiler. Het is wat meer instel werk, maar het doet zeker niet onder aan alle andere compiler omgevingen. Daarnaast is het een stuk beter leesbaar dan assembler.

Wat ik wil zeggen met mijn post is:
Geef de topic starter eens de ruimte om te antwoorden, in plaats van anderen af te schieten en je eigen mening te posten waar op dat moment niet om gevraagd wordt.

Op 10 april 2013 08:38:40 schreef rew:
[...]En als je begrip van de assembly wil kweken de uitvoer van de compiler zo nu en dan bekijken.

Daar ben ik het niet mee eens, je kan er nog zo vaak naar kijken, maar daardoor krijg je het echt niet in de vingers. Net zoals met bijvoorbeeld lassen of iets dergelijks.

Uiteindelijk ga je uiteraard wel in een of ander programmeer taal programmeren, omdat dat je dan veel meer functionaliteit in kortere tijd kunt implementeren.

Op 11 april 2013 11:29:09 schreef shizzle dizzle:
[...]
Daar ben ik het niet mee eens, je kan er nog zo vaak naar kijken, maar daardoor krijg je het echt niet in de vingers. Net zoals met bijvoorbeeld lassen of iets dergelijks.

Uiteindelijk ga je uiteraard wel in een of ander programmeer taal programmeren, omdat dat je dan veel meer functionaliteit in kortere tijd kunt implementeren.

Daar ben ik het volledig mee eens. Het is als met het gebruik van een conversatietaal. Duits of Frans, je kunt het wel passief gebruiken, door te begrijpen wat er gezegd wordt, maar dat wil nog niet zeggen dat je er zelf foutarm op spreeksnelheid in kunt formuleren, als je dat niet langdurig eerder geoefend hebt.

Ter zake betekent dat dus, dat je wellicht wel naar assembler als output van een compiler kunt kijken en die begrijpen, maar dat dat zeker niet wil zeggen dat je de knulligheid van het product kunt herkennen en dat aanzienlijk kunt verbeteren.

Dat zal zeker lang niet altijd nodig zijn, maar als het nodig is dan wreekt zich het gebrek aan vaardigheden, dat ontstaan is door niet actief in assembler met het onderhavige product te programmeren.

Met VHDL als gebruikt voor FPGA's is het abstractieniveau nog verder verhoogd en zie je derhalve op dit forum af en toe vragen, waaruit blijkt dat men de taal syntactisch en semantisch juist toepast, maar dat dat toch niet tot een werkend product leidt, zoals bedoeld. Het contact met de onderliggende hardware-structuur is dan nog verder verloren gegaan.

@ andere bijdragers: "Onzin" is niet een citaat uit mijn toetsenbord, maar dat van Rew, ik acht het bij een discussieforum ongewenst dat men elkaars argumentatie a bout portant ongenuanceerd en zonder enige steekhoudende argumentatie aldus kwalificeert. Dat bevordert namelijk de onderlinge uitwisseling van argumenten bepaaldelijk niet.

Citaat van pinky-t:

Progger jij hebt volledig gelijk. Ik moet echt leren lezen

Is nog niet gelukt, merk ik.

Beweegredenen voor het doen in assembly is een verplichte eis van de hoge heren bij ons op school. Zeer irritant, vooral omdat C net zo goed draait, beter aan sluit op het vorige thema, en korter is. Maar goed, roeien met de riemen die je hebt.

Leuke discussie hier, maar nog geen helder antwoord. Ik hoef niet zo zeer code te zien, maar wat is de theorie er achter?

Een falling edge interrupt maken is één ding, maar je kunt toch geen twee opties aan één interrupt toe wijzen? Een toggle heb ik gemaakt, dus één keer indrukken pauze, nog een keer verder en repeat.

Als je beter formuleert begrijp ik misschien wat je bedoelt. Nu zijn er zoveel interpretaties mogelijk, en je code is zo'n onduidelijke puinhoop dat ik niet begrijp wat je wilt.

In ieder geval kun je met een interruptafhandeling veel doen, meer dan een ding.

Wil je het niet allemaal tegelijk, om de afhandeling kort te houden, en hoeft dat ook niet allemaal direct achterelkaar, dan verdient het aanbeveling de interrupttimer (als het een timer int is) 4 keer zo snel te laten lopen. als eerste ding in de afhandeling een counter te verhogen die immediate te anden met 3, zodat je een 4 positieteller hebt, en dan afhankelijk van de stand van die teller een van je vier taken te doen die allemaal op een kwart van de snelheid van de int om de beurt afgehandeld moeten worden.

Als je niet alles zelf wilt uitvinden, zoals het wiel, dan geef ik ter overweging om van de onderhavige processor wat listings te bestuderen die door de fabrikant in application notes of zoiets verspreid worden. En dan niet globaal, maar nauwkeurig, aandachtig en precies, mede door te kijken wat elke gebruikte instructie precies doet en wat die voor invloed heeft op de bits van het processor statusregister.

Kun je misschien op een ander forum de pedante jongen uithangen, druiloor?

Nou heb ik de startpost een paar keer gelezen, maar ik snap nog steeds niet wat het ding nou moet gaan doen en wat de relatie met een interrupt is...

Ik krijg de indruk dat de TS iets als een 'PAUSE' ofzo wil implementeren met een interrupt handler. Nou ja, alles kan natuurlijk... Maar daar zijn die dingen dus duidelijk niet voor bedoeld...

Op 12 april 2013 23:12:38 schreef alex278:
Kun je misschien op een ander forum de pedante jongen uithangen, druiloor?

Zeker,
ik ben al weg.

Wat een offtopic discussie weer. Druiloor, hou eens op met dat ge-"u". Dat klinkt enorm uit de hoogte en je ziet wat daar van komt.

TS, is het ook een eis dat je dit met een interrupt oplost? Ik vind het nl. verre van een mooie oplossing. Een interrupt gebruik je voornamelijk als je een lopend proces op een exact moment wilt onderbreken, bv als er een byte via de UART binnen komt, of als een knop op je keyboard wordt ingedrukt, of omdat er een 10 ms voorbij is.
Als je "m vasthoudt" (moet dat hier? ), dan kun je die status gewoon via een input uitlezen in je main loop en dan iets anders gaan doen, niet meer knipperen vd LEDs of zo. Wat je wilt. Als dat een paar ms langer duurt, dan ziet niemand dat. Lang in een ISR blijven hangen is niet fraai.