ATTINY84V programmeren.

Open het project via de .atsln file. Middenboven zie je een selectieveld dat op "debug" staat, zet deze op "release". Doe dan nog eens een build.

Hij beweert dat "__vector2_" en nog 1 dubbel gedefinieerd zijn. Je hebt de broncode, dus je kan kijken hoe dat komt. En hij vertelt de regelnummers er bij: 


   main.c(296,1
   lib_pcint.c:107

Waarschijnlijk worden die twee interrupt routines GEBRUIKT maar heeft de lib dus een "standaard definitie" die weg moet vallen als je ze daadwerkelijk gebruikt. Daar zijn diverse truuks voor.

De huidige "kom tot een snelle oplossing" zal zijn om ze gewoon uit pcint.c te halen of "uit te zetten" 

#if 0 
void __vector2_ (void)
{
...
}
#endif

Op dinsdag 2 april 2024 06:07:29 schreef PE9SMS:
Open het project via de .atsln file. Middenboven zie je een selectieveld dat op "debug" staat, zet deze op "release". Doe dan nog eens een build.

Super, dat werkt!!
Laat ik nou de map die daar stond gekopieerd hebben en die .atsln file niet...
Die laadt overigens hetzelfde als de .cproj file, ik was al blij dat ik zelf iets werkends had gevonden.

Maar nou heb je deze aap een kunstje geleerd (waarvoor dank), maar hij snapt nog nauwelijks wat hij doet...
Ik wil nou zelf iets in de code aanpassen (7-segments aansturing) en vond al vrij snel onderstaande in de main.c:

Original:

static SEVEN_SEGMENT_MAP map =
{
	0, // A
	1, // B
	3, // C
	4, // D
	5, // E
	7, // F
	6, // G
	2, // DP
};

Adapted:

static SEVEN_SEGMENT_MAP map =
{
	3, // A
	4, // B
	5, // C
	6, // D
	1, // E
	2, // F
	7, // G
	0, // DP
};

Dat heb ik met kladblok in de betreffende file gewijzigd en dan gaat opnieuw compileren gelukkig ook nog goed.
Of dat ook echt werkt ga ik zien als de hardware klaar is. :-)

Dank voor alle hulp!

Kladblok? Daar heb je juist zo'n handige IDE voor. In je screenshot hier boven zie je rechts de Solution Explorer. Klik daar het mapje source open en klik dan op een c of h file om die te editten.

Als ik dubbelklik op rob040_fMainsDisplay.cproj dan kwam dat standaard in beeld.
Dubbelklik ik op rob040_fMainsDisplay.atsln, dan was het niet zichtbaar.

Maar inmiddels het knoppie gevonden en ook hoe ik de wijzigingen dan kan opslaan.
Wel zo makkelijk inderdaad. :-)

Nog een aanvullende vraag...
Op een gegeven moment is de waarde 200 toegevoegd voor DMEMORY_POOL_BYTES.
Dat is nattevingerwerk, dus het kan zijn dat die waarde nog aangepast moet worden.
Die stond in de makefile, maar die is niet terug te vinden in de ATMEL studio 7 files van PE9SMS.
Hoe en waar kan ik met die DMEMORY_POOL_BYTES waarde spelen als het nodig is?

memory pool is het geheugen wat je dynamisch kan alloceren en de-alloceren als je het (even) nodig hebt.

Op een Atmel ATMEGA328 zou ik dat "liever niet" doen. Je hebt maar 2k, dus als daar 1.5k van over is na "de rest", dan kan je maximaal 500 bytes voor die memory pool gebruiken en dat zou dan HEEL snel op zijn. Beter even zelf over nadenken wat je wel en niet tegelijk nodig hebt en zo.

Op een RP2040, daar heb je 264k geheugen, dat is een andere zaak. Dan kan je zomaar 220k over hebben na "de rest" en dan is er voldoende marge dat het niet "onverwacht op" is en dat soort dingen.

Ik zou er voorlopig afblijven. Iemand heeft er over nagedacht of de default laten staan en dat werkte.

Op woensdag 3 april 2024 14:50:34 schreef rew:
Ik zou er voorlopig afblijven. Iemand heeft er over nagedacht of de default laten staan en dat werkte.

Oorspronkelijk was er geen waarde ingevuld. Toen ik bij het compileren een error kreeg heeft deKees voorgesteld om waarde 200 te gebruiken:

Ik zet de waarde hier op 200. Geen idee of dat in de buurt komt van wat er nodig is. Maar het lijkt erop dat het hier gaat om een memory management module die een soort van free-space memory beheert. En dan is 200 bytes wel weinig, maar een Tiny84 heeft niet meer dan 512 totaal beschikbaar.

Kan zijn dat er nu door PE9SMS ook geen waarde staat, maar dat vind ik niet terug.

Functies uit memorypool.c worden niet gebruikt in dit project. Deze file had dus ook niet vanuit de makefile gecompileerd hoeven worden.

