bestaande c code in avr studio4

Zo ik ben lekker bezig geweest henri62

Ik heb inderdaad ISR(INT0_vect) gebruikt.
Als er bijvoorbeeld 2 interrupts in een c file zitten gebruik ik INT0 en INT1 (goed?)

bij de volgende c file met een interrupt weer met 0 "nul" beginnen (goed?)

Op gegeven moment wilt hij gaan builden en geeft 5 warnings. Zijn warnings erg of geeft hij dan nog steeds juiste code?

En hij geeft 1 error en wel deze;

e:/avr tools/avr toolchain/bin/../lib/gcc/avr/4.6.2/../../../../avr/bin/ld.exe: cannot find -lobjc
collect2: ld returned 1 exit status
make: *** [prop4.elf] Fout 1
Build failed with 1 errors and 5 warnings...

Heb al wat op ge-googled en zou iets te maken hebben met blocks en
"linken" maar kon er geen kaas van maken.
misschien -lobjc statement weghalen? maar hoe?

Wat te doen? We zijn dichtbij....

edit: heb wat zitten rommelen en die -lobjc error is weg echter gaat hij nu verder met het main programma te controleren (hij heeft dus alle andere c files gecontroleerd en OK bevonden denk ik?)

En komt nu met

E:\- Hobby\hobby\Propellor clock Elektor\atmel418_projects\prop4\default/../base.c:65: undefined reference to `__eint'
eeprom.o: In function `EE_WriteByte':
E:\- Hobby\hobby\Propellor clock Elektor\atmel418_projects\prop4\default/../eeprom.c:45: undefined reference to `__dint'
E:\- Hobby\hobby\Propellor clock Elektor\atmel418_projects\prop4\default/../eeprom.c:48: undefined reference to `__eint'
microcontroller.o: In function `MCU_Sleep':
microcontroller.c:(.text+0xf4): undefined reference to `__sleep'
collect2: ld returned 1 exit status
make: *** [prop4.elf] Fout 1
Build failed with 4 errors and 3 warnings...

begrijp dus ook niet echt in welke volgorde hij build

