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

[bask185]

Ik snap je elektronica topologie niet helemaal. Arduino's kunnen met een beetje elektronica DCC direct uitlezen, dat doet je DCC interface waarschijnlijk ook. Als je bijvoorbeeld met een arduino wissels wilt aansturen om geld te besparen dan zou ik ze direct aan de DCC hangen. Ik zie geen reden om je DCC berichten eerst te vertalen voor de can bus en dan om via je can bus wissels aan te sturen. Met een ringleiding heb je toch overal DCC om af te tappen. Je sein en draaischijf controller zijn er ook alleen maar om te ontvangen die kunnen dus ook op de DCC bus.

Misschien dat ik er in alle haast over heen heb gelezen, maar ik snap de losse 'bezetmelder controller' en de S88 interace niet, moet dat niet 1 geheel zijn? Ik snap overigens ook niet waarom je de S88 bus gebruikt. Nu moet ik zeggen, ik weet niet wat die niet-Marklin varianten kosten tegenwoordig, maar ik kon me alleen niet voorstellen dat het voordeliger is dan simpele stroomdetectie printjes te maken voor je arduinos en die te gebruiken voor je terug melding, want ja.. je hebt immers al je eigen can bus aangelegd.

Je MDRRC-II heeft ook een ingang voor de s88 bus. Dus tenzij je can bus gebruikt om grotere lengtes af te leggen dan mogelijk is aan de S88 (geen idee hoe lang deze kan), lijkt het me ook overbodig om ook hier je S88 bus te vertalen naar can en naar je centrale te sturen.

Ik zie dus geen duidelijk voordeel in je can bus implementatie behalve dat je misschien minder kabels hoef te trekken.

Zoals je weet ben ik zelf ook met mijn eigen rs 485 netwerk bezig. En dat heb ik zo ontworpen opdat ik A. zo min mogelijk draden wil leggen en B. om goedkoop uit te zijn en C. het is leuk om te doen  .

Ik heb 1 universeel arduino programma die ik kan configureren. En met de I2C bus kan ik tot max ~50cm in beide richtingen van de arduino het netwerk iets uitbreiden en IO extenders plaatsen voor seinen, terugmelders(massa detectie), magneet artikelen, knoppen voor wisselstraten, ontkoppelaars en servo drivers. En ik kan erg veel arduinos aan de rs485 bus hangen. Ik heb hier een motto voor bedacht: "Als je al een bus heb liggen voor arduino's die nagenoeg geen limitaties kennen, dan waarom nog  DCC of terugmeld bussen gebruiken?".

Ik heb van 1 arduino een DCC centrale gemaakt om kosten te besparen. Dat ding bestaat uit nog 10 euro aan onderdelen (excl de voeding). Ik stuur hem aan met een zelf gemaakte handcontroller over bluetooth voor ook een prikkie en ik hoef geen S88 dingen te kopen. Als klap op de vuurpijl gebruik ik ook mijn eigen computer programma die ik graag deel wanneer hij een beetje af is.

[meino]

Zoals je weet ben ik zelf ook met mijn eigen rs 485 netwerk bezig. En dat heb ik zo ontworpen opdat ik A. zo min mogelijk draden wil leggen en B. om goedkoop uit te zijn en C. het is leuk om te doen  .

Om de zelfde reden (het is leuk om te doen) ben ik met de Canbus begonnen.
Maar het is niet helemaal zonder reden geweest dat ik naar dit soort oplossing heb gezocht. Oorspronkelijk had ik inderdaad een aantal systemen die rechtstreeks aan het spoor hinngen en luisterden naar de DCC commando's. Maar in de praktijk had ik best veel problemen doordat een Arduino DCC commando's niet goed ontving. Ook locs hadden en hebben soms een probleem dat ze niet direct op bijv een snelheidswijziging reageren. Bij locs is dat niet al te problematisch omdat deze commando's continue herhaald worden. Echter accessory commando's (voor wissels en seinen) worden niet constant herhaald. Dit hing er ook vanaf waar de betreffende Arduino op het spoor was aangesloten. Vooral als bepaalde locs op de baan reden konden deze problemen best heftig zijn. Waarschijnlijk zetten sommige locs stoorsignalen op de baan. Misschien heeft het met de leeftijd van de locs te maken, de oudste is nu ruim 40jr oud en de jongste is ongeveer 28jr oud.
Ook voor de S88 interface, de Arduino die daar zorg voor droeg, controleerde ook alle bezetmelders. Dat had tot gevolg dat er een forse hoeveelheid aan kabels onder de baan  hing omdat alle aansluitingen van blokken naar een centrale locatie onder de baan gingen waar ook alle bezetmelders gelocaliseerd waren. Vrijwel alle bezetmelders werken met stroomdetectie, behalve twee die gebaseerd zijn op ali lichtsluisjes.

