bestaande c code in avr studio4

Het probleem zou kunnen zitten in de sleep functie. Daar ben ik niet zeker van hoe de originele zou moeten werken.

In microcontroller.c de functie MCU_Sleep() zet // voor de volgende regels:

set_sleep_mode(SLEEP_MODE_IDLE);
sleep_mode();

Dan zal de code nog wel gewoon lopen maar misschien meer stroom gebruiken.

Anders zou je de sources even kunnen comparen met het origineel en kijken of er misschien nog andere verdachten zijn.

-edit-
Ik zie net dat ik ook een stomme fout gemaakt heb in eeprom.c

Ik heb de sei() en cli() functies omgedraaid.
Line 51 moet cli() zijn.
Line 58 moet sei() zijn.

Zie eventueel het attachment (met 20Mhz aanpassing er ook in, uiteraard niet de toolchain want ik weet niet waar die bij jou staat).

Maar zelf even aanpassen is sneller.

Hmmmn, helaas werkt hij nog niet. Heb ongeveer 15 verschillende opties erin gebrand zonder resultaat...... Lastig verhaal dit...

Programma draait denk ik totaal niet want aan pin 26 zit een controle led die iedere 1 seconde knippert (update clock, etc). Dat ledje knippert nu niet.

Ook de infrarood led D65 en IR leds voor data communicatie gloeien niet op (met een digitale camera gekeken en bij originele prog zie ik ze wel opgloeien).

De propeller gaat gewoon draaien maar dan zonder toeren regeling (vol gas). Wel krijgt de andere atmega op de propeller zijn spanning (controle ledjes gaan branden) dus dat betekent wel dat de clock loopt op het base programma ivm push pull over de trafo heen (pin 9 en 10)...

bijgaand het schema.

Heb je dat sleep.. stukje proberen weg te commenten?
(Zie vorige post)

Anders eerst eens een programmatje er in zetten dat alleen dat ene ledje op PC3 laat knipperen om te kijken of je fuse bitjes en al dat spul goed zijn.

Op 16 augustus 2015 14:13:41 schreef henri62:
Heb je dat sleep.. stukje proberen weg te commenten?
(Zie vorige post)

Anders eerst eens een programmatje er in zetten dat alleen dat ene ledje op PC3 laat knipperen om te kijken of je fuse bitjes en al dat spul goed zijn.

Ik heb inderdaad ook met het sleep gedeelte gespeeld maar helaas.
Ik heb de volgende code erin geschoten om dat ledje te laten knipperen en dat werkt perfect.


#include <avr/io.h>
#include <util/delay.h>

int
main (void)
{
    DDRC |= _BV(PC3); 
    
    while(1) 
    {
        PORTC ^= _BV(PC3);
        _delay_ms(500);
    }
}

Dit gedaan met dezelfde fuse instellingen als het originele programma. Hij gebruikt dus de externe 20 MHz crystal.

Raar dat je programma niet draait. Ik denk dat hij ergens hangt. Het rare is dus dat wel de draadloze energieoverdracht werkt (push pull naar de FET's werken) maar de communicatie niet....

Moet ergens in de ISR's zitten denk ik.

Wat ik wel zag is dat in alle ISR's een 'return' staat.
Misschien die er allemaal eens uit halen?
=> helpt niet denk ik, die returns kan ik in de assembly niet vinden, worden weg optimized.

Kan ook in de definitie van de IO pinnen zitten dat daar bij IAR ergens iets andere bits worden gebruikt. Misschien de edge detectie van hardware of zo?

[Bericht gewijzigd door henri62 op (11%)]

Hmn.... Zou dit nog te de-buggen zijn met de simulator van avr studio?
Of met een avr dragon?

Er zit niks anders op te debuggen, hier en daar het ledje aansturen en kijken hoe ver de code nog komt.

Op 16 augustus 2015 20:16:42 schreef henri62:
Er zit niks anders op te debuggen, hier en daar het ledje aansturen en kijken hoe ver de code nog komt.

bedoel je "er zit niks anders op dan te debuggen" of "er valt niets meer te debuggen" :-)

bij IAR ergens iets andere bits worden gebruikt. Misschien de edge detectie van hardware of zo?