[Bericht gewijzigd door Hoihoi op donderdag 6 augustus 2015 21:01:53 (35%)

INT0 en INT1 zijn twee verschillende interrupt handlers die bij een specifiek deel van de hardware horen. Die kun je dus niet zomaar even veranderen.

libc is de C-library die de linker niet kan vinden.
Dit heeft waarschijnlijk wel met de GCC toolchain te maken.

Op zich is het helemaal niet moelijk om die even te installeren en die te gebruiken ipv. de avr toolchain. Ik ben bang dat je er niet onderuit komt.

Als het goed is heb ik ook hier op het forum eens een installatie voorschrift gepost moet dat moet. Effe zoeken...

-edit- Niet meer kunnen vinden hier op het forum, dan maar weer een copy/paste uit mijn archief:

Download AVR Studio 4, release 4.19 (build 730) and install it.
http://www.atmel.com/tools/studioarchive.aspx
http://www.atmel.com/forms/software-download.aspx?target=tcm:26-17924


Download "WinAVR":
http://sourceforge.net/projects/winavr/files/
(At time of writing "WinAVR-20100110-install.exe").
Install in: C:\WinAVR   NOTE: IS NOT THE DEFAULT!!!
The usermanual can be found in: C:\WinAVR\WinAVR-user-manual.html

Start: AVR Studio 4
In the menu:
	Project => Project Wizard
Button:
	New Project, select AVR GCC
	Choose a project name and folder
	Finish
Project:
	Configuration options, select correct CPU type.

Existing projects:
Open the project.

Project:
	Configuration options, custom options icon at the left.
	Disable Use AVR toolchain.
		External tools.
		avr-gcc: C:\WinAVR\bin\avr-gcc.exe
		make: C:\WinAVR\utils\bin\make.exe

Als er een van die tools al op staat hoef je die natuurlijk niet opnieuw te installeren. Let op installatie paden met spaties er in, ik dacht dat dat niet werkt.

Ja, het is zo ver; Ik heb de handdoek in de ring gegooid.

Ik heb tandjes veel code aangepast, toolchain aangepast, libraries toegevoegd, etc etc. Na uren klooien waren de hiervoor gaande foumeldingen weg en dan komt hij nu met een nieuwe waslijst aan errors (in wat voor volgorde hij nu build is me echt een raadsel).

AVR studio begint nu weer over andere declaraties enz, zoals;

../i2c.h:26:2: error: storage class specified for parameter 'tx_type'
../i2c.h:64:18: error: expected declaration specifiers or '...' before 'tx_type'
In file included from ../base.c:18:0:

Ben bang dat deze code op een linux systeem is geschreven met eigen of speciale libraries........geen idee. Maar mij lukt het niet.

Als iemand er zin in heeft er naar te kijken zal ik een zip file opsturen.

Op 9 augustus 2015 14:49:39 schreef Hoihoi:
Ben bang dat deze code op een linux systeem is geschreven met eigen of speciale libraries........geen idee. Maar mij lukt het niet.

Als je het host systeem bedoeld (waar de compiler dus op draait) dan is dat niet de reden.

Maar voor welke CPU is de code?
Hoeveel sourcefiles heb je?

Maar voor welke CPU is de code?
Hoeveel sourcefiles heb je?

Het is voor een Atmega 328p-au
Er zijn 9 source files en 13 header files.

Ik vind het zo raar dat c code dus gewoon niet zo standaard is. Het is erg afhankelijk van instellingen en libraries. Logisch misschien maar het verschil tussen IDE's vind ik raar. In de één geeft een declaratie of op een andere manier van schrijven van een interrupt een error en bij een andere IDE weer niet. Ik vind C dan niet echt een eenduidige taal.....

Mail die sources eens naar me toe (zie profiel), kijk ik er even naar of ik snel kan vinden wat de oorzaak is. Ik ben nu wel benieuwd waar die problemen vandaan komen.

Op 10 augustus 2015 18:14:36 schreef henri62:
Mail die sources eens naar me toe (zie profiel), kijk ik er even naar of ik snel kan vinden wat de oorzaak is. Ik ben nu wel benieuwd waar die problemen vandaan komen.

Dankjewel. Ik heb net de e-mail gestuurd.

De code is origineel voor de IAR compiler gemaakt, daarom compileert het voor geen meter met de avr-gcc compiler.

Ik heb de code van "base" aangepast zodat die op beide nu zou moeten compileren.

De meeste uitdagingen zitten dus in de declaraties van de ISR functies. Het includen van de juiste avr/io.h zoals al gezegd is.

Verder nog in de __sleep functie die anders is. En nog meer van die ongein.

De code bouwt nu onder avr-gcc met een handje vol warnings die er al in zaten.

Geen idee of de code die er nu uit komt ook echt werkt. De binairy code size is net iets meer dan 8000 bytes.

Zie de verbouwde zip file.

Er is nog een ander dingetje: Het opstarten via de *.aps file werkt om een of andere duistere reden niet.
Als je winavr opstart en je opent het project via de aps file, gaat het wel goed.

Ook even de frequentie van de CPU goed instellen en de AVR toolchain, die kan bij jouw anders zijn. (Project->Configuration options)

-edit- 2015-08-13
Ik heb de base.aps file gefixed zodat het project nu in een keer te openen is.
Plus nog een paar triviale warnings opgelost.
Dus een nieuwe zipfile attached.
Ook het project even gecleaned zodat de upload minimaal is.

-edit- 2015-08-15 code verwijderd, verderop staat de verbeterde versie!

Hallo Henri62,

Super bedankt dat je er even naar wilde kijken. Ik heb je code nog niet kunnen openen. Van het weekend ga ik er weer met frisse zin voor zitten want ik was nogal gedemotiveerd geraakt en heb even mn zinnen gezet op wat reparaties om mn hoofd van avrstudio af te krijgen ( je weet misschien hoe dat gaat als je ergens door gedemotiveerd bent geraakt..... Even wat anders doen). Ik laat je hier in dit topic wel weten wat de uitkomst is.
Nogmaals dank.

Hallo Henri,

De code werd juist "ge-build". Ik moest wel weer mn toolchain aanwijzen. Ik had de freq ingesteld bij "general" onder settings (20000000 Hz kristal). En toen vervolgens met avrdude de hex erin gebrand. Helaas geen draaiend programma...

De fuse settings zijn hetzelfde als bij de originele hex dus dat kan het niet zijn.

Ik ga nog even google'en wat al die andere soorten instellingen zijn bij general zie bijlage. zoals OS optimization en die 4 vinkjes aan de zijkant, geen idee wat ze doen. De 2 laatste plaatjes van avr dragon instellingen zijn van de maker zelf.

edit: zou het kunnen liggen aan de andere code die in de andere atmega zit? De base atmega doet namelijk via ir signalen communiceren naar de propeller atmega. En daar zit dan een net ander opgebouwde code in....

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 zondag 16 augustus 2015 16:57:58 (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 dinsdag 18 augustus 2015 17:23:29 (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 dinsdag 18 augustus 2015 17:23:45 (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.