henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Vooral bij het gebruik van porteren van code van andere CPU's is het gebruik van alle stdint.h types sterk aan te bevelen. (kortom als je zelf libraries maakt die je vaker wilt gebruiken)
Ik heb eens aan een project meegewerkt waar we een hele bak code kregen die aan "onze" code geplakt moest worden. Nou die hadden dus hun eigen INT16 INT32 en meer van dat soort dingen zelf gemaakt. Een grote nachtmerrie was dat, het kostte meer dan een dag om alle ellende rondom die macros recht te breien.
Ook in hetzelfde project kreeg ik een library van 3-den die netjes stdint.h hadden gebruikt. Binnen 15 min compileerde dat. Alleen wat include paden fixen en klaar.
Op 29 december 2019 20:28:29 schreef deKees:
Het makkelijkste is om alle variabelen in homing.c te zetten en dan de nodige 'extern' declaraties in de homing.h te zetten zodat alles ook vanuit main.c beschikbaar is.Meestal is het ook wel handig om een deel van de variablen als funktie parameter te definieren. Dan kun je die gemakkelijk doorgeven vanuit de funktie aanroep.
Maar een betere methode is om die variabelen in een struct of een class te definieren. Maar dat vergt wat meer werk.
bovenstaande gaat over een variabele die zowel in de main.c als in de homing.c word gebruikt.
kan je niet gewoon b.v. int speed_select; zowel in de main.c als in de homing.c zetten ?
edit: de compiler slikt het in ieder geval.
kan je niet gewoon b.v. int speed_select; zowel in de main.c als in de homing.c zetten ?
Dat kan wel, maar dan krijg je twee aparte variabelen die allebei dezelfde naam hebben maar verder niet aan elkaar gekoppeld zijn. En dat is volgens mij niet de bedoeling.
Als het goed is krijg je dan ook foutmeldingen tijdens het linken, tenzij die variabelen 'static' zijn, of als het lokale variabelen zijn.
ben ik weer 
wat aan het testen, hoe zit het eigenlijk met een #define ?
als ik b.v. een button led_on heb,
en ik gebruik die zowel in de mainc als ook in de homing.c
moet ik dan in beide (main.c & homing.c) #define led_on ((PINA & (1<<PINA7)) == 0) zetten ?
edit: volgens mijn testjes lijkt het van wel.
Zo een #define wordt door de pre-processor tijdens compileren afgehandeld.
#define led_on ((PINA & (1<<PINA7)) == 0)
Hier wordt de tekst "led_on" vervangen door de tekst "((PINA & (1<<PINA7)) == 0)"
Normaal zet je zo een #define in de header homing.h zodat die dmv een #include overal meegenomen kan worden waar je die gebruikt.
Maar dan moet je ook overal PINA en PINA7 beschikbaar hebben.
Dus dan kun je beter de #define weglaten en een funktie definieren.
In homing.h :
bool led_on();
In homing.c :
bool led_on()
{ return ((PINA & (1<<PINA7)) == 0);
}
In main.c :
#include "homing.h"
...
if(led_on())
{ ...
}
...
## deleted ##
EDIT Oeps, laat maar. Het is een query ipv een imperatief. Het klopt wel. Ik ben niet wakker.
[Bericht gewijzigd door Deskinspin op (56%)]
geeft een error: unknown type name 'bool'
moet er mischien nog iets ge-included worden ?
O ja, bool is iets van C++ en bestaat niet in C.
Als je de sourcefile extensie verandert in .cpp dan werkt het weer.
En je kunt ook een typedef of een #define toevoegen aan homing.h :
#ifndef bool
#define bool unsigned char
#define true 1
#define false 0
#endif
of
typedef unsigned char bool;
#define true 1
#define false 0
edit
Of de definitie van led_on() aanpassen in homing.h en in honing.c en als return value een unsigned char gebruiken ipv een bool:
unsigned char led_on()
[Bericht gewijzigd door deKees op (19%)]
met dat #define wil nog niet erg lukken, maar ik zal eens posten wat tot nu toe werkt. het is een minimale code alleen om te testen.
met x & y test ik de variabele.
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Nee niet klooien met eigen defines en typedefs (ik krijg een dejavu).
Dit bovenaan in je source includen:
#include <stdint.h>
#include <stdbool.h>
Dat werkt bij een beetje moderne compiler (C99 support).
Die "define led_on ..." is een erg slechte manier van schrijven.
Later kijk je naar die code en denk je wtf doet dat?
Zet die de led nu aan of checked dat ding iets??
Dus beter de test functie(of macro) is_ledon() noemen. Dan leest de code later ook beter.
Verder wordt zo'n macro ook vaak in een do {} while(0) constructie gepropt om deze als een functie aanroep eruit te laten zien (wat een stuk handiger is). Maar ik zal het even niet moeilijker maken.
#include <stdint.h>
#include <stdbool.h>
Dit kan ook inderdaad, veel beter.
Werkt bij mij in elk geval ook in AS7.
ga ik morgen testen.
led_on is zomaar een bedachte benaming voor deze test.
word helemaal niet gebruikt in het uiteindelijke programma.
Op 3 januari 2020 19:19:45 schreef henri62:
Dit bovenaan in je source includen:#include <stdint.h> #include <stdbool.h>
met source word main.c of homing.c bedoeld ?
Overal waar je bool gebruikt moet deze bekend zijn.
Het makkelijkste is om het bovenin de homing.h te zetten.
Want die wordt al in allebei meegenomen als het goed is.
Boudie
Vervangen DOOR.
Op 3 januari 2020 12:54:14 schreef Deskinspin:
Ik ben niet wakker.
Geeft niet hoor. Daar heb je wel vaker last van.
is ie weer
getest en het lijkt te werken in de simmulatie. wat mij op valt is dat wanneer hij in de main.c bij if(led_on()) komt, het programma naar homing.c gaat naar
bool led_on()
{ return ((PINA & (1<<PINA7)) == 0);
}
daar word led_on gedefinieerd, en dan weer terug naar de main.c
en verder gaat waar hij gebleven was.
lijkt mij wel logisch, maar het viel me op.
ik heb nog een wijziging toegevoegd:
in homing.c
#include <stdint.h>
#include <stdbool.h>
verwijderd en,
#include "homing.h"
toegevoegd.
lijkt mij meer "zoals het hoort".
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Het is meer een defacto standard (of zoals je zelf al zegt: "zoals het hoort") dat je "self-contained" header files maakt.
Dat wil zeggen dat als je een willekeurige header file (.h) include in een andere source, dat deze moet compileren zonder dat extra dingen in je source hoeft toe te voegen.
Als je dus in een header file een 'bool' hebt gebruikt zorg je dat ook stdint en stdbool ook in dezelfde file included worden.
Dit heeft het voordeel dat als iemand een header van een library gebruikt zich niet druk hoeft te maken of er nog allerlei andere zooi included moet worden om het werkend te krijgen.
Omdat je zo door deze methode ook vaak meerdere keren dezelfde headers zou kunnen includen worden die zgn "include guards" gebruikt (die #ifdef __XXX_H__ constructies) om er voor te zorgen dat de file in werkelijkheid maar EEN keer wordt "geparsed" in elke source file.
In C++ en sommige C compilers kun je ipv die constructie ook "#pragma once" in de header file zetten. Dat compileerd over het algemeen ook sneller.
rew
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
Op 5 januari 2020 12:56:20 schreef trix:
in homing.c#include <stdint.h>
#include <stdbool.h>verwijderd en,
#include "homing.h"
En dan de twee includes in homing.h toegevoegd (of die stonden daar al?) ?
Smaak-kwestie, maar ik vind dat niet helemaal de juiste aanpak. Als je binnen een project totaal tien includes nodig hebt, maar niet allemaal in ALLE sourcefiles, dan krijg je na verloop van tijd dat alle includes in het "include-de-includes" file staan. Zo krijgen dan alle sourcefiles veel te veel includes te verwerken. Nu gaat het me niet om de processing tijd van de compiler, maar meer om "onnodige shit te vermijden".
Het is een beetje anders als je in de declaraties van homing.h de definities van stdint en stdbool nodig zou hebben. Dan kan je zeggen dat die includes wel in homing.h thuishoren. Maar dan zit je dus met dat je "achter de schermen" stdint en stdbool include omdat je "toevallig" homing.h include. Mocht je later bijvoorbeeld een configuratie hebben waarbij je homing.h niet meer nodig hebt, dan verlies je in je module ineens ook de definities uit stdint.h en stdbool.h.
Let op: Dit is een mening. Die wordt zeker niet door IEDEREEN gedeeld. Maar het even van de andere kant bekijken en nadenken over hoe JOU sourcecode het meest overzichtelijk en robuust wordt is een goede zaak.
(robuust: als je bijvoorbeeld het "homing" deel afsplitst naar een andere sourcefile, dan hoef je minder van de "homing" details te weten als je dat als module gebruikt. Robuust is: je HOEFT het niet te weten, maar ook: het blijft doen wat je er van verwacht ook al zou je het een keer iets anders gebruiken dan origineel bedoeld.).
Op 7 januari 2020 09:41:58 schreef rew:
[...]En dan de twee includes in homing.h toegevoegd (of die stonden daar al?) ?
stonden er al (te zien in de 3 print screens die ik als laatste heb gepost).
Op 6 januari 2020 22:46:49 schreef henri62:
Omdat je zo door deze methode ook vaak meerdere keren dezelfde headers zou kunnen includen worden die zgn "include guards" gebruikt (die #ifdef __XXX_H__ constructies) om er voor te zorgen dat de file in werkelijkheid maar EEN keer wordt "geparsed" in elke source file.
hier bedoel je denk ik dat wanneer ik b.v. een manual.c zou maken dat iedere keer de manual optie word gebruikt, dezelfde file word geincluded.
(bij homing.c niet, want dat doe je maar 1x 
)
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Op 7 januari 2020 09:41:58 schreef rew:
[...] ...
Let op: Dit is een mening. Die wordt zeker niet door IEDEREEN gedeeld. Maar het even van de andere kant bekijken en nadenken over hoe JOU sourcecode het meest overzichtelijk en robuust wordt is een goede zaak.
Dat was mijn mening vroeger ook (eigenlijk stieken nog steeds). Include in je .c file wat je aan standaard spul nodig hebt en dan pas de library header files.
De library moet dan documenteren wat die nodig heeft.
Maar blijkbaar zijn veel programmeurs van die lamzakken die te beroerd zijn om documentatie te maken en een nette API te beschrijven. Je wilt niet weten hoeveel discussies ik hierover heb gehad bij diverse bedrijven en andere SW engineers. Altijd kwamen smoezen van: Er zitten include guards omheen bla bla maakt niet zo veel uit en noem maar op.
Ik heb zelfs performance testjes gedaan wat al die zooi (redundant includen) aan tijd kost, dat waren verassende resultaten.
Uiteindelijk heb ik het opgegeven en die shit maar geaccepteerd dat iedereen het zo doet.
Dus in dit geval zou alleen stdbool.h in de homing.h moeten staan, omdat de homing.h die verderop nodig heeft.
stdint.h moet dan alleen in de .c files waar die nodig is.
Probleem is dan wel dat je bezig blijft met het verhuizen van includes als je later de definities in de header files aanpast.
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Op 8 januari 2020 22:17:30 schreef deKees:
Dus in dit geval zou alleen stdbool.h in de homing.h moeten staan, omdat de homing.h die verderop nodig heeft.
Nop, je moet stdint.h includen VOOR stdbool.h. Dit omdat die een macro definieerd (_Bool) die stdbool.h gebruikt (rtfm).
-edit- De C99 standaard bijvoorbeeld. Of eerste hit als je zoekt op stdbool.h https://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdbool.h.htm…
(rtfm : read the fine manual)
[Bericht gewijzigd door henri62 op (13%)]
Dus dan zou stdbool.h eigenlijk zelf al de stdint.h moeten includen.
Maar feitelijk is het dus niet te doen om alles uit elkaar te houden.
Ben wel benieuwd welke rtfm manual je hier bedoelt. Ik zou het niet weten.
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Op 8 januari 2020 22:52:26 schreef deKees:
Dus dan zou stdbool.h eigenlijk zelf al de stdint.h moeten includen.
Dat is dus precies wat 'rew' bedoeld. En waar ik ook voorstander van ben/was.
Dan krijg je dus precies wat je bedoeld, je moet wat docs gaan lezen wat je precies moet includen.