ATTINY84V programmeren.

Op zaterdag 30 maart 2024 15:54:28 schreef rob040:
Dank weer voor de uitleg.
De ringbuf.c is inderdaad in de hele library niet terug te vinden.
Alleen ringbuf.cpp en ringbuf.h.
Kan ik de ringbuf.c 'maken' uit of met behulp van één van bovenstaande files?

Het renamen van ringbuf.cpp naar ringbuf.c werkt niet (dat was te makkelijk).

Hm... .C is een "C-programma", .CPP is C++, ik weet niet of de compiler die zo standaard pakt. Ik weet wel dat visual studio code wel .CPP aanmaakt.

cpp extensie is voor C++ broncode.

Normaliter is er ook een regel hoe "make" voor jou van een cpp file een .o file kan maken ("roep de c++ compiler aan!")

Omdat de avr-gcc ook cpp kan compileren en volgens mij automatisch in C++ mode gaat je hem aanroept als g++ ipv gcc, zou het copieren en aanpassen van de regel voor C moeten helpen. Ik weet niet of die in jou makefile staat of dat je de standaard "rule" gebruikt.

abra2:~/test> touch test.cpp
abra2:~/test> make test.o
g++    -c -o test.o test.cpp
abra2:~/test> 

Op mijn systeem heb ik een cpp bestand aangemaakt met niets, maar dan ook helemaal niets er in en dan make gevraagd om de corresponderende .o te maken. Dan roept ie de g++ compiler aan.

En als ik een makefile aanmaak met:

CC=avr-gcc
CXX=avr-g++

Dan gebruikt ie avr-g++ ipv g++. Ik heb nu dus een avr test.o met daarin c++ gecompileerd... niets.

test.o: ELF 32-bit LSB relocatable, Atmel AVR 8-bit, version 1 (SYSV), not stripped

Edit: Even naar je makefile gekeken. Er is een regel CC=....
Als je die copieer en dan CXX= van maakt en van gcc op het eind door g++ vervangt, dan heb je make vertelt hoe de C++ compiler heet.

Hmm. Jou make schijnt geen regel voor cpp te hebben.

In de documentatie vond ik:
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c
als regel, en volgens mij moet de regel dan compleet:

%.o: %.cpp
       $(CXX) $(CPPFLAGS) $(CXXFLAGS) -c

Let op: Make is een HEEL oud programma (ongeveer 50 jaar), dus heeft soms wat "rare" dingetjes: die lege ruimte voor de $(CXX) MOET een tab zijn.

[Bericht gewijzigd door rew op zaterdag 30 maart 2024 16:31:22 (23%)]

Ja, ringbuf.cpp gebruikt templates dus dat is duidelijk C++.

Je kunt de file hernoemen naar ringbuf.c, want dan wordt hij weer wel herkend door de makefile.

En vervolgens kun je de compiler vragen om alles als C++ te behandelen dmv een extra compiler optie:

 -x c++ 

Misschien werkt dat, misschien ook niet.

Je kunt ook proberen om ringbuf.c uit de CFILES lijst te halen. Misschien is die niet nodig voor dit project.

En anders moet je op zoek naar een oudere versie van die library die nog de c versie van ringbuf gebruikt.

PS1: de methode van rew kan ook. Mogelijkheden genoeg. Maar het is nog maar de vraag of je hier C en C++ binnen dit project kan mixen. Meestal geeft dat weer andere problemen.

PS2:
ringbuf.cpp gebruikt templates. En die zijn gedefinieerd in ringbuf.h. Dus elke module met "#include <ringbuf.h>" moet als C++ worden gecompileerd.

Uit nieuwsgierigheid heb ik de netfrekwentie gemeten met een frequentieteller die ook de periodetijd kan meten tot op de µS.
Na een uur opwarmen en meten schommelde de periodetijd tussen 19,998 mS en 20,003 mS wat mij doet vermoeden dat meting met een controller de afwijking eerder zal toenemen.

Waarom zou de afwijking toenemen? Als je het goed doet, maar de input capture hardware en een goed circuit ervoor, is de resolutie beperkt door de clockfrequentie, en de nauwkeurigheid door de clock source. Als je het echt goed wilt doen, gebruik je een externe tijdreferentie, zoals de 1PPS van een GPS ontvanger of zo. Een resolutie in de orde van een tiental ns is dat vrij triviaal, en de nauwkeurigheid hoeft niet veel slechter te zijn.

