Heeft er iemand een titel van een boek over hoe je een programma schrijft? Niet over de programmeertaal zelf en hoe loops etc in elkaar zitten. Maar hoe je het programma zelf aanpakt, opdeelt etc zodat het handelbaar blijft, afhandeling van fouten, checken van input, ... die dingen die maken dat het ipv 1 blok waar je later niets meer van snapt en moet herbeginnen
Heb wel leren programmeren op school (lang geleden) en de technische zaken zitten er nog wel in. Ik snap de datatypes, lussen, testen etc. Maar heb eigenlijk nooit meer gedaan dan zo van die typische oefeningen als "geeft 20 getallen in en druk de gesorteerde reeks af".
Ik wil beginnen aan de sturing van de treinbaan (die er ook nog niet is, maar dat is een ander verhaal). Dus ik ga moeten inlezen van files, inlezen van het bedieningspaneel, de beslissingen nemen en de io's sturen. Elk van die zaken op zich zie ik wel zitten. Probleem is vooral dat dit niet als een doorlopende bezigheid gaat kunnen doorgaan. Dus ik moet alles goed structureren zodat het handelbaar blijft. Maar dat heb ik nooit geleerd. Er zijn wel boeken van 500-600 pagina's maar dat is altijd weer eerst een hele uitleg van een of andere taal en dan enkele algemeenheden over datastructuren. Nooit iets over hoe degelijk opsplitsen, libraries, herbruikbaar en onderhoudbaar maken.
Alle suggesties welkom.
niet direct Johan.Ben daar ook al een tijdje op aan het sjikken (en ondertussen ook c++ aan het leren).
Analyse is een belangrijke stap in het ontwerpproces, dat merk je snel he.
Ik heb wel heel veel interessante boeken gevonden op http://it-ebooks.info/ (http://it-ebooks.info/)
Tot voor kort kon je het gros daar ook gratis downloaden. Ik zal (zodra m'n pc gerepareerd is, gebruik nu een
laptopje met lege harde schijf :-) ) ook eens in m'n oogst zoeken of ik wat vind dat je zou kunnen helpen.
Boeken...neen, ik ken er geen.
Wat jij wil doen heb ik zelf al wel ooit gedaan. Een werkend programma voor de besturing van een modelbaan.
Ik zie 1 enorm probleem bij u : je hebt nog geen baan !!!
Zo een programma is erg groot. Maar opgebouwd uit kleine stukjes. Je schrijft een stukje code en die code test je GRONDIG uit zodat dit stukje kan dienen als basis voor de verdere programmadeeltjes...Als je dan 2 deeltjes hebt ga je alweer testen hoe ze samenwerken, enz.
Het is hard werken en de weg is erg eenzaam.
Erik
mss moet je op zoek naar het boek Digitale modeltreinbesturing van M. J. Wijfels.Daar staan voorbeelden van besturing en programmatie in .Uitgegeven door elektuur met als isbn 90-70160-82-X.
Citaat van: Havoc op 01 maart 2017, 12:50:22 PM
Heeft er iemand een titel van een boek over hoe je een programma schrijft?
Ik vermoed dat er niet een 'universeel' boek is, tenzij schoolboeken. De meeste lectuur die ik ken is specifiek voor één of andere taal en begint vanf nul tot heel complex. Zelfs voor kinderen wordt er eerst een taal gekozen en dan beginnen ze in die taal te experimenteren.
Voor mij is programmeren een soort 'kunst'. Je kan er veel over lezen en leren maar je moet voor jezelf een manier vinden die je goed ligt, die je problemen met een minimum aan code oplost en die eventueel nog 'leesbaar' is voor anderen.
Mijn raad: kies een taal en begin eraan. In de 35 jaar dat ik programmeer ben ik al meerdere keren van taal veranderd en of je het nu hebt over bread, brot, pain of kruh, het blijft brood en in alle talen wordt het op min of meer dezelfde manier gemaakt en verorberd.
Citaat van: Havoc op 01 maart 2017, 12:50:22 PM
...Ik wil beginnen aan de sturing van de treinbaan...
Waarom warm water uitvinden?
Citaat van: bellejt op 01 maart 2017, 19:47:16 PM
mss moet je op zoek naar het boek Digitale modeltreinbesturing van M. J. Wijfels.Daar staan voorbeelden van besturing en programmatie in .Uitgegeven door elektuur met als isbn 90-70160-82-X.
Dat boek is ondertussen al wat decennia oud en gedateerd. Ik heb het wel nog als pdf...
De structuur van een programma bedenk ik de laatste tijd met een ander hulpmiddel: mind-mapping (dankzij een tip van Jean "SteamN")
Programmeren zelf: Kies inderdaad een taal, en begin er mee. Stap voor stap ...
Als het specifiek voor op een PC is met rekenpower in overvloed dan kun je enkele zaken gebruiken om het beheersbaar te houden.
Complexe zaken die op PC draaien -> OOP.... Alles (de gekste dingen) klassen van maken, en met objecten werken.
Elke klasse beschrijft de werking van een deel van je programma.... Goed elke methode documenteren (Javadoc, doxygen,...).
Git kan ook een handig hulpmiddel zijn als versiebeheersysteem... Elke keer je een nieuwe functie hebt die werkt "committen", als het daarna in het honderd loopt kun je eenvoudig terugdraaien naar de vorige versie. Gebruik een Master en een develop branch. In de Master hou je de versie bij waarvan je weet dat ze betrouwbaar werkt, de develop branch gebruik je om je nieuwe ontwikkelingen in bij te houden. Kun je aanvullen met Github account als je het opensource wil. (bij interesse schrijf ik hier gerust een tuto over). Om iets op een "andere manier" te proberen kun je ook met branches enzo werken. Ik hou het meestal vrij eenvoudig...
Ik ben er geen expert in, maar in principe zou je code bij complexe projecten "loosely coupled" moeten zijn. Dat laat toe om makkelijk wijzigingen door te voeren. Misschien eens zoeken op "loosely /tightly coupled code".
Ja, het is voor op een pc. Mijn kennis is beperkt tot gewone C en zo complex is het nu ook niet (denk ik).
Om een praktisch voorbeeld te nemen om de discussie wat concreter te maken, ik werk met een gekochte module die usb naar I2C, A/D en GPIO omzet (een library met basis interfacing ernaar was erbij). Dus ben ik begonnen met alles wat ik daarmee doe in een library te stoppen. Bedoeling is om die module "af te schermen" van het programma zodat wanneer die module niet meer te koop is enkel dat stuk moet herschreven worden. In theorie...
Dat leek me een logische en nuttige afsplitsing. Ook laat me dit toe om al iets te testen. Maar daar stopt het, ik zie niet direct andere punten die toelaten af te splitsen.
Ook heb ik de indruk dat ik meer ballast aan het schrijven ben dan nuttige zaken. Nu ja, "ballast" want het is bvb de voedingsspanning meten en zien of die niet teveel afwijkt alvorens de resets naar de bussen vrij te geven. Telkens de return value controleren als je iets met de module doet om te zien of je commando goed uitgevoerd is en indien nodig de foutboodschap afdrukken en afsluiten. Gewoon de usb openen en bvb de I2C instellen is enkele pagina's "rondom" een handvol commando's. Langs de ene kant lijkt dit overbodig (bretels, broekriem en stuk touw filosofie), langs de andere kant veel saai altijd hetzelfde dat nergens goed voor lijkt (waarschijnlijk tot de eerste keer dat er iets mis gaat).
Ik ga de tips die er al zijn verder bekijken. Dacht om een repository op te zetten (wel svn ipv git) maar voorlopig lijkt me dat wel heel complex vergeleken met wat er nu is. Langs de andere kant om eraan te beginnen als het programma al complex wordt is het misschien te laat.
Waarom het warm water opnieuw uitvinden? Goeie vraag met toch wel wat antwoorden (voor mij, misschien voor anderen):
- ik heb nog niets gezien dat me aanstaat. De meeste programma's gaan ervan uit dat je alles met DCC (of zoiets) doet. Wel, met de Z waarvoor dit bedoeld is gaat dat niet. Ik heb geen zin om die locs (vaak destructief) om te bouwen als er al decoders zijn.
- meeste programma's zijn ook bedoeld voor volledige automatisatie. De bedoeling is om alles te kunnen van volledige automatisatie tot "ondersteund" manueel. In dat geval doet de pc de beveiliging, leest wat ik wil vanop het bedieningspaneel en voert uit. Of laat een deel automatisch rijden en een deel manueel. (ik noem dat stationschef spelen)
- ik wil een pc maar die mag geen interface zijn. Dus niets te bedienen met toetsenbord, muis, scherm. Ik zit de hele dag achter zo'n ding en dan hoef ik het niet meer met mijn treinen. (wel ok voor op te starten alhoewel niet strict noodzakelijk)
- ben ook van opleiding electronica ontwerper (maar heb nooit software gedaan), dus dit is voor mij véél plezanter dan huisjes, boompjes, mannetjes en andere dingen :D
Johan,
Ik meen al ergens te hebben gelezen dat je bekent bent met Linux? In dat geval zou je volgens mij beter opteren voor een Rasperry Pi. Die heeft I²C, GPIO en AD aan boord. Je kan programmeren in oa C/C++ (maar moet je telkens compileren) en heel belangrijk: Python! Een interpreter taal die ook OOP toelaat. Zet een display en wat toetsen op je Pi en je kan aan de slag. Via VNC kan je vanop gelijk welke PC op je Pi werken.
Bij de chinaman zijn verschillende interface boards voor 2 appels en wat eieren verkrijgbaar.
Lectuur: massa's op het net te vinden!
Succes!
Johan,
een deel van het antwoord op je vraag zijn "Architectural design patterns", google maar even op deze termen.
In principe zijn dit "best practices" m.b.t. het oplossen van veel voorkomende software ontwerp problemen.
Focus ligt op abstractie en hergebruik.
Een eenvoudig en leuk voorbeeld is dit http://www.adamtornhill.com/Patterns%20in%20C%204,%20OBSERVER.pdf (http://www.adamtornhill.com/Patterns%20in%20C%204,%20OBSERVER.pdf)
Heel herkenbaar probleem waarbij je bvb één of meerdere functies periodiek wil aanroepen op basis van een timertick.
Als de functies die aangeroepen moeten worden in een Array opgeslagen worden in de timer bibliotheek dan is de oplossing per definitie niet flexibel.
Dit voorbeeld laat zien hoe het wel moet.
Zo zijn er tientallen (embedded) design patterns.
mvg,
Patrick Smout
Johan,
misschien ook nog even dit.
Voor object georiënteerd ontwerpen (OO) van software kan je beter eerst een cursus OO doorspitten en vervolgens je toeleggen op de taal ( C++, JAVA).
Het duurt even vooraleer je het OO denken in de vingers hebt. De taal aanleren is het makkelijkste deel.
Als je direct met de taal begint is de kans reëel dat je nooit OO gaat denken/ontwerpen en dan schrijf je wel C++/JAVA programma's maar deze zijn daarom nog niet direct OO.
mvg,
Patrick
Peter, het is voor onder linux. Een RPi is een optie, het programma zou mits hercompilatie gewoon moeten draaien. Ben nu ook gewoon in C bezig met CodeBlocks op de laptop. In theorie is met de goeie config ook compilatie voor Windows mogelijk, de driver voor de usb interface is daarvoor voorzien (door de fabrikant, dat is ver buiten mijn erf).
Patrick, heb het gedownload, ga dat eens lezen op de trein. Zoiets lijkt wat ik zoek. OO ben ik niet van plan. Nooit gedaan, ken het idee erachter maar om dat voor 1 toepassing ooit te gaan studeren is iets teveel denk ik. Ben vroeger wat met C bezig geweest, genoeg om de programma's die ik toen schreef nu niet meer te snappen. Vermits de lib voor de interface daarin beschikbaar is ga ik me daaraan houden. Heb ook nog de boeken etc. Dus dat moet lukken.
Havoc :
Er bestaan wel boeken om in een bepaalde taal te leren programmeren.
Zo ben ik ooit begonnen.
Om iets uit te testen moet je een baan hebben natuurlijk.
Verder een digitaal systeem en hier hangt veel van af hoe je commando's en terug meldingen enz moet verwerken.
Veel digitale systemen beschikken over een zg protocol een soort handleiding om met een interface en pc te werken.
Geen klein werk . Voor mij is het een hobby in een hobby .
Gr
Flip
Echt modern ben ik niet met mijn zelf geschreven trein besturing.
Maar vuur is ook niet zo modern en we gebruiken het nog steeds.
Volgens mij gaat het er om is het niet te moeilijk en werkt het goed.
Ik gebruik power basic nu nog zonder compiler ,maar het kan wel met
Ik vind het voordeel van deze basic dat je veel (bijna alles)even snel kan proberen.
Je schrijft iets ,druk start ,en ziet meteen of het wel of niet werkt.
Bij alle (bijna)programmeer talen moet je eerst een file maken ,die omzetten naar een exe file.
Dan proberen en als het niet gaat weer terug.
Wizigen ,weer exe file ,weer proberen
Vooral als niet 100% programmeur wordt ik daar dol van (kost tijd als water)
Power basic draait onder dos (stabiel) en kan echt alles wat voor een treinbesturing nodig is
Het is trager dan b.v.C ofC++ maar snel zat voor een baan met 5 treinen tegelijk .
Wel is het zo dat mijn baan nog voor 90% analoog loopt.
Trouwens voor seinen /wissels/ e,d is digitaal sturen eigenlijk onzin en nogal duur
decoders/terugmelders tegen wat draad (reken maar uit)
wim
https://nl.wikipedia.org/wiki/Jackson_Structured_Programming
nog van in den tijd van toen (als ik op school zat) maar zeker nog bruikbaar....
Citaat van: Flip op 09 maart 2017, 09:50:08 AMEr bestaan wel boeken om in een bepaalde taal te leren programmeren.
Zo ben ik ooit begonnen.
Om iets uit te testen moet je een baan hebben natuurlijk.
Verder een digitaal systeem en hier hangt veel van af hoe je commando's en terug meldingen enz moet verwerken.
Veel digitale systemen beschikken over een zg protocol een soort handleiding om met een interface en pc te werken.
Geen klein werk . Voor mij is het een hobby in een hobby .
Zo heb ik ook het grootste deel geleerd. Enig probleem is dat die boeken je de taal leren maar niet leren programmeren. En dat is nu het probleem. Hoe steek je vanaf het begin structuur in wat je doet zodat je klein klan beginnen en niet altijd alles moet herschrijven omdat je iets wil toevoegen.
Ik doe de hele interfacing zelf, er komen geen protocollen aan te pas. Heel de opzet is dat het eigenlijk een grote IO poort is. De I2C doet enkel port extending. Ik zet een bitje om iets te doen (led je branden, wissel omzetten) of lees een bit. Er zijn ook pwm's en die zet ik gewoon een richting en duty cycle.
Citaat van: ysbeer op 09 maart 2017, 12:01:08 PMEcht modern ben ik niet met mijn zelf geschreven trein besturing.
Maar vuur is ook niet zo modern en we gebruiken het nog steeds.
Volgens mij gaat het er om is het niet te moeilijk en werkt het goed.
Ik gebruik power basic nu nog zonder compiler ,maar het kan wel met.
....
Wel is het zo dat mijn baan nog voor 90% analoog loopt.
Trouwens voor seinen /wissels/ e,d is digitaal sturen eigenlijk onzin en nogal duur
decoders/terugmelders tegen wat draad (reken maar uit)
Modern gaat dat ook niet zijn. Eenmaal opgestart komt er geen scherm/muis/keyboard aan te pas. Ga wel in C werken, gewoon omdat ik niets anders ken, de boeken in de kast heb staan en ik voor de usb interface daar een lib voor heb.
De baan zelf is ook 100% analog. Geen loc decders etc. Gewoon er staat een trein in het schaduwstation op spoor x, ik wil die op spoor y in het station, wel dan zoekt de pc een rijweg uit, legt de wissels om en zet al de seinen. Ofwel laat de pc zelf de trein rijden, ofwel doe ik dat dan. Eigenlijk vervangt de pc bij mij een container of 2 relais.
Phillipe: die Jackson ga ik eens zoeken.
PS: ik dacht dit op een tablet tetypen, maar dat kl**eding wil altijd de woorden veranderen naar wat hij denkt dat "juist" is. Nogal lastig want ik typ nederlands, engels en frans. Die Androdinges trekt echt op niks. Dacht dat het op de telefoon aan het kleine toetsenbord en scherm lag maar het is gewoon slecht.
Persoonlijk zou ik iedereen die wil leren programmeren aanraden om in een wat hogere programmeertaal te beginnen dan c of c++. Daarin kan je sneller meer doen en bereiken en dat motiveert meer.
Eens je de gang van zaken hebt begrepen, kan je altijd van taal wisselen, dat gaat dan veel vlotter.
Ik persoonlijk vind python fantastisch, leesbaar (ook achteraf ;D) en makkelijk te schrijven
https://gathering.tweakers.net/forum/list_messages/1566266 (https://gathering.tweakers.net/forum/list_messages/1566266)
Citaat van: wouterdt op 10 maart 2017, 07:43:48 AM
Persoonlijk zou ik iedereen die wil leren programmeren aanraden om in een wat hogere programmeertaal te beginnen dan c of c++. Daarin kan je sneller meer doen en bereiken en dat motiveert meer.
Eens je de gang van zaken hebt begrepen, kan je altijd van taal wisselen, dat gaat dan veel vlotter.
Ik persoonlijk vind python fantastisch, leesbaar (ook achteraf ;D) en makkelijk te schrijven
https://gathering.tweakers.net/forum/list_messages/1566266 (https://gathering.tweakers.net/forum/list_messages/1566266)
Misschien. Ik ben van de oude stempel toen python en zo nog niet bestond en c++ net begon op te komen. Maar ik blijf ervan overtuigd dat je je taal moet aanpassen aan wat je wil bereiken. De grote hoop van wat ik moet doen is bitjes omzetten wat toch wel simpel is in c. Er is niets grafisch te doen en file io is niet meer dan een configuratie inlezen.
Misschien ipv C++ te gebruiken overstappen naar C#. De overstap is niet zo heel lastig, beide lijken nogal op elkaar. C# is zelfs gemakkelijker. Vind je ook onnoemelijk veel info van op het net, stapels ebooks enz.
Je vind ook genoeg video's op bv youtube of artikels op het internet ivm de architectuur voor een (dot net C#) programma.
C vind ik nog steeds de meest duidelijke taal, procedureel en uiterst expliciet: je zegt wat het doet, en het doet wat je zegt, met alle kemels en blunders. Nadeel, je moet echt alles weer uitspinnen tot elementaire logica en operaties.
Java vind ik een heerlijke taal wanneer je eerder object-gericht wilt werken. Heel concequent in syntax (c-like), fantastisch voor klein of middelgrote projecten, maar een ramp op het vlak van geheugenbeheer, met enorme verspilling en een rampzalige garbage collector.
C++ is mossel noch vis, geen C maar ook geen Java. C# is mossel noch vis maar gebonden aan Microsoft, dus C# ontgaat me compleet. C++ is wel een heel technsiche taal, performant en dirwijlls gebruikt voor technische ontwikkelingen (vb gaming) en grote, volumineuze projecten.
Python is dan weer uiterst impliciet. Je heb geen controle over hoe Python iets uitvoert. Er bestaan geen declaraties, dus heb je het raden naar of python je variabel als double, integer of string interpreteert. Dikwijls lopen jouw ideëen en pythons interpretaties aardig uit elkaar. Ook het collection management (loop'en door arrays en dergelijke) is erg fussy. Ik voel me niet comfortabel met Python en erger me dikwijls, maar jongeren blijken er wel snel mee weg te zijn.
Php leuk voor zeer kleine projectjes, maar ook erg fussy in z"n syntax. Maar voor piep-klein eenvoudige projectjes ben je snel klaar.
Assembler, Basic en Pascal zijn voor mij volledig passé, en hebben voor mij geen toepassingsgebied meer.
CiteerC# is mossel noch vis maar gebonden aan Microsoft, dus C# ontgaat me compleet.
Wat bedoel je met mossel noch vis? In de wereld waar ik in zit (ICT Consultancy) wordt bijna altijd C# gebruikt. Wij bouwen hier complexe en grote websites mee, gecombineerd met andere technologieën natuurlijk. Ook voor Windows desktop applicaties in het bedrijfsleven wordt heel veel C# gebruikt.
C# is echt wel een volwaardige programmeertaal waar je alle kanten mee uit kunt. Al hangt het wss wel wat af van wat je exact wil maken. ;)
Stieven, je hebt natuurlijk gelijk. Het is bij ons (Federaal Wetenschappelijk) dat C# geen meerwaarde heeft, maar in een ander omgeving zal het dat zeker hebben. ;)
Citaat van: Stieven76 op 10 maart 2017, 09:19:40 AM
CiteerC# is mossel noch vis maar gebonden aan Microsoft, dus C# ontgaat me compleet.
Wat bedoel je met mossel noch vis? In de wereld waar ik in zit (ICT Consultancy) wordt bijna altijd C# gebruikt. Wij bouwen hier complexe en grote websites mee, gecombineerd met andere technologieën natuurlijk. Ook voor Windows desktop applicaties in het bedrijfsleven wordt heel veel C# gebruikt.
Vermits dit niet voor een website is, onder linux geen .net is en helemaal geen desktop applicatie zijn dat dus zeker geen reden om een nieuwe taal te leren.
En het gaat niet over taal. Ik zoek over organisatie, structuur etc.
Citaat
Ik doe de hele interfacing zelf, er komen geen protocollen aan te pas. Heel de opzet is dat het eigenlijk een grote IO poort is. De I2C doet enkel port extending. Ik zet een bitje om iets te doen (led je branden, wissel omzetten) of lees een bit. Er zijn ook pwm's en die zet ik gewoon een richting en duty cycle.
Havoc : ik begrijp het niet . Een eenvoudig voorbeeld. Als je een digitaal systeem gebruikt kun je niet zonder enige uitleg hoe je bv een lok laat vooruit rijden en aan welke welke snelheid ?
Flip
De keuze van de taal hangt ook af van wat je wil doen.
Als je dicht op de hardware wil zitten (en dan vooral qua performance), dan ga je voor C(++) denk hierbij aan 3D engines voor games enzo. Je wil wel low level manipulaties doen maar qua performance neem ik aan dat het geen probleem zal zijn.
Wil je een taal waarin een rigide werkstructuur wordt afgedwongen met klasses/interfaces/... maar die toch meer gemak biedt ja dan kom je uit bij java(overal) of c# (Windows ) maar deze talen gaan dan wat meer resources vragen.
Ik persoonlijk vind dat de manier van werken die deze talen vragen (expliciet declaraties/gebruik van publieke en private data) te strikt voor een hobby projectje waar je toch zoveel mogelijk wenst te bereiken in je schaarse vrije tijd. Ze zijn beter in enterprise omgevingen met hele teams van programmeurs/Analysten/...
Talen zoals Python bieden veel vrijheid, en alles gaat vlot en je kan flexibeler en vlugger werken.
Ik denk trouwens dat de meeste talen bitwise operations ondersteunen, daar moet je je niet door laten afschrikken( https://wiki.python.org/moin/BitwiseOperators (https://wiki.python.org/moin/BitwiseOperators))
Maar het allerbelangrijkste is dat je moet de taal nemen waarin je comfortabel kan werken.
Als jij het liefst schrijft in C, dan maak je het gewoon in C.
Als je dit sneller kunt doen dan een andere taal leren en het daarin doen, doe dat dan.
Jij bent de Project leider, jij beslist ;D
Citaat van: Flip op 10 maart 2017, 17:30:10 PM
Citaat
Ik doe de hele interfacing zelf, er komen geen protocollen aan te pas. Heel de opzet is dat het eigenlijk een grote IO poort is. De I2C doet enkel port extending. Ik zet een bitje om iets te doen (led je branden, wissel omzetten) of lees een bit. Er zijn ook pwm's en die zet ik gewoon een richting en duty cycle.
Havoc : ik begrijp het niet . Een eenvoudig voorbeeld. Als je een digitaal systeem gebruikt kun je niet zonder enige uitleg hoe je bv een lok laat vooruit rijden en aan welke welke snelheid ?
Flip
Wat ik bedoel is dat ik geen protocol moet ondersteunen zoals DCC of S88 of wat er ook naar een DCC centrale moet geschreven en gelezen worden. De hele opzet is dat alles wat buiten de pc hangt gewoon I/O is. Dus een wissel omzetten wordt bitje x van poort y van ic z op "1" zetten, wachten tot bit a van poort b op adres c "1" wordt (terugmelding) en dan die eerste bit terug uitzetten. Als een loc een bepaalde snelheid moet hebben (uitgerekend door de pc) dan worden al de pwm uitgangen die aan die rijweg hangen op duty cycle q% gezet, dat is opnieuw een bepaalde waarde naar een bepaald register schrijven.
De protocollen omdie bits te gaan omzetten zoveel meter verder onder de baan doet de hardware.
Denk dat we hier even over verschillende definities van protocollen aan het praten zijn. Voor mij is de I2C op de bus een protocol, maar daar kom ik niet tussen behalve de max frequentie instellen 1x in het begin. Hoe het verband is tussen de clock en data hou ik me niet bezig.
OK laat maar eens weten wanneer uw eerste treinen hun rondjes rijden ;)
Vol automatisch dan met stop in station bediening van wissels en seinen .
Terug naar opstelstation enz;
Groeten
Flip
Vermits het 30 jaar geduurd heeft om een baanplan te maken zal dit niet voor morgen zijn. Soms is de reis waardevoller dan de bestemming...
Heb eens gezocht in m'n boekenkast, het meeste is taal specifiek, vooral dan Java en C++.
Deze 2 zijn algemeen:
- McConnell, S., Code Complete, Redmond, Microsoft Press, 1993, ISBN 1-55615-484-4
- Gamma, E., et al, Design Patterns; Elements of Reusable Object-Oriented Software, 20ste druk, Upper Saddle River, Addison-Wesley, 2000, ISBN 0-201-63361-2
Je leert er niet mee programmeren, maar er worden wel voorbeelden gegeven van hoe structuur in te brengen, en patronen te herkennen.
En ook, hoewel off-topic, zijn de volgende 2 wel in het Nederlands, en heel goed voor de beginner, dus vermeld ik ze maar:
- Warmer, J., Kleppe, A., Praktisch UML, s.l. Addison-Wesley, 1999, ISBN 90-6789-937-2
- van der Lans, R. F., het SQL leerboek; vijfde herziene uitgave, 5de druk, 3de oplage, Schoonhoven, Academic Service, 2000, ISBN 90-395-0755-4
Voor Engelstalige titels kan je de beoordelingen op bijvoorbeeld Amazon UK of US lezen.
En het helpt ook om eens op Wikipedia te zoeken/lezen: bijvoorbeeld https://nl.wikipedia.org/wiki/Model-view-controller-model (https://nl.wikipedia.org/wiki/Model-view-controller-model)
Waarbij de controller ook input ontvangt van de spoorbaan (bvb bezetmeldingen), en de view output naar de spoorbaan is (bvb seinen). Het model is je eigen data structuur, die de secties in je baan beschrijft/opsomt. De bezetmelders (input) laten je weten in welke sectie er iets gebeurt, en daar kan je de dan de gerelateerde seinen mee aansturen (output). De "fysieke" in- en output kan je loskoppelen met een aparte reeks functies (bibliotheek) van je eigenlijke programma code.
Dat is wat ik begrepen uit je bovenstaande vragen, maar ik kan me vergissen.
Citaat van: Werner op 27 maart 2017, 00:20:23 AM
En ook, hoewel off-topic, zijn de volgende 2 wel in het Nederlands, en heel goed voor de beginner, dus vermeld ik ze maar:
- Warmer, J., Kleppe, A., Praktisch UML, s.l. Addison-Wesley, 1999, ISBN 90-6789-937-2
- van der Lans, R. F., het SQL leerboek; vijfde herziene uitgave, 5de druk, 3de oplage, Schoonhoven, Academic Service, 2000, ISBN 90-395-0755-4
Een goed boek over UML lijkt me niet echt off-topic hoor. Een goed programma komt enkel tot stand dankzij een goed software ontwerp (design). Jammer genoeg wordt er te snel voorbij gegaan aan design. Coderen is immers zoveel leuker ...
Citaat van: Werner op 27 maart 2017, 00:20:23 AM
En het helpt ook om eens op Wikipedia te zoeken/lezen: bijvoorbeeld https://nl.wikipedia.org/wiki/Model-view-controller-model (https://nl.wikipedia.org/wiki/Model-view-controller-model)
Waarbij de controller ook input ontvangt van de spoorbaan (bvb bezetmeldingen), en de view output naar de spoorbaan is (bvb seinen). Het model is je eigen data structuur, die de secties in je baan beschrijft/opsomt. De bezetmelders (input) laten je weten in welke sectie er iets gebeurt, en daar kan je de dan de gerelateerde seinen mee aansturen (output). De "fysieke" in- en output kan je loskoppelen met een aparte reeks functies (bibliotheek) van je eigenlijke programma code.
Interessante blik op MVC (Model View Controller). Veelal wordt MVC geassocieerd met (lees toegepast op) gebruikersinterfaces (UI). Dit vind ik een verfrissend idee, heel origineel (al ben ik er nog niet helemaal uit of dit probleem nu hierdoor eenvoudiger wordt).
Ter aanvulling van m'n vorige post volgende boeken-tip "Design Patterns for Embedded Systems in C" van Bruce Powel Douglass uitgegeven door Elsevier. Op het einde van het boek is er ook een appendix met een overzicht(je) van de UML notatie. Niet voldoende om het te doorgronden maar wel een aanzet. Zoals hierboven al aangegeven, goed boek van UML is zeker ook een aanrader: "Real Time UML workshop for embedded systems" eveneens van Bruce Powel Douglass (bestaat ook nog een recentere versie van)
mvg,
Patrick Smout
Citaat van: Werner op 27 maart 2017, 00:20:23 AM
Heb eens gezocht in m'n boekenkast, het meeste is taal specifiek, vooral dan Java en C++.
Deze 2 zijn algemeen:
- McConnell, S., Code Complete, Redmond, Microsoft Press, 1993, ISBN 1-55615-484-4
- Gamma, E., et al, Design Patterns; Elements of Reusable Object-Oriented Software, 20ste druk, Upper Saddle River, Addison-Wesley, 2000, ISBN 0-201-63361-2
Je leert er niet mee programmeren, maar er worden wel voorbeelden gegeven van hoe structuur in te brengen, en patronen te herkennen.
En ook, hoewel off-topic, zijn de volgende 2 wel in het Nederlands, en heel goed voor de beginner, dus vermeld ik ze maar:
- Warmer, J., Kleppe, A., Praktisch UML, s.l. Addison-Wesley, 1999, ISBN 90-6789-937-2
- van der Lans, R. F., het SQL leerboek; vijfde herziene uitgave, 5de druk, 3de oplage, Schoonhoven, Academic Service, 2000, ISBN 90-395-0755-4
"Code complete" had ik ondertussen gevonden, maar wanneer ik de tijd ga vinden om die turf te doorworstelen is een ander paar mouwen. De andere referenties ga ik eens opzoeken.
CiteerEn het helpt ook om eens op Wikipedia te zoeken/lezen: bijvoorbeeld https://nl.wikipedia.org/wiki/Model-view-controller-model (https://nl.wikipedia.org/wiki/Model-view-controller-model)
Waarbij de controller ook input ontvangt van de spoorbaan (bvb bezetmeldingen), en de view output naar de spoorbaan is (bvb seinen). Het model is je eigen data structuur, die de secties in je baan beschrijft/opsomt. De bezetmelders (input) laten je weten in welke sectie er iets gebeurt, en daar kan je de dan de gerelateerde seinen mee aansturen (output). De "fysieke" in- en output kan je loskoppelen met een aparte reeks functies (bibliotheek) van je eigenlijke programma code.
Dat is wat ik begrepen uit je bovenstaande vragen, maar ik kan me vergissen.
Je zit er heel dicht bij. Het opzet was (is?) om te werken zoals een state machine: input lezen, verwerken, nieuwe output genereren. Enig verschil is dat er geen definitie vooraf van die states gaat zijn, enkel een soort "rule book".
De low-level IO loskoppelen van de rest was ik al van plan. Vooral omdat ik de software zoveel mogelijk onafhankelijk van de hardware wil maken. Dus het programma stuurt gewoon door hoe het de IO's wil (lijst adressen en bits/bytes) en de lib lost het op. Als het dan een hardware doosje van merk X of Y wordt of verschillende dozen, enkel de lib moet herwerkt worden. Met dat stuk ben ik al wat begonnen omdat de hardware getest moet kunnen worden dus dat komt al van in het begin van pas. Verder zit ik al aan versie 7 of zo van hoe de data te organiseren. Maar telkens als je dat een weekje laat liggen dan zie je er zo de gaten in. Probleem is dat elke versie tot nu toe meer gaten heeft dan een gruyère.