Wat bedoel je daar precies mee?

- Kortom, je moet gaan debuggen waar het probleem zit.

- Het zou kunnen dat bij de IAR compiler definities anders zijn als bij de AVR-GCC compiler. Alhoewel ik niks aan de defines en code gewijzigd heb, dus de kans is niet zo groot dat het probleem is.
Maar je weet nooit of het helemaal goed is.

Het zou ook zomaar kunnen zijn dat ergens in het programma gewoon een bug zit en die er nu toevallig uit komt.

Kun je de code eens compileren met -O0? Ongeoptimaliseerd is die iets meer dan ca 12 KB, maar past er gewoon in.

VOILA Succes! Ik dacht dacht ik gisteren alle "-O" had geprobeerd maar wist het niet zeker. Hij builde met 0 errors en 0 warnings. De .hex erin geschoten en hij draait. Er zitten wel een berg bugs in hoe hij de tijd laat zien en het lopen van de seconden aan de rand van de propeller laat hij niet zien. Ook een veld laat hij niet goed zien en bij verschillende schermtypen zit er iets door het beeld van de vorige beeld instelling.
Maar ach, niets te klagen, van hier uit kan ik verder :-)

Het verschil tussen een niet en wel draaiende hex code is; 2 warnings; heel vreemd....


../base.c:40: warning: 'u8_styleNumberSaved' may be used uninitialized in this function
../base.c:38: warning: 'stateMachineMenu' may be used uninitialized in this function

Alleen bij -O0 geen warnings!

Henri echt super bedankt! Ik heb veel geleerd!

[Bericht gewijzigd door Henry S. op (27%)]

Bij -O0 worden meestal geen warnings displayed omdat de optimizer niets hoeft uit te zoeken.
Die warnings heb ik ook maar het hoeft niet altijd te zijn dat het ook een bug oplevert.
Deze lijkt wel een probleem: u8_styleNumberSaved, initialiseer die maar eens op 0 boven in.

Nu de code wel draait is het de vraag welke code/file precies verantwoordelijk is voor het probleem.

Je kunt in de project bij de custom options (waar ook de toolchain zit) per file de optimalisatie opgeven.

Probeer een voor een de files van -O1 t/m 3, elke keer een andere file tot je code het niet meer doet. Dan kun je je concentreren wat er in die file fout zit.

Als de bug gevonden is zou het zo kunnen zijn dat je de andere problemen ook vind/opgelost hebt.

Ja, dat is wel een goede om met de optimize functie per file te zoeken. Dat ga ik zeker even proberen.

Zou het ook kunnen zitten in een .h file of heeft dat er niet zo veel mee te maken?

[Bericht gewijzigd door Henry S. op (69%)]

Het kan ook daar zitten, via defines. Maar dat is dan een kwestie van elimineren. Je zou elke file apart van -O3 kunnen voorzien en dan kijken of er meer dan een file is die de zaak laat vastopen.

Dan is het in kwestie van die files goed nakijken wat daarin fout zou kunnen zijn.

Ben ook even nieuwsgierig geweest naar de IAR compiler en heb even gezocht op google daarnaar. Daar heb ik als hobby'ist niets te zoeken denk ik....
Beetje een wollige wereld en kon ook niet iets free downloaden qua compiler voor avr.
Anders was dat misschien de kortste weg geweest om een IAR compiler te installeren.

Klopt vrij aardig, de IAR compiler is commercieel en voor hobbyisten eigenlijk niet betaalbaar (ik geloof als ik zo hier en daar zoek meer dan 2000 euro).

Er is wel een free 30 dagen trial versie op iar.com. Je zou het kunnen proberen. Maar als er bugs in de code zitten (en dat is zo anders had het wel gewerkt) gaat je dat uiteindelijk ook niet helpen ben ik bang voor.

Eigenlijk te gek voor woorden dat Elektor een project publiceert waarbij voor de hobbyist onbetaalbare tools gebruikt worden. Als het nu netjes portable gemaakt was zou ik zeggen: prima, maar mooi niet dus. Zo is het vrij kansloos dat je het na bouwt en/of zelf wijzigingen kunt maken zonder grote inspanning.