Oorspronkelijk kwam dus alles op een centrale plek onder de baan bij elkaar, maar dat werd veel te complex, en eigelijk niet meer uitbreidbaar. Ik heb toen besloten om alles via ringleidingen en een eigen bus te gaan doen. Ik heb dat uitgebreid in mijn draadje over Kranenberg beschreven. Oorspronkelijk had ik ook I2C gebruikt maar diverse anderen op dit forum vonden dat geen goed idee, in de discussie over mogelijke alternatieven werd ook de Canbus genoemd. Ook omdat de benodigde hardware goedkoop (1,30-1,60euro voor een MCP2515 kaartje) verkrijgbaar is. Verder zijn er op Internet ook een aantal bibliotheken te vinden om dit kaartje op hardware nivo aan te spreken zodat ik dat niet zelf in de Arduino hoef te coderen.
Het resultaat is nu, dat alle bezetmelder controllers (nu 6 stuks) zijn gedistribueerd geplaatst. Op diverse plekken onder de baan, zo dicht mogelijk bij de bezetmelders die zij controleren, terwijl de S88 interface dicht bij de MDRRC-II centrale zit, er zijn genoeg horror stories op dit forum te vinden over spook meldingen met S88, veroorzaakt door lange kabels.

Maar goed, uiteindelijk vond ik dit (als gepensioneerd IT architect/systeem ontwerper) ook wel erg leuk om terug te keren naar mijn roots en weer wat met C++ te doen.

Groet Meino

[Timo]

Hoi Meino,

Dit wordt een beetje een raar bericht, alvast excuses hiervoor. Maar ik had je eerste paar berichten gelezen en was begonnen met een reactie schrijven. Maar de PC waar ik dat op deed kreeg wat problemen dus is dat even blijven liggen Dus nu pak ik de draad weer op met wat ik had.

Allereest, leuk project! CAN is inderdaad wel goed toepasbaar op de modelspoorbaan denk ik. Heb de modules ook wel liggen maar nog nooit mee gespeeld

Allereerst vind ik het wel erg bijzonder dat twee modules sneller werken dan een enkele Maar goed, zelf de modules nog steeds niet gebruikt. Maar ik keek even snel door de datasheet en kon zo snel niets vinden over kristal instellingen. Kan je die dus zomaar verhogen?

Ter verduidelijking, LSB 0 betekent Least Significant Bit heeft index 0. Dat betekend dat de bit nummering in het ID veld van rechts naar links gaat (analoog aan de bitSet() functie in een Arduino schets).

Ook analoog aan ons dagelijkse 10-tallig stelsel werkt. Maar zodra het om niet 10-tallig gaat willen sommige opeens van links naar rechts getallen lezen

