Citaat van: meino op 04 december 2019, 15:49:02Pointers kunnen als parameters aan methods door gegeven worden, de physieke objecten niet.Hoezo niet?
Pointers kunnen als parameters aan methods door gegeven worden, de physieke objecten niet.
Ik dacht al, geen commentaar van Timo
Zie de code. De S88 gebruikt 3 signalen, CLOCK, PS en RESET. Ik heb een ISR op de CLOCK en de PS signalen. RESET wordt niet gebruikt.
Weet jij wat het verschil tussen C en C++ is? Het niet initialiseren van variabelen in C is een van de grootse valkuilen. Ik kom uit de C wereld, daar leer je op de harde manier dat je variabelen moet initialiseren voor je ze kunt gebruiken. Maar dat zit er bij mij zo ingesleten dat ik dat ook in C++ doe.
byte eenArray[100] = {0};
Ze moeten gevoed worden vanuit het DCC signaal. Dat beide rails onderbroken moeten worden volgt uit de beschrijving en dat wordt ook bevestigd door mijn ervaring met deze detector.
Dat doe ik om te voorkomen dat deze routines direct aangeroepen worden. Ik dwing nu dat afgeleide klassen een attach() en heartBeat() method implementeren.
Hangt ervan af wat je flink noemt. 1,25 tot 1,50 maal trager uitlezen van de bus maar wel foutloos. Geen gedoe met 2 x uitlezen, tragere clock of andere pleisters. Geen slecht compromis, althans zo denk ik erover.
[...] Daarom gebruik ik de Canbus voor de echte communicatie en blijft de kabel voor de S88 communicatie zo kort mogelijk en gebruik ik een cat5 kabel (S88-n).
Per wissel heb ik een relaispaar nodig.
Dit schrijven gebeurd cyclisch, zodat ik iedere keer een nieuwe locatie gebruik.
Nouwja, als je gewoon alleen de geldigheid van de data checkt weet je wel dat je alleen goede data gebruikt maar niet of je data mist. Vandaar het "niet robuust". Maar zeker eens, liever wat trager en betrouwbaar dan snel en rommel.
Helemaal met je eens! Fysieke laag blijft hier ook extreem zwak. En denk dat het pas een beetje robuust is als er error correctie in zit. Maar eens dat de kans dat het fout gaat als je in ieder geval een checksum hebt (verkeerde data weg gooit en moet "wachten" op juiste data) met deze snelheden op een baan niet zo groot is.En de grap is eigenlijk dat je zou kunnen stellen dat DCC een per bit "checksum" heeft doordat elk bitje twee keer in een pakket zit. Helaas doet dat niets tegen het dan niet ontvangen van data dus robuust is dat ook niet Timo
Doelde er meer op dat het niet de standaard is bij stroomdetectie. Misschien bedoelde je het niet zo maar je beschrijving lijkt te zeggen dat stroomdetectie altijd twee onderbroken spoorstaven nodig heeft. Kan zijn dat de PMP7 wel moet (kan de documentatie niet vinden) maar bij de meeste volstaat één staaf.
Maar is het dan echt nodig dat iedere child een redefined versie daarvan heeft?
Waarom heb je geen wisselspanning gepakt? Of loopt hij daar niet zo mooi op? Ook aan een H-brug gedacht? L293D of Mini-L298/MX1508 ofzo.
Hoe hoe je bij waar in geheugen de laatste geldige stand staat? En neem aan dat je EEPROM.update() gebruikt?
Heb je specifieke Nano's met sd-kaart/geluid/wav optie? Of gewoon standaard ATmega328p Nano's?
Ik schrijf per update 3 bytes weg, 2 bytes met de wisselstanden gevolgd door een byte met een uniek bitwaarde die niet kan voorkomen bij de wisselstanden.
Gewoon standaard Nano's. Ik heb het idee om niet met wav files te werken, maar met een pink noise generator. Maar dat is nog allemaal experimenteel. Het kan zijn dat ik het uiteindelijk heel anders ga doen. eerst maar eens wat proberen.
Ligt er maar net aan wat je als fysieke laag gebruikt voor TCP/IP Hebben we het over ethernet over CAT dan zou ik willen zeggen dat het wel een vorm van error protectie (niet error correctie) door het differentiaal paar door de selectiviteit te verhogen en common noise te ondervangen. Ofwel, geen zwakke fysieke laag. Maar het gaat dan natuurlijk om de gehele stack, net als hier. Dus ja, het is pas echt robuust met TCP/IP (of een andere vorm met error correctie of ACK ofzo)
Maar dan kan je in 2 byte dus maximaal 15 wisselstanden opslaan.
Ken inderdaad de "servo truc" ook van Klaas.
Wat ik weer bijzonder vind in deze discussie dat Meino kennelijk heel diep in de software en de overdrachtsprotocollen zit, maar van redelijk simpele elektronica geen kaas heeft gegeten. Bij mij is dat precies andersom, ik volg dit draadje nog steeds, maar de helft snap ik geen bal van.
Overigens de truck met halve golf aansturing met diodes begrijp en ken ik ook. Maar ik had in mijn verzameling stekkervoedingen een 3V dc voeding liggen, en in kombinatie met mini schakelaars kon ik dat ook goed werkend krijgen.