De CanBus komt naar Kranenberg, Arduino's en de CanBus

[bask185]

Waarom is myServo eigenlijk een pointer?

[meino]

Dag Bas

Ik geloof dat we daar al eens eerder een discussie over hebben gehad. Laat ik het houden op programmeerstijl en voorkeur.
Ik houd er van om met New objecten te maken. Dat heeft er mee te maken dat ik op die manier een onderscheid probeer te houden tussen primitieven zoals int, long etc en objecten, Verder kun je in een functie aanroep (in C en C++) alleen primitieven (int, long, pointers, etc) doorgeven maar niet een object. Dus wil je een object aan een functie doorgeven zal dat altijd in de vorm van een pointer moeten. Dus prefereer ik om zo vaak mogelijk met pointers te werken.

Groet Meino

[reinderlf]

Hoi Meino,

Ook objecten die op de stack gemaakt zijn kun je ook doorgeven, dat kan op verschillende manieren in C++:

Object op de stack:

Code: [Selecteer]

Object object;
1. Als referentie:

Code: [Selecteer]

void functie(Object& object); aanroepen als

Code: [Selecteer]

functie(object);
2. Als const referentie:

Code: [Selecteer]

void functie(const Object& object); aanroepen als

Code: [Selecteer]

functie(object);
3. Als pointer:

Code: [Selecteer]

void functie(Object* object); aanroepen als

Code: [Selecteer]

functie(&object);
4. Als const pointer:

Code: [Selecteer]

void functie(const Object* object); aanroepen als

Code: [Selecteer]

functie(&object);
5. Als kopie:

Code: [Selecteer]

void functie(Object object); aanroepen als

Code: [Selecteer]

functie(object);
6. Via move (r-value reference):

Code: [Selecteer]

void functie(Object&& object); aanroepen als

Code: [Selecteer]

functie(std::move(object));
Voor objecten die het hele programma leven is het handiger om ze als global (of static binnen een class) te declareren, groot voordeel is dat je tijdens het compileren weet of het in het geheugen past van de microcontroller.
Het nadeel van heap allocaties (via new) is dat je pas tijdens het draaien van je code weet of er genoeg geheugen is. De wat kleinere microcontrollers hebben vaak geen MMU (memory management unit), hier moet de compiler dan wat mee doen.

Een reference heeft over het algemeen de voorkeur t.o.v. een pointer, het voordeel van een reference is dat deze altijd geldig is Een pointer daarin tegen kan NULL zijn. (Wat dan wel weer handig kan zijn als de parameter optioneel is )

Mocht je nog vragen hebben, let me know

Reinder

p.s. Het is niet betweterig bedoeld Puur een stukje kennisdeling

[meino]

Dag Reinder

Bedankt voor je kennis. Ik moet eerlijk zijn, ik kom nog uit de old school (K&R) C tijd en houd zaken zo simpel mogelijk. Zoals het gezegde luidt "C provides all the rope to hang your self", daarom heb ik een hekel aan het gebruik van exotische constructies. Dus houdt ik het simpel en geef objecten als pointer door. Daarom was ik ook een grote fan van Java toen dat begin jaren 90 beschikbaar kwam, omdat dit sterk gestandaardiseerd was (objecten altijd by reference). Voor de liefhebbers raad ik de Obfuscated C competition aan

Groet Meino

[bask185]

Ik geloof dat we daar al eens eerder een discussie over hebben gehad

Nou je het zegt.. begint bij mij ook een belletje rinkelen. Straal vergeten  No further questions 

[Reinout van Rees]

Wat voorbeeldcode is altijd handig, bedankt.
Wat me opviel is dat je de servopin voor/na de beweging aan/uit zet, tenminste als ik goed genoeg keek. Dat werkt bij jou in de praktijk goed, kennelijk? Ik laat bij mij de pin continu actief, ik dacht dat dat bij servo's de bedoeling was. Bij mij gaat het om twee wissels, dat is misschien ook wat anders dan een seinpaal omdat een wissel echt netjes in positie gehouden moet worden?

(Over een paar maanden ga ik denk ik weer eens wat klussen, ik heb de arduino's al 7 jaar niet meer aangeraakt... Met te lange draden jitteren ze af en toe een beetje. Vandaar dat ik ook wat aan pin aan/uit zit te denken. Beter probleem v/d lengte bij de bron oplossen, maar goed )

Reinout

[bask185]

Dat werkt bij jou in de praktijk goed

Niet alleen bij Meino. Voor wissels is het vrij gebruikelijk om de servo's af te schakelen. Ik had het probleem dat ze of niet ver genoeg doordrukten of ze drukten te ver door en gingen brommen (met risico op doorbranden). En uiteraard iets van een verend iets gebruiken. Als een servo uit staat, heeft hij zoveel wrijving dat ze bij onze wissels wel willen blijven staan.

et te lange draden jitteren ze af en toe een beetje

Als je ze uit zet en er komt een trein voorbij, dan zal je zien dat ze heel ver gaan uitzwiepen. Dat kan je idd door kortere kabels oplossen. Meino hier gebruikt shielded kabels maar ik weet niet welke. Ik heb volgens mij ook ergens gelezen dat je om je kabels aluminium folie kan wikkelen. Een pull-up weerstand van een niet te hoge waarden zoals 4k7 dicht op de servo motor lost ook veel op. Die zorgt er ook voor dat de servo niet dat kleine schokje geeft wanneer je de spanning er op zet.

[offtopic]
Ik heb hiervoor een servoSweep class geklopt die de servo langzaam beweegt, die optioneel een punstuk relais kan aansturen halverwege de slag en die gebruik kan maken EEPROM om de standen inleerbaar te maken en hij kan ook onthouden wat de servo stand is. Met die pull-up weerstand in plek, blijft de servo gewoon op zijn plek bij opstarten en hij weet dan ook waar hij is.
[/offtopic]

Mvg,

Bas

[meino]

Ja ik schakel de servo's af als ze de eindstand bereikt hebben. Dit om jitter en brom te voorkomen. Wat ik wel doe, is dat een servo die in een eindstand staaat, periodiek (zeg na 10-30sec) even actief maak en opnieuw naar de geldende eindstand zet. Mocht een servo toch iets van plaats zijn veranderd dan wordt dat daardoor gecorrigeerd.
Verder had ik met een paar servo's problemen door lange signaal kabels die pulsjes oppikten. Die draden heb ik vervangen door afgeschermd signaaldraad. Hierna geen problemen meer gehad.

Groet Meino

[Reinout van Rees]

Bedankt voor de tips 

Reinout