Als ik de meter werkend krijg dan wil ik hem hiermee vergelijken:

https://www.mainsfrequency.com/

Ben van alles aan het proberen, maar nog geen succes. Ik moet even goed in de gaten houden wat ik wijzig, wat het doet en hoe ik weer terug kan.

Heb me vandaag aangemeld, las dit draadje al eerder. Wil mijn reactie hier nog toevoegen:
Ik zou het programma PonyProg gebruiken en de .hex file in de attiny programmeren.

[Bericht gewijzigd door Klompendanser2 op zaterdag 30 maart 2024 21:38:16 (36%)]

Welkom op het forum!
Welk device moet ik dan kiezen, want de Attiny84 staat er niet bij...
Het programmeren zal het probleem niet zijn, dat moet met XGpro en mijn TL866II ook kunnen en XGpro kent em wel.
Maar zover ben ik nog niet...

Op zaterdag 30 maart 2024 22:02:49 schreef rob040:
Welkom op het forum!
Welk device moet ik dan kiezen, want de Attiny84 staat er niet bij...
Het programmeren zal het probleem niet zijn, dat moet met XGpro en mijn TL866II ook kunnen en XGpro kent em wel.
Maar zover ben ik nog niet...

Het standaard atwoord is meestal RTFM (read the freaking manual).

je zou zonder lezen dit kunnen proberen.
Device programming -> AVR micro -> Attiny85

Ik raad aan om in het datasheet van de controller te kijken tot welke famillie of groep de 84 behoort, zou zomaar de 85 kunnen zijn als 8x.

Op zaterdag 30 maart 2024 20:04:50 schreef SparkyGSX:
Waarom zou de afwijking toenemen? Als je het goed doet, maar de input capture hardware en een goed circuit ervoor, is de resolutie beperkt door de clockfrequentie, en de nauwkeurigheid door de clock source. Als je het echt goed wilt doen, gebruik je een externe tijdreferentie, zoals de 1PPS van een GPS ontvanger of zo. Een resolutie in de orde van een tiental ns is dat vrij triviaal, en de nauwkeurigheid hoeft niet veel slechter te zijn.

Je koppelt wel veel voorwaarden achter uw vraagteken, dan is er ook nog de software.
De meetfouten accumuleren door langere tijd te meten is ook iets om over na te denken.
Moest het display hier aan de teller hangen en in Hz meten dan zou het gedurig verspringen van 50.00 naar 49.99
Tov. de frequentieteller zal hij zeker onnauwkeuriger zijn

Maar hij krijgt het voordeel van de twijfel, het was mij uit nieuwsgierigheid te doen...en zijn probleem ligt elders waarbij ik niet kan helpen.

De truc is juist dat je het meten helemaal zonder tussenkomst van de software doet. Stel dat je een microcontroller op 200MHz laat lopen, een telt hoeveel cyclus daarvan er tussen twee nuldoorgangen passen. Je zult er dan ongeveer 2.000.000 tellen. De uiteindelijke nauwkeurigheid hangt dan af van de kwaliteit van de clock, en dat kun je enorm verbeteren door een externe referentie op dezelfde manier te meten en daarvoor te corrigeren. Het 1PPS signaal van een GPS ontvanger is daarvoor prima geschikt.

De nuldoorgangsdetector is waarschijnlijk de grootste bron van onnauwkeurigheid, maar als je altijd een hele periode meet (dus tussen 2 opgaande of 2 neergaande flanken) ben je een al boel onnauwkeurigheid kwijt.

Als jij denkt dat het anders is, mag je uitleggen waarom; ik denk dat er weinig dingen relatief eenvoudig zo nauwkeurigheid te meten zijn als tijd.

Op zondag 31 maart 2024 01:07:08 schreef SparkyGSX:

Als jij denkt dat het anders is, mag je uitleggen waarom; ik denk dat er weinig dingen relatief eenvoudig zo nauwkeurigheid te meten zijn als tijd.

Ik denk niet dat het anders is, maar ik gaf enkel mijn mening over dit ontwerp en mogelijks gaat dat zelfs heel goed.

Op zaterdag 30 maart 2024 21:02:04 schreef rob040:
Ik moet even goed in de gaten houden wat ik wijzig, wat het doet en hoe ik weer terug kan.

Het is een "git" project. Als je git installeert houdt git bij wat je wijzigt en hoe je weer terug kan.