Op woensdag 3 april 2024 17:17:19 schreef PE9SMS:
Functies uit memorypool.c worden niet gebruikt in dit project. Deze file had dus ook niet vanuit de makefile gecompileerd hoeven worden.

Neem aan dat de code optimization m dan ook er uit laat met linken ?

Ja, daar is een gcc optie voor. Ik ken 'm niet uit m'n hoofd maar staat volgens mij standaard aan in Studio 7.

edit:
zie hier linkje

[Bericht gewijzigd door PE9SMS op (38%)]

Op woensdag 3 april 2024 17:17:19 schreef PE9SMS:
Functies uit memorypool.c worden niet gebruikt in dit project. Deze file had dus ook niet vanuit de makefile gecompileerd hoeven worden.

Ah, dat is mooi. Dan kan dat ook geen probleem geven. :-)

Misschien, maar dan moet je ook de #include <ringbuf.h> uit alle sourcefiles weghalen.

Op woensdag 3 april 2024 18:07:54 schreef deKees:
Misschien, maar dan moet je ook de #include <ringbuf.h> uit alle sourcefiles weghalen.

Ik kom #include <ringbuf.h> nog wel tegen in diverse sourcefiles.
Wat is de relatie met memorypool en waarom zou je ze weghalen?

Ik kan me vergissen. Dat was een andere fout misschien.

Bij dit soort dingen: Effe die mempool uit de makefile halen kijken of het nog compileert. Zelfde geldt voor ringbuf. Is veel handiger om het echt te weten of het gebruikt wordt dan dat wij hier daarover gaan zitten filosoferen.

Voor mij is het nu het makkelijkste om het eerst gewoon te proberen in de schakeling.
Ik kan nu zelf compileren en de code wat aanpassen in Microchip Studio 7, maar ik ben de relatie kwijt tussen de makefile die de ontwerper gemaakt heeft en de files van PE9SMS voor/in MS7.

Er is geen relatie. Ze hebben wel het zelfde doel: gemakkelijk het project te kunnen bouwen zodat je een elf/hex maakt. Met make/makefile op de command line. Of in een GUI / IDE zoals MS7. En "toevallig" maakt MS7 ook een makefile om gcc mee aan te roepen. Dat had je zelf al ontdekt.

Ah, duidelijk. Dan nog een controlevraag om te zien of ik het helemaal begrijp: Had jij de elf/hex file met SM7 kunnen maken als de makefile van James er niet bij zat?
Ik verwacht dat je die makefile gelezen hebt en daarmee het project gebouwd hebt in SM7. Dan is dat de relatie voor mij, de file wordt verder in SM7 niet gebruikt. Heb ik het bij het rechte eind? ;-)

Op woensdag 3 april 2024 22:18:04 schreef rob040:
Ah, duidelijk. Dan nog een controlevraag om te zien of ik het helemaal begrijp: Had jij de elf/hex file met SM7 kunnen maken als de makefile van James er niet bij zat?

Ja. Ik heb in main.c gekeken wat er geinclude wordt en die files heb ik van github gehaald. Dat bleek voldoende. Vandaar ook dat er geen memorypool.c/.h in het MS7 project zit.

Ik verwacht dat je die makefile gelezen hebt en daarmee het project gebouwd hebt in SM7.

Niet voor de c/h files, alleen (een paar?) compiler settings overgenomen uit de makefile, -O3 in elk geval.

Dan is dat de relatie voor mij, de file wordt verder in SM7 niet gebruikt. Heb ik het bij het rechte eind? ;-)

Correct.

Op woensdag 3 april 2024 22:35:30 schreef PE9SMS:
[...]Ja. Ik heb in main.c gekeken wat er geinclude wordt en die files heb ik van github gehaald. Dat bleek voldoende.

O, dat is niet wat ik verwacht had. Dacht dat die makefile essentieel zou zijn. Ik blijf het knap vinden dat het je gelukt is. :-)

Alleen de c/h files (en de toolchain) zijn echt essentieel. De makefile is een hulpmiddel (script) om het compilen makkelijk/handig te maken. Anders moet je zelf voor iedere C file de compiler aanroepen. En dan nog een keer voor het linken. Je zou het zelfde kunnen bereiken met een bash script (linux) of batch file (windows). Maar bij C is make nou eenmaal gebruikelijk, historisch zo ontstaan.

https://en.m.wikipedia.org/wiki/Make_(software)

@PE9SMS: Als ik een project zonder makefile moet doen, dan zou ik 

gcc abc.c def.c ghi.z lib.c -o project

doen. Dus niet meer apart de .o files maken, maar direct door naar linken en output genereren. Tenzij je project echt heel groot is, is een moderne computer zo snel dat dit ook nog wel te harden is omdat JIJ minder hoeft te typen.

In de praktijk maak ik vanaf ongeveer 1 C-file al een makefile aan. Al is het alleen maar: 

CC=gcc
CFLAGS=-Wall -O2 

all: myproject

Oja, kan ook. Ik werk nagenoeg altijd in een IDE die de gcc opties voor me regelt.