henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
@trix, het lijkt erop wat je gedaan hebt wel de manier is om een extra C-source toe te voegen. Heb je die ook met een .c extensie opgeslagen?
Wel moet je van de functies dan ook een header file maken (je interface definitie). Anders kun je vanaf je main.c de code niet aanroepen.
Als ik het voorbeeld van deKees gebruik maak je dan een regel met alleen de functienaam (+ een ; ) en stop je die in een file met nagenoeg dezelfde naam maar dan met een .h extensie.
void ClearRotary();
Die voeg je ook toe aan je project. Dit soort regels noemt men een "prototype" van je functie (ofwel forward declaratie).
In je main.c (of net hoe die heet) doe je dan een: #include "jouwfilename.h"
Als het goed is zal AS7 automatisch alle object files aan elkaar linken.
flipflop
"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
Op 22 december 2019 21:06:07 schreef deKees:
Hoeveel code past er trouwens op een A4'tje? Dat is nogal afhankelijk van het font-size, en...
Autist 
buckfast_beekeeper
Van Lambiek wordt goede geuze gemaakt.
Op 22 december 2019 21:06:07 schreef deKees:
Hoeveel code past er trouwens op een A4'tje? Dat is nogal afhankelijk van het font-size, en het is alweer een tijdje geleden dat ik nog sourcefiles heb afgeprint.Toen werkten we trouwens nog met ketting-papier en hadden we nog applikaties die draaiden vanuit een 2732 Eprom, dus zo rond 1982.
A4 is standaard font (monospaced) 80 karakters breed en ongeveer 25 lijnen bij een normale uitlijning.
edit: dit is een reactie op henri62
verdorie er was al een 2e pagina geopend.
ik verkreeg dan een .c extencie. maar dat is denk ik niet goed, omdat wanneer ik een bestaande werkend file toevoeg (voor een HD44780) een .h extencie verkrijg.
ik sla dat blok op als of het een eigen programma is, maar in dat programma staat dan b.v. geen include en main en dergelijke.
wanneer je dit blok dan op mijn manier toevoegd aan het hoofd programma, krijg je waarschijnlijk compiler errors.
ik moet even nog je reactie op mij laten in werken, om het te begrijpen.
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Er zou iets moeten zijn als de solution explorer, daar voeg je een (nieuwe) source file (+header file toe).
Dan copieer alleen de stukken sourcecode naar de nieuwe C file.
Uit je originele main.c (of net hoe die heet) moet je die dan weg halen natuurlijk anders krijg je linker errors dat er duplicate symbols zijn.
Ook de nodige headers includen (die je minimaal nodig hebt) in het nieuwe "stuk" C code.
En dat klopt, er is maar een main() in heel je programm.
Als je met meerdere sourcefiles werkt dan zit de feitelijke code in een sourcefile met een .c (of een .cpp) extensie, en dan moet je ook een header file aanmaken met een .h extensie.
De .h file heeft dan
void ClearRotary();
Dat is dan alleen een declaratie van de funktie, net genoeg om te weten hoe de funktie wordt gebruikt. Die header wordt dan geinclude in je main:
#include "ClearRotary.h"
Met deze header file weet de compiler tijdens compileren van main.c dat er ergens een funktie bestaat die ClearRotary() heet, en dat die geen parameters nodig heeft en geen return value teruggeeft.
Dan heb je nog de implementatie van de funktie in je .c (of .cpp) file:
#include "ClearRotary.h"
void ClearRotary()
{ // Hier de statements tussen zetten die de funktie uitvoeren.
}
Met deze sourcefile kan de compiler dan die funktie ook daadwerkelijk aanmaken.
flipflop zou dan -als ik het goed begrijp- een aparte sourcefile aanmaken voor elke funktie die iets met die rotaries doet, zodat je alleen al voor die rotarie encoder een tiental sourcefiles krijgt (met evenzovele header files?).
Ik zou die dan allemaal in een enkele header file zetten "Rotary.h" en een enkele Rotary.c met daarin alle rotary funkties.
Het kan allemaal, het is maar net wat je handig vind. Je kunt zelfs alle declaraties in een enkele .h file zetten en toch de implementatie over meerdere .c files verdelen, al is dat tamelijk ongebruikelijk.
flipflop
"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
Op 22 december 2019 22:31:58 schreef deKees:
flipflop zou dan -als ik het goed begrijp- een aparte sourcefile aanmaken voor elke funktie die iets met die rotaries doet, zodat je alleen al voor die rotarie encoder een tiental sourcefiles krijgt
Nee, dat zou ff dus niet doen In jouw voorbeeld zou ik alle rotary functies in een file stoppen. Zeker in dit voorbeeld wordt dat nooit enorm veel code, dus dat past best een op paar A4's (niet te letterlijk nemen he!). Daarbij heb je dus 1 .h file die je include, overal waar de rotary functies gebruikt wordt. Nou kan het zijn dat die file toch erg groot wordt. In dat geval zou je de "laag bij de hardware" functies in een file kunnen houden (dat is eigenlijk de driver) en de functies die meer tegen je applicatie aan zitten in een andere. Hangt van de situatie af.
Hetzelfde doe je uiteraard met leds.c, display.c, motorsturing.c etc.
Ok, kan best dat ik alles wat al te letterlijk neem. Daar ben ik inderdaad nogal op gefocust. Maar een opmerking als deze kan ik toch moeilijk anders interpreteren.
Een file moet niet meer dan 1 a 2 A4'tjes zijn. Sources voor verschillende functies horen in aparte files te staan.
Maar misschien bedoel je 'funktie' hier in de betekenis van 'funktionele eenheid' zoals 'rotary' en niet in de betekenis van subroutine.
Feit blijft dat je in grote projecten niet ontkomt aan grote source files en dat je dat niet kunt afdoen als slecht ontwerp.
flipflop
"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
Op 23 december 2019 11:38:27 schreef deKees:
...Maar misschien bedoel je 'funktie' hier in de betekenis van 'funktionele eenheid' zoals 'rotary'
Ah, zit 'm daar de crux Ja, bedoelde ik als functie van de applicatie, niet als functie in de syntax vd programmeertaal. In het laatste geval krijg je wel heeeeuuuuul veel files.
ben nog wat aan het proberen, ik doe nu het volgende:
onder solution explorer (appart veld)
right click op map
add
new item
dan zijn er 5 optie's, ik kies: include file
add
er verschijnt in solution explorer een bestand met .h extencie
die je kan "renamen"
als ik dat bestand open zie ik:
/*
* IncFile1.h
*
* Created: 23-12-2019 19:01:19
* Author: 31610
*/
#ifndef INCFILE1_H_
#define INCFILE1_H_
#endif /* INCFILE1_H_ */nou vermoed ik dat ik mijn blok (homing stepper) hier tussen moet voegen ??
en uiteraard verwijderen uit het hoofdprogramma.
so far so good, denk ik, maar nu rijzen er 2 vragen.
als ik op boven genoemde manier 4 "blokken" maak, hoe zorg ik er dan voor dat de blokken in de juiste volgorde worden afgewerkt ?
en hoe roep ik die blokken aan ? gaat dat dan met includen, en kan ik daarmee dan ook de volgorde bepalen ? wat meteen vraag 1 zou oplossen.
ik "rommel" nog even verder.
edit: o ja....die blokken worden tabbladen
ze worden niet automatisch gelinkt, wanneer ik opzettelijk een fout maak in homing stepper en ik build het hoofdprogramma dan word deze fout niet opgemerkt.
maar build ik in homing stepper, dan ziet hij de fout ook niet .......wazig.
ik heb nu #include "homing stepper.h" toegevoegd nu ziet hij de fout wel.
stop nu even met het live verslag
ik kom er op terug.
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
nou vermoed ik dat ik mijn blok (homing stepper) hier tussen moet voegen ??
Nee: de code moet in een een C file komen, de header file moet alleen in interface bevatten. DWZ de functienamen zelf. Zoals boven door mij is aangegeven en door deKees herhaald is.
Voeg op dezelfde manier een C file toe en zet daar de "echte" code in.
als ik op boven genoemde manier 4 "blokken" maak, hoe zorg ik er dan voor dat de blokken in de juiste volgorde worden afgewerkt ?
Dat doe je zelf door de functies in je hoofdprogramma op de juiste manier/plaats aan te roepen.
Ieder stuk wat functioneel iets doet stop je in een functie en die geef je een naam. Als dat bij elkaar hoort stop je die in dezelfde (extra C) file en voegt een "prototype" van die functie toe aan de header file (dus 1 regel per functie).
Dan kun je die functies weer aanroepen in je hoofdprogramma.
Heb je stukken code die iets anders doen maar wel bij elkaar horen stop je die weer in een nieuwe C-file (met een bijbehorende zinnige naam) met ook weer een header file (.h) etc.
ok....de thermologie is soms een probleem voor mij. voor julie gesneden koek, maar voor een leek/beginner taaie kost.
ik ga der mee aan de slag.
.h is dus natuurlijk header en heeft niks van doen met hexadecimaal 
[Bericht gewijzigd door trix op (21%)]
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Ik zie dat je de nieuw file IncFile1 genoemd hebt. Dat is natuurlijk niet zo handig. Beter is een zinnige naam kiezen voor de functionaliteit die ook in de file komt te zitten.
Stel zoals je voorbeeld allerlei functies hebt om een LCD aan te sturen (init, writeChar, writeInt en noem maar op) bundel je die in weer als voorbeeld in een file genoemd lcd.c, zo kun je in een keer zien waar je welke functionaliteit hebt opgelost.
die heb ik later ge renamed
1 van de 5 eerder door mij genoemde opties is: C file
add
en nu verschijnt er uiteraard in de solution explore een bestand met .c
+ een tabblad met dezelfde naam.
ge renamed naar homing stepper.
de bijbehorene code in het des betreffende tabblad gezet.
de header file moet alleen in interface bevatten. DWZ de functienamen zelf
dus ik moet dan ook nog een .h file toevoegen
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Precies. Enne: gebruik geen spaties in filenamen. Is maar dat je gewaarschuwd bent.
P.S. Die:
#ifndef INCFILE1_H_
#define INCFILE1_H_
Eendif
is een zgn "include guard" de voorkomt dat je een file 2x include en je allerlei errors krijgt.
Die "defines" moet je dus ook renamen als je de file named hebt, dus beter direct een goede filenaam kiest, scheelt weer werk.
de post van dekees nog eens door gelezen en daar staat het inderdaad duidelijk in, ga ermee aan de slag.
allen bedankt voor de inzet en geduld.
i.p.v. spaties ga ik underscores gebruiken. geld dat voor file namen in het algemeen ?
[Bericht gewijzigd door trix op (24%)]
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Spaties gebruiken in filenames in een project is vrijwel altijd een probleem. Dit komt omdat die als argument aan de compiler meegegeven worden, bijvoorbeeld zo:
cc -o filename.o filename.c
De argumenten megegeven aan een willekeurig programma worden op spaties "gesplitst" daardoor zit de compiler in dit geval bij "file name" hetvolgende:
cc -o file name.o file name.c
En kan die er niet veel meer goeds van maken omdat die dan name.o als input file ziet. Je krijgt dan allerlei wazige fouten.
Leuk voor domme word documenten etc, maar niet voor compilatie.
weer even tijd gevonden om te testen.
nu heb ik eigenlijk 3 vragen die mij niet helemaal duidelijk zijn:
het blok waar ik een apparte .c van wil maken heet homing
1- dat blok code zet je in een .c file
daar hoort dan een .h file bij
als ik nu 1 zo'n apart blok maak, staat er dan ook in de .h file
maar 1 regel ? dus bij mij: void homing();
2- mag ik de .h en de .c dezelfde naam geven dus homing.h en homing.c
3- ik heb het een en ander getest en de compiler kwam met een 30 tal errors
meeste als: first used in this function
het goede nieuws is dat ik errors zie in de homing.c en de main.c zie, waaruit ik de conclusie trek dat deze bestande wel gelinkt zijn.
als nu in de main.c staat: #define homing_button ((PINB & (1<<PB6)) == 0)
dan lijkt het dat ik dat moet plaatsen in de homing.c file, want daar word de button gebruikt.
klopt dat ? (heeft wel invloed op de aantal errors)
en wanneer deze button in zowel de homing.c en de main.c worden gebruikt moet deze regel dan in beide files ?
ik kan me dat bijna niet voorstellen. vooral dat laatste want dat zou betekenen dat er meer code word gedownload naar de controller.
ik hoop dat ik weer op julie input mag rekenen.
Op 26 december 2019 18:40:42 schreef trix:
staat er dan ook in de .h file maar 1 regel ? dus bij mij: void homing();
Soms gebeurd dat (maar één betekenisvolle regel in de .h file). Dat is niet erg.
2- mag ik de .h en de .c dezelfde naam geven dus homing.h en homing.c
Dat mag, en dat is gewenst: Dan kunnen mensen zien dat ze gerelateerd zijn. (De compiler kijkt niet naar de naam, die moet je alsnog vertellen (met een "#inlude") dat ze bij elkaar horen)
first used in this function
Dan heb je de functie gebruikt voordat de compiler hem kende, meestal omdat je de include met de declaratie vergeten bent.
#define homing_button ((PINB & (1<<PB6)) == 0)
...
in zowel de homing.c en de main.c worden gebruikt moet deze regel dan in beide files ?
#define zet je bijna altijd in een .h, in dit geval denk ik in homing.h. Daarna #include je homing.h in zowel homing.c als in main.c.
bedankt, ik ga dat straks eens proberen.
Op 26 december 2019 22:25:02 schreef blurp:
Dat mag, en dat is gewenst: Dan kunnen mensen zien dat ze gerelateerd zijn. (De compiler kijkt niet naar de naam, die moet je alsnog vertellen (met een "#inlude") dat ze bij elkaar horen)
dat gaat natuurlijk niet meer wanneer er meerdere bloken komen met verschillende namen.
[Bericht gewijzigd door trix op (83%)]
weer wat tijd gevonden om het een en ander te testen, maar het wil nog niet echt vlotten 
nu heb ik voor het overzicht het een en ander terug gebracht tot een minimum code.
als ik in een v/d files (homing.h homing.c of main.c) opzettelijk een fout maak, en ik build hem (maakt niet uit vanaf welk tabblad) dan krijg ik een error. dat is voor mij het bewijs dat alle files gelinkt zijn.
wie ziet waar de errors vandaan komen ?
Arco
Special Member
Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
CROP!
('t Is nogal storend die enorme tekeningen van 4000x2000 pixels die voor 90% leeg zijn... 
)
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
In de file waar je die pin definities gebruikt moet je ook de file includen waar de PINB en PB6 gedefinieerd worden.
Dat is waarschijnlijk #include <avr/io.h> dus toevoegen in homing.c
P.S. de screenshots zijn nog steeds veel te groot. Kun je met "paint" makkelijk croppen.
is mij al vaker verteld dat croppen, ik begrijp nu pas wat er bedoeld word.
pak ik eerst even aan.
even kijken hoe dat gaat in paint ?
edit:
henri62, je voorstel getest en geen errors
bedankt.
[Bericht gewijzigd door trix op (20%)]
De compiler behandelt elke .c file als een aparte unit die niet aan elkaar gerelateerd zijn. Tijdens compileren van homing.c ziet de compiler een tweetal onbekende namen "PINB" en "PB6". De compiler kent die niet en geeft daarop een foutmelding.
Tijdens compileren van main.c zijn diezelfde woorden wel bekend omdat "avr/io.h" geincluded is in main.c. Als je die ook include in homing.c dan gaat het weer een stuk beter.