Edit: Sterker nog, doet ie nu ook al, ook al is ie niet geinstalleerd. Zodra je hem installeert vertelt git status je welke files je veranderd hebt en git diff wat precies.

[Bericht gewijzigd door rew op zondag 31 maart 2024 09:31:48 (23%)]

Op zaterdag 30 maart 2024 21:37:19 schreef Klompendanser2:
Heb me vandaag aangemeld, las dit draadje al eerder. Wil mijn reactie hier nog toevoegen:
Ik zou het programma PonyProg gebruiken en de .hex file in de attiny programmeren.

Ponyprog is zwaar verouderd. Er zijn nog maar weinig PC's (zeker geen laptops) met een fatsoenlijke seriele poort , een paralelle poort kun je helemaal vergeten en is al jaren niet meer geupdate, op Windows/10-11 loopt het ook niet echt lekker.

Ook eens aan het spelen geweest met die code, eea bij elkaar geveegd maar krijg nu tijdens het compileren een error die mijn zeer beperkte C kennis te boven gaat.

Ik zie dat de code 11 jaar oude is en de lib 7 jaar, dus misschien is er in die tijd ook wel wat aan syntax veranderd.

Behalve een paar warnings krijg ik 2 errors , hier de eerste, iemand ?

Is deze niet makkelijker als basis ?
Hoef je alleen nog maar een uitlezing (+code) aan te plakken.

doc8365.pdf

AVR205.zip

[Bericht gewijzigd door bprosman op zondag 31 maart 2024 12:41:07 (31%)]

Op zondag 31 maart 2024 09:28:57 schreef rew:
[...]Het is een "git" project. Als je git installeert houdt git bij wat je wijzigt en hoe je weer terug kan.

Edit: Sterker nog, doet ie nu ook al, ook al is ie niet geinstalleerd. Zodra je hem installeert vertelt git status je welke files je veranderd hebt en git diff wat precies.

Ha rew, ik ben een complete dombo met software. Wat ik tot nu gedaan heb zijn de files voor het project downloaden en in een aparte map op de C-schijf gezet.
Datzelfde heb ik met zijn hele library gedaan.
Verder heb ik make.exe gedownload en in de map met de files (bij makefile) gezet.
Dan met kladblok de makefile aangepast en dat doe ik elke keer zo om te proberen.
Edit: En natuurlijk een compiler gedownload en op de C-schijf gezet.

Dat het in Github kan en hoe wist/weet ik dus niet eens.
Grote onkunde vanuit mijn kant, ik was al blij dat ik een paar stappen vooruit was gekomen...

Op zondag 31 maart 2024 12:37:43 schreef bprosman:
Is deze niet makkelijker als basis ?
Hoef je alleen nog maar een uitlezing (+code) aan te plakken.

Ha Bram, zie mijn opmerking aan rew, dit is voor mij veels te moeilijk. Mijn brein heeft blijkbaar moeite om iets abstracts als FW te begrijpen.

Op zondag 31 maart 2024 11:57:10 schreef bprosman:
Behalve een paar warnings krijg ik 2 errors , hier de eerste, iemand ?

De syntax ziet er goed uit: Een paar regels hoger lijkt dezelfde constructie gewoon wel te werken. Dus mogelijk is 1 van de woordjes die je daar ziet een "reserved word" geworden. Of elders met #define een getal in plaats van een "woord" geworden. Ik zou tijdelijk overal een "a" voor plaatsen (een paar regels hoger een "e")... Als ie dan verder komt dan weet je dat het zoiets was en zou je 1 voor 1 de a's weg moeten halen om te kijken wanneer het weer fout gaat. Die geef je z'n "a" terug en moet je in de rest van de code dan "LOW" in "aLOW" gaan veranderen (of een andere als het een andere blijkt te zijn).

@rob: github is niet hetzelfde als git. Heeft met mekaar te maken, maar is niet hetzelfde.
In wat je hebt gedownload zit een ".git" directory. Daaruit concludeer ik dat je de hele "git" stuff ook hebt gedownload (niet zeker). Daar staat dan in hoe dit project tot op dit punt is gekomen. Met "git" geinstalleerd is "git log" iets van: Laat de samenvatting van alle foto-momenten zien.

Bij zo'n project op github wil het best wel eens gebeuren dat iemand z'n project vrijwel af heeft voordat ie besluit git te gaan gebruiken. Je ziet dan maar 1 of 2 "snapshots". Maar bij een project als "linux" zijn het er vele duizenden (neem ik aan. Niet recent gechecked.).

[Bericht gewijzigd door rew op zondag 31 maart 2024 21:53:21 (30%)]

Heb de code in een Microchip Studio 7 project gezet en dat bouwt zonder problemen. Moest wel de symbolen SUPPRESS_PCINT0 en SUPPRESS_PCINT1 defineren omdat anders dit stukje in lib_pcint.c voor dubbele declaratie van een aantal interrupt vectors zorgt (in main.c staan de ISR's waar het om gaat).

#if defined( PCINT0_vect ) && !defined( SUPPRESS_PCINT0 )
PCINT_ISR(PCINT0);
#endif
#if defined( PCINT1_vect ) && !defined( SUPPRESS_PCINT1 )
PCINT_ISR(PCINT1);
#endif
#if defined( PCINT2_vect ) && !defined( SUPPRESS_PCINT2 )
PCINT_ISR(PCINT2);
#endif
#if defined( PCINT3_vect ) && !defined( SUPPRESS_PCINT3 )
PCINT_ISR(PCINT3);
#endif

#define PCINT_ISR(name) ISR(name ## _vect) { s_bTriggered[e ## name] = true;}

De error van bprosman kwam ik niet tegen. In de release directory staat de elf en hex.

Ha Bas, dat is verrektes mooi, dank je wel!
Nu weet ik dat het mogelijk is om output te genereren. Ik zou het graag reproduceren, want ik moet eigenlijk een aanpassing doen in de 7-segments aansturing. Kan natuurlijk ook de PCB nog aanpassen, maar dacht het 'even' in de software te doen.
Morgen zal ik Microchip Studio 7 ook installeren en dan ga ik kijken of het mij ook lukt.
Heb jij dat op een Windows PC gedaan, of maakt dat niet uit?

Ja, Windows 10.

Hi Bas, ik heb Microchip Studio 7 geinstalleerd.
Nou heb ik even een nieuw map gemaakt waarin de volledige library staat van JamesF en een map met de originele files van het project.
Ik heb in jouw file lib_pcint.c gezien dat onderstaande regels zijn toegevoegd:

#define PCINT_ISR(name) ISR(name ## _vect) { s_bTriggered[e ## name] = true;}

en

#if defined( PCINT0_vect ) && !defined( SUPPRESS_PCINT0 )
PCINT_ISR(PCINT0);
#endif
#if defined( PCINT1_vect ) && !defined( SUPPRESS_PCINT1 )
PCINT_ISR(PCINT1);
#endif
#if defined( PCINT2_vect ) && !defined( SUPPRESS_PCINT2 )
PCINT_ISR(PCINT2);
#endif
#if defined( PCINT3_vect ) && !defined( SUPPRESS_PCINT3 )
PCINT_ISR(PCINT3);
#endif

Dus die kan ik kopiëren en gebruiken. Of is het verstandig om alles uit jouw map source te gebruiken? Zijn er meer dingen aangepast?
Want waar heb jij nou ringbuf.c vandaan gehaald? Dat was toch een file die ontbrak?

Dan, ik vond bij jou een makefile terug, maar die was automatisch gegenereerd.
Wat wordt mijn startpunt, moet ik iets doen met de originele makefile, zoals paden weer aanpassen? En hoe ga ik die file "runnen"?

Ik heb geen code aangepast. Ik kreeg alleen een error op het getoonde stukje omdat het botst met de device specifieke header die Microchip Studio aan het project toevoegt. Op te lossen door -DSUPPRESS_PCINT0 en -DSUPPRESS_PCINT1 mee te geven aan de compiler (zoals eerder ook met -DMEMORY_POOL_BYTES=200).
Die ringbuf.c komt van github. Het is een versiebeheersysteem dus je kunt "terug in de tijd", en dan vind je deze file ook weer. Je kunt dit project in Studio naar wens bewerken en opnieuw op "build" klikken.

Wat ik heb gedaan:

• Een kopie van jouw file gemaakt.
• Files rob040_fMainsDisplay.elf en rob040_fMainsDisplay.elf in de map Release verwijdert (want ik wil die opnieuw maken).
• Ik dubbelklik op rob040_fMainsDisplay.cproj om het project te openen.
• Ik kies project rob040_fMainsDisplay en het correcte device (ATtiny84) wordt zichtbaar.
• Dan ga ik naar Build >> Build solution.
• De compiler gaat aan de gang...
• En komt terug met 4 errors.

De output laat het volgende zien:

------ Build started: Project: rob040_fMainsDisplay, Configuration: Debug AVR ------
Build started.
Project "rob040_fMainsDisplay.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "E:\Microchip Studio 7\7.0\Vs\Compiler.targets" from project "X:\Hobby\Testen & Meten\Net volt- & frequentiemeter\Frequency meter\Software\Files van Bas - kopie\rob040_fMainsDisplay\rob040_fMainsDisplay\rob040_fMainsDisplay.cproj" (target "Build" depends on it):
	Using "RunCompilerTask" task from assembly "E:\Microchip Studio 7\7.0\Extensions\Application\AvrGCC.dll".
	Task "RunCompilerTask"
		Shell Utils Path E:\Microchip Studio 7\7.0\shellUtils
		E:\Microchip Studio 7\7.0\shellUtils\make.exe all --jobs 4 --output-sync 
		Building file: ../source/freq_data.c
		Invoking: AVR/GNU C Compiler : 5.4.0
		"E:\Microchip Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU=8000000  -I"E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\include"  -O3 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny84 -B "E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny84" -c -std=gnu99 -MD -MP -MF "source/freq_data.d" -MT"source/freq_data.d" -MT"source/freq_data.o"   -o "source/freq_data.o" "../source/freq_data.c" 
		Finished building: ../source/freq_data.c
		Building file: ../source/lib_fuses.c
		Invoking: AVR/GNU C Compiler : 5.4.0
		"E:\Microchip Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU=8000000  -I"E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\include"  -O3 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny84 -B "E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny84" -c -std=gnu99 -MD -MP -MF "source/lib_fuses.d" -MT"source/lib_fuses.d" -MT"source/lib_fuses.o"   -o "source/lib_fuses.o" "../source/lib_fuses.c" 
		Finished building: ../source/lib_fuses.c
		Building file: ../source/lib_clk.c
		Invoking: AVR/GNU C Compiler : 5.4.0
		"E:\Microchip Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU=8000000  -I"E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\include"  -O3 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny84 -B "E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny84" -c -std=gnu99 -MD -MP -MF "source/lib_clk.d" -MT"source/lib_clk.d" -MT"source/lib_clk.o"   -o "source/lib_clk.o" "../source/lib_clk.c" 
		Finished building: ../source/lib_clk.c
		Building file: ../source/lib_extint.c
		Invoking: AVR/GNU C Compiler : 5.4.0
		"E:\Microchip Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU=8000000  -I"E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\include"  -O3 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny84 -B "E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny84" -c -std=gnu99 -MD -MP -MF "source/lib_extint.d" -MT"source/lib_extint.d" -MT"source/lib_extint.o"   -o "source/lib_extint.o" "../source/lib_extint.c" 
		Finished building: ../source/lib_extint.c
		Building file: ../source/lib_io.c
		Invoking: AVR/GNU C Compiler : 5.4.0
		"E:\Microchip Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU=8000000  -I"E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\include"  -O3 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny84 -B "E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny84" -c -std=gnu99 -MD -MP -MF "source/lib_io.d" -MT"source/lib_io.d" -MT"source/lib_io.o"   -o "source/lib_io.o" "../source/lib_io.c" 
		Finished building: ../source/lib_io.c
		Building file: ../source/lib_pcint.c
		Invoking: AVR/GNU C Compiler : 5.4.0
		"E:\Microchip Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU=8000000  -I"E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\include"  -O3 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny84 -B "E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny84" -c -std=gnu99 -MD -MP -MF "source/lib_pcint.d" -MT"source/lib_pcint.d" -MT"source/lib_pcint.o"   -o "source/lib_pcint.o" "../source/lib_pcint.c" 
		Finished building: ../source/lib_pcint.c
		Building file: ../source/lib_shiftregister.c
		Invoking: AVR/GNU C Compiler : 5.4.0
		"E:\Microchip Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU=8000000  -I"E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\include"  -O3 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny84 -B "E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny84" -c -std=gnu99 -MD -MP -MF "source/lib_shiftregister.d" -MT"source/lib_shiftregister.d" -MT"source/lib_shiftregister.o"   -o "source/lib_shiftregister.o" "../source/lib_shiftregister.c" 
		Finished building: ../source/lib_shiftregister.c
		Building file: ../source/lib_tlc5916.c
		Invoking: AVR/GNU C Compiler : 5.4.0
		"E:\Microchip Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU=8000000  -I"E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\include"  -O3 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny84 -B "E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny84" -c -std=gnu99 -MD -MP -MF "source/lib_tlc5916.d" -MT"source/lib_tlc5916.d" -MT"source/lib_tlc5916.o"   -o "source/lib_tlc5916.o" "../source/lib_tlc5916.c" 
		Finished building: ../source/lib_tlc5916.c
		Building file: ../source/main.c
		Invoking: AVR/GNU C Compiler : 5.4.0
		"E:\Microchip Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU=8000000  -I"E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\include"  -O3 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny84 -B "E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny84" -c -std=gnu99 -MD -MP -MF "source/main.d" -MT"source/main.d" -MT"source/main.o"   -o "source/main.o" "../source/main.c" 
		Finished building: ../source/main.c
		Building file: ../source/ringbuf.c
		Invoking: AVR/GNU C Compiler : 5.4.0
		"E:\Microchip Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU=8000000  -I"E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\include"  -O3 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny84 -B "E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny84" -c -std=gnu99 -MD -MP -MF "source/ringbuf.d" -MT"source/ringbuf.d" -MT"source/ringbuf.o"   -o "source/ringbuf.o" "../source/ringbuf.c" 
		Finished building: ../source/ringbuf.c
		Building file: ../source/seven_segment_map.c
		Invoking: AVR/GNU C Compiler : 5.4.0
		"E:\Microchip Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU=8000000  -I"E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\include"  -O3 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny84 -B "E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny84" -c -std=gnu99 -MD -MP -MF "source/seven_segment_map.d" -MT"source/seven_segment_map.d" -MT"source/seven_segment_map.o"   -o "source/seven_segment_map.o" "../source/seven_segment_map.c" 
		Finished building: ../source/seven_segment_map.c
		Building target: rob040_fMainsDisplay.elf
		Invoking: AVR/GNU Linker : 5.4.0
		"E:\Microchip Studio 7\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o rob040_fMainsDisplay.elf  source/freq_data.o source/lib_clk.o source/lib_extint.o source/lib_fuses.o source/lib_io.o source/lib_pcint.o source/lib_shiftregister.o source/lib_tlc5916.o source/main.o source/ringbuf.o source/seven_segment_map.o   -Wl,-Map="rob040_fMainsDisplay.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mmcu=attiny84 -B "E:\Microchip Studio 7\7.0\Packs\atmel\ATtiny_DFP\1.3.172\gcc\dev\attiny84"  
X:\Hobby\Testen & Meten\Net volt- & frequentiemeter\Frequency meter\Software\Files van Bas - kopie\rob040_fMainsDisplay\rob040_fMainsDisplay\Debug\Makefile(227,1): error: recipe for target 'rob040_fMainsDisplay.elf' failed
		source/main.o: In function `__vector_2':
X:\Hobby\Testen & Meten\Net volt- & frequentiemeter\Frequency meter\Software\Files van Bas - kopie\rob040_fMainsDisplay\rob040_fMainsDisplay\source\main.c(296,1): error: multiple definition of `__vector_2'
		source/lib_pcint.o:X:\Hobby\Testen & Meten\Net volt- & frequentiemeter\Frequency meter\Software\Files van Bas - kopie\rob040_fMainsDisplay\rob040_fMainsDisplay\Debug/../source/lib_pcint.c:107: first defined here
		source/main.o: In function `tlcNullFn':
X:\Hobby\Testen & Meten\Net volt- & frequentiemeter\Frequency meter\Software\Files van Bas - kopie\rob040_fMainsDisplay\rob040_fMainsDisplay\source\main.c(293,1): error: multiple definition of `__vector_3'
		source/lib_pcint.o:X:\Hobby\Testen & Meten\Net volt- & frequentiemeter\Frequency meter\Software\Files van Bas - kopie\rob040_fMainsDisplay\rob040_fMainsDisplay\Debug/../source/lib_pcint.c:42: first defined here
collect2.exe(0,0): error: ld returned 1 exit status
		make: *** [rob040_fMainsDisplay.elf] Error 1
		The command exited with code 2.
	Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreBuild" in project "rob040_fMainsDisplay.cproj" -- FAILED.
Done building project "rob040_fMainsDisplay.cproj" -- FAILED.

Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========

Ik doe dus duidelijk iets niet goed, enig idee wat?