En even "zeuren", gebruik const ipv aan macro (#define) Betere errors berichten, handelt echt als een variabele, type safe etc. Snap niet helemaal dat macro's nog zo veel gebruikt worden

En heb je een reden om new te gebruiken ipv gewoon het object te definiëren? Kan je gewoon de . notatie gebruiken etc.

Vooral als bepaalde locs op de baan reden konden deze problemen best heftig zijn. Waarschijnlijk zetten sommige locs stoorsignalen op de baan.

Toevallig loc's met LoSo 4's op de baan?

En ach, CAN en RS485 hebben overeenkomsten, beide om te beginnen differentiaal. CAN kent alleen ook al een protocol en topology implementatie waar RS485 alleen een pijp met bytejes is. Maar ben het mee eens dat een decentrale oplossing inderdaad heeeeel veel werk kan schelen En inderdaad, S88 is niet zo heel gunstig voor afstand. S88n al wat beter maar blijft een wat gevoelig systeem, ooit geïntroduceerd om kosten efficiënt te zijn.


Timo

[bask185]

En even "zeuren", gebruik const ipv aan macro (#define) Betere errors berichten, handelt echt als een variabele, type safe etc. Snap niet helemaal dat macro's nog zo veel gebruikt worden

"handelt echt als een variabele"  -> werkt zodoende niet in een case label. Daarom ben je imo het beste af met enums.

Also een #define voor een IO kan prima. Mensen zeggen ook dat je een macro met hoofdletters moet tikken, zodat je kan zien dat het een macro is. Dat kan je beschouwen als een soort type-safety.

"Snap niet helemaal dat macro's nog zo veel gebruikt worden" > macro's worden door veel mensen ten onrechte als "kwaadaardig" beschouwd  en dat slaat nergens op. Een macro is slechts een van velen tools die we hebben in o.a. C en C++. En zoals elke tool komt een macro met voor- en nadelden. Als je iemand dood mept met een hamer, dan is de hamer niet "kwaadaardig" maar "kwaadaardig" gebruikt. Als je hem gebruikt om een spijker in een plank te slaan, is het de perfecte tool. Dus een nadeel van de hamer: je kan er iemand dood mee meppen. Voordeel: je kan er spijker mee in hout tikken.

Het zelfde principe gaat ook op voor macro's. Je kan er de meest onduidelijke code mee maken en jezelf in een debug nachtmerrie werken. Maar je kan ze ook gebruiken om; overhead te verminderen, code te comprimeren en om code leesbaarder te maken.

Ik gebruik zelf macro's om state machines mee op te bouwen. Ik heb dan een lijstje met een enum van states en een switch-case die functie calls uitvoert. De woorden 'case' en 'break' worden door de macro vervangen door 'State'. De functie call wordt vanuit een if statement gedaan en wacht tot de state in kwestie true returnt. Tevens heb ik bij deze macro ook nog ingebakken dat de state automatisch geprint wordt. Dat is soms best handig. Met de # operator zet ik de enum om in een string en met de ## doe ik een functie call naar   someState + F()

Code: [Selecteer]

#define State(x) break; case x: if(prevState != state) {print("State ");print(#x); print("\n\r");prevState=state;} if(x##F())


[meino]

Dag Timo

toch leuk dat je nog even een reactie geeft.

Allereerst vind ik het wel erg bijzonder dat twee modules sneller werken dan een enkele Maar goed, zelf de modules nog steeds niet gebruikt. Maar ik keek even snel door de datasheet en kon zo snel niets vinden over kristal instellingen. Kan je die dus zomaar verhogen?

Ansich werken ze niet sneller, maar veel betrouwbaarder. Ik denk dat het met de firmware op de MCP2515 chip zelf te maken heeft. Als je een kaartje gebruikt voor zowel zenden als ontvangen dan valt de (betrouwbare) throughput terug naar 10-20 berichten per seconde. Ik speel met het idee om de clockchip op deze kaartjes te vervangen (is nu 8Mhz, maar de chip kan tot 20Mhz aan). Ik weet alleen niet of de andere componenten op het kaartje dat ook aankunnen. Maar omdat het gebruikte kaartje slechts 1,5 euro kost, doe ik niet moeilijk en gebruik 2 kaartjes voor de systemen die ontvangen en zenden.

En even "zeuren", gebruik const ipv aan macro (#define) Betere errors berichten, handelt echt als een variabele, type safe etc. Snap niet helemaal dat macro's nog zo veel gebruikt worden

Dat zeuren geeft niet, ik weet wel waarom. Maar het zal wel te maken hebben met mijn leeftijd. Ik heb het vak geleerd op een EL X8 met Algol, later jaren als systeemprogrammeur op mainframes in BAL gewerkt. In 83 in het UNIX gebeuren verzeild. Alles deed je met macro's en #defines. Zelfs toen ik begin 90 in Berkeley werkte (C, C++) deden we nog alles met #defines en macro's. Kortom oude gewoontes slijten slecht. Overigens gebruik ik echt wel const's en enums, maar #defines gebruik ik ook nog bewust, vooral als (pre)compiler directives,

En heb je een reden om new te gebruiken ipv gewoon het object te definiëren? Kan je gewoon de . notatie gebruiken etc.

Ja, objecten kun je slecht als parameter in een method gebruiken, dus probeer ik zoveel mogelijk met pointers te werken. Met new kan ik een object creeeren in de constructor van een ander object. Bijkomend voordeel is isolatie.

Toevallig loc's met LoSo 4's op de baan?

Nee, ik heb geen locs met geluid. De probleemgevallen ware een Lima mat46 met de oorspronkelijke rondmotor en een paar Roco locs met de oude, zilveren motor.

En ach, CAN en RS485 hebben overeenkomsten, beide om te beginnen differentiaal. CAN kent alleen ook al een protocol en topology implementatie waar RS485 alleen een pijp met bytejes is. Maar ben het mee eens dat een decentrale oplossing inderdaad heeeeel veel werk kan schelen En inderdaad, S88 is niet zo heel gunstig voor afstand. S88n al wat beter maar blijft een wat gevoelig systeem, ooit geïntroduceerd om kosten efficiënt te zijn.

Yep, daarom ook voor de MCP2515 gekozen omdat de onderste lagen al aanwezig zijn, inclusief CD (Collision Detectie). Dat moet je met RS485 allemaal nog implementeren. Ik heb genoeg kennis en ervaring om dat te doen, maar bij de Can bus is dat allemaal al gedaan, wel zo gemakkelijk.
 
Groet Meino

[meino]

@timo & @bask185

Ik ga zaterdag naar Houten digitaal. Is er een kans om jullie te ontmoeten? Rond 12:00 zal ik wel de BNLS tafel proberen te vinden.

Groet Meino

[bask185]

Per toeval ga ik heen. Ben er nog nooit geweest. Het is ook m'n verjaardag dus ik moet ff grondig shoppen.

Edit ik ga op zondag

[Timo]

Allereest het jammere:

Ik ga zaterdag naar Houten digitaal. Is er een kans om jullie te ontmoeten? Rond 12:00 zal ik wel de BNLS tafel proberen te vinden.

Helaas was ik deze week aardig druk en heb een paar lange dagen gemaakt. Ik zie dit bericht dus helaas nu pas. Had ik hem eerder gezien was ik denk ik nog wel naar Houten gereden. Maar ben bang dat de kroketten nu al wel op zijn

werkt zodoende niet in een case label.

Hoe bedoel je? Kan je een voorbeeld geven?

Overigens wel met je eens dat een enum voor "state"-achtige zaken, waar de echte waarde van je "variabele" er niet toe doet, een enum een mooiere oplossing is. Maar om een pin nummer nu als enum te definiëren 

Also een #define voor een IO kan prima.

Zeg ook niet dat het niet kan  Zeg alleen dat er een beter/nieuwer alternatief is.

Mensen zeggen ook dat je een macro met hoofdletters moet tikken, zodat je kan zien dat het een macro is. Dat kan je beschouwen als een soort type-safety.

Met het laatste ben ik het niet eens. Het is wel een clue voor jezelf maar heeft niets met type-safe te maken maar met style. Maar een macro voor constanten gebruiken is naar mijn idee een beetje als een Tesla met alle opties kopen maar nooit met autopilot rijden. Waarom zou je jezelf niet laten helpen door de compiler ipv alleen op jezelf te vertrouwen? Alle C++ toevoegingen aan C zijn er alleen maar om jou te helpen en je intentie duidelijk te maken aan zowel de compiler als een ieder die de code leest. En de eerste beloont je dan ook met duidelijkere errors en warnings.

Ja, macro's hebben nog steeds hun plek in code, in 99% van de gevallen voor pre-processor zaken. Maar ook voor die dingen wordt er hard gewerkt aan betere alternatieven binnen C++ zodat men af kan van de niet eenduidige search-and-replace functie die een macro geeft.

macro's worden door veel mensen ten onrechte als "kwaadaardig" beschouwd  en dat slaat nergens op. [...]

Zie het ook absoluut niet als kwaadaardig. Zie het alleen als het gebruik van een handboor terwijl er ook een mooie accu-boormachine in je gereedschapskoffer ligt

[...] De woorden 'case' en 'break' worden door de macro vervangen door 'State'. [...]

Tja, van dat soort constructies ben ik dan ook geen fan. Naar mijn idee maakt dat code namelijk niet leesbaarder (door geen standaard code te zijn) maar is het alleen een soort lui-heid (niet negatief bedoelt!). Maar goed, dat is een kwestie van stijle (en zolang iemand een stijl consequent toepast zal ik daar geen opmerking over maken) en geeft inderdaad een geval aan waar geen C++ alternatief is. (Afgezien van je enum ) Maar dat betekend niet dat er andere gevallen zijn waar je wel meer voordeel uit moderne C++ toevoegingen kunt halen.

En ja, naar mijn idee is de switch() nog een zwak punt in C++

Dus nogmaals, vind (nog ) niet dat een macro per definitie slecht is. Maar voor gevallen waar een C++ alternatief beschikbaar is zie ik die vaak wel als "beter" door de toegevoegde meerwaarde zoals het laten zien van je intentie, code safety en betere compiler berichten. Maar ja, ook met een handboor krijg je een gat in beton, kost je misschien alleen wat blaren

Ansich werken ze niet sneller, maar veel betrouwbaarder. [...]

Maakt dat ik er toch ook eens mee moet gaan spelen. Maarja, altijd te veel projectjes lopen Scheelt dat de donkere dagen binnen er weer aan komen, misschien dat ik eens een opstellingkje kan maken. Moet ik eerst de modules wel weer vinden

Dat zeuren geeft niet, ik weet wel waarom. Maar het zal wel te maken hebben met mijn leeftijd. Ik heb het vak geleerd op een EL X8 met Algol, later jaren als systeemprogrammeur op mainframes in BAL gewerkt. In 83 in het UNIX gebeuren verzeild. Alles deed je met macro's en #defines. Zelfs toen ik begin 90 in Berkeley werkte (C, C++) deden we nog alles met #defines en macro's. Kortom oude gewoontes slijten slecht. Overigens gebruik ik echt wel const's en enums, maar #defines gebruik ik ook nog bewust, vooral als (pre)compiler directives,

Viel me vooral op omdat je wel de overstap naar objecten hebt gemaakt maar wel veel macro's gebruikte. Zoals hierboven ook uitgelegd dus vooral een voorstander van omdat ik denk dat het een nuttige tool is, niet omdat het anders onmogelijk of fout is. Maar ik zie bijvoorbeeld newbies zo vaak verdrinken in cryptische error messages of bijwerkingen van macro's.

Ja, objecten kun je slecht als parameter in een method gebruiken, dus probeer ik zoveel mogelijk met pointers te werken.

Bedoelde meer, waarom een pointer en niet gewoon het object zelf in je eigen class opnemen?

Ik heb genoeg kennis en ervaring om dat te doen, maar bij de Can bus is dat allemaal al gedaan, wel zo gemakkelijk.

Kan ik het alleen maar mee eens zijn 


Timo

[meino]

Allereest het jammere:Helaas was ik deze week aardig druk en heb een paar lange dagen gemaakt. Ik zie dit bericht dus helaas nu pas. Had ik hem eerder gezien was ik denk ik nog wel naar Houten gereden. Maar ben bang dat de kroketten nu al wel op zijn

Er komen nog wel vaker beurzen.

Viel me vooral op omdat je wel de overstap naar objecten hebt gemaakt maar wel veel macro's gebruikte. Zoals hierboven ook uitgelegd dus vooral een voorstander van omdat ik denk dat het een nuttige tool is, niet omdat het anders onmogelijk of fout is. Maar ik zie bijvoorbeeld newbies zo vaak verdrinken in cryptische error messages of bijwerkingen van macro's.

Dat mag ook wel voor een IT architect die vanaf de midden jaren 90 een fanatieke advocaat van OO is geweest. Als je eenmaal het licht hebt gezien, dan begrijp je niet meer hoe je het daarvoor deed. Overigens was dat ook de tijd dat we met JAVA begonnen en daar speelt het gebruik van macro's niet. Het is jammer dat een Arduino niet het platform is om echt puur "message driven" en in OO te ontwikkelen. Maar dat heeft ook wel weer zijn charme.

Bedoelde meer, waarom een pointer en niet gewoon het object zelf in je eigen class opnemen?

Omdat deze objecten weer hun eigen initialisatie parameters hebben (de CS pin) en ik in de constructor van de CanBus niet extra verborgen parameters wil meegeven. De mcp2515 objecten zijn de parameters voor het CanBus object. Dat deze laatste klasse een CS pin als parameter gebruikt is niet relevant voor de CanBus klasse zelf.  Daardoor ontkoppel ik de creatie van het mcp2515 object van het CanBus object en zou ik makkelijk dat kunnen wijzigen. Als ik het mcp2515 object in de CanBus klasse initialiseer, dan creeer ik een verborgen object (en relatie) in de CanBus zelf. Dat behoort IMHO niet tot een goede ontwerp/programmeer stijl.

Groet Meino

[Timo]

Er komen nog wel vaker beurzen.

Dat mag ook wel voor een IT architect die vanaf de midden jaren 90 een fanatieke advocaat van OO is geweest.

Dat is al wel even ja Zelf nooit een fan van Java geworden. Ook al was dat het vak op de uni waar we de basis van OO mee kregen.

Omdat deze objecten weer hun eigen initialisatie parameters hebben (de CS pin) en ik in de constructor van de CanBus niet extra verborgen parameters wil meegeven.

Maar dat is toch ook gewoon mogelijk met het object zelf?

Dus

Code: [Selecteer]

mcp2515 *sender = new mcp2515(10);
//wordt
mpc2515 sender(10);Of via de initializer list als je een object in je klasse wilt gebruiken. Of wil je geen objecten in je klasse hebben?

Nogmaals, puur uit nieuwsgierigheid. Niets fout aan pointers Viel me gewoon op door alle structure dereferences.


Timo

[meino]

Nogmaals, puur uit nieuwsgierigheid. Niets fout aan pointers Viel me gewoon op door alle structure dereferences.

Voor een deel is het mijn stijl van werken. Maar die is ook gevormd door ervaring. In C++ (erfenis van C) kun je object via een referentie (pointer) of direct benaderen, verschil is de aanroep van een method, met en . of met een -> In de praktijk levert dit vaak verwarring op (niets is erger dan na dagen door legacy code spitten, om er dan achter te komen dat er een & is vergeten om een adres door te geven. Probleem was ook dat het meeste van de code nog K&R volgde, dus moesten we in GNU C het nivo van error checking nogal laag zetten).
Vandaar mijn voorkeur om zoveel mogelijk met pointers te werken, omdat je dan de referentie altijd kunt gebruiken, ook als parameter in methods. Een object "by value" doorgeven in een method kan nu eenmaal niet. Dit is ook wat mij sterk aansprak in JAVA omdat daar, afgezien van primitieven (int, float, etc) alles "by reference" is en dus de verwarring die soms bij C en C++ kan voorkomen, minder gebeurt.

Groet

[Timo]

Hoi Meino,

Bedankt voor de toelichting Zelf ben ik wat later begonnen en was C++ er al volwaardig. Ook heb ik zelf meer een elektrotechniek achtergrond dan informatica

Maar moet je dan zo vaak je objecten als parameter gebruiken? Van wat je gepost hebt leek het er meer op dat je gewoon een object aanmaakt in je constructor en deze in een pointer van je klasse opslaat. Ofwel, onderdeel van je klasse maakt. Of mis ik iets


Timo

[meino]

Maar moet je dan zo vaak je objecten als parameter gebruiken? Van wat je gepost hebt leek het er meer op dat je gewoon een object aanmaakt in je constructor en deze in een pointer van je klasse opslaat. Ofwel, onderdeel van je klasse maakt. Of mis ik iets

Hoi Timo
Het heeft niet eens zoveel te maken met het doorgeven van een object in een method aanroep. Het is meer stijl en standaardisatie. Maar het feit dat ik de Mcp2515 objecten niet binnen de CanBus klasse aanmaak, heeft te maken met het spreiden van verantwoordelijkheid wat hoort bij een goed OO ontwerp.

Het Mcp2515 object isoleert het mcp2515 kaartje en zijn bijbehorende interface bibliotheek. Het Mcp2515 object houdt zich puur bezig met het zenden en ontvangen van berichten, het bijhouden van de send queue (vanwege het reduceren van de hoeveelheid berichten per seconde), verder is hij verantwoordelijk voor de initialisatie en configuratie van de onderliggende interface bibliotheek.

Het CanBus object daarentegen is met dat soort zaken niet bezig, hij heeft kennis van de berichttypen, beheert de bijbehorende interrupt routines etc. Verder kan hij verschillende configuraties aan, alleen zender, alleen receiver of zender en receiver. Verder zou het kunnen dat ik in de toekomst een ander type interface kaart zou willen gebruiken i.p.v. een mcp2515 kaart. In dat geval moet er een andere klasse komen die dat ondersteund. Dus zou de Mcp2515 eigenlijk een interface definitie moeten zijn zodat ik daar makkelijk een andere klasse achter kan plaatsen.
Verder als ik de Mcp2515 objecten binnen de constructor van het CanBus object zou maken, dan moet ik kennis van al deze objecten in de CanBus klasse inbouwen. Dat betekend dat in de constructor van het CanBus object ik informatie moet verstrekken over wat hij moet fabriceren. Maar dat is informatie die op geen enkele wijze relevant is voor de werking van het CanBus object, een situatie die je in een goed ontwerp moet proberen te voorkomen.

Kortom het heeft veel te maken met hoe ik een OO ontwerp maak en hoe ik graag werk. Maar dat is wel gevormd in een omgeving waar de heap size niet relevant was (4GB of groter). Helaas is een Arduino niet het meest geschikte platform om dit zonder restricties te kunnen doen (2Kb voor de heap is erg weinig). Aan de andere kant, als je weet wat je beperkingen zijn, kom je toch een heel eind.

Groet Meino

[Timo]

Hoi Meino,

Bedankt voor deze lange toelichting

En ben het met je eens dat het je de vrijheid geeft. Of je die altijd nodig hebt Misschien was ik zelf eerder voor een reference gegaan.

En hoe wil je dat makkelijk opvangen als je wel een andere library wilt ondersteunen, er is dan denk ik niet een makkelijke virtual class / interface voor de mcp2515-class of wel?

Nogmaals, iet om te zeuren! Puur interesse omdat jij er wel echt over na hebt gedacht. Zit nog wel eens op het Arduino forum en daar zie ik juist vaak mensen alleen maar dingen doen zonder gedachten omdat ze het zomaar ergens zagen en het dus zo MOET


Timo

[meino]

En hoe wil je dat makkelijk opvangen als je wel een andere library wilt ondersteunen, er is dan denk ik niet een makkelijke virtual class / interface voor de mcp2515-class of wel?

Dag Timo

op dit moment is de Mcp2515 een klasse en geen interface, maar als ik een andere library zou willen ondersteunen, dan hoef ik slechts de Mcp2515 klas aan te passen, of een nieuwe klasse te schrijven met de zelfde interface. Vandaar de scheiding tussen de Mcp2515 en CanBus klassen. Waarbij de Mcp2515 klasse de CanBus klasse isoleert van de specifieke hardware en bijbehorende bibliotheek. Op dit moment is het zeker nog geen volwassen systeem, dan had ik gelijk de Mcp2515 als een interface of base class uitgewerkt, helaas is dat in C++ wat minder intuitief dan in JAVA, dus het is gebouwd direct op wat ik nu gebruik en nodig heb. Het enige is dat ik wel achterdeurtjes in het ontwerp open hou om dit later eventueel makkelijk te kunnen doen.

Overigens dit zijn leuke discussies, maar ik realiseer me dat dit aan de de meeste forumleden voorbij zal gaan. Tenslotte is dit een treintjesforum, dus misschien verder gaan via PB's?

Groet Meino