BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: AP3737 op 03 February 2024, 10:52:27
-
Hallo allemaal
Ik heb een vraag aan de Loconet experts. Even wat achtergrond over mijzelf: ik heb ervaring met het bouwen van DCC en RS-Bus decoders, en heb voor beide ook Arduino libraries ontwikkeld (https://github.com/aikopras).
Nu ben ik wel benieuwd naar Loconet, maar heb mijn twijfels over het gemak en betrouwbaarheid van zelfbouw Loconet decoders. Ik weet dat er een (mrrwa) Arduino Library is, en dat er aan versie 2 wordt gewerkt. Mijn indruk is dat iedere hobbyist deze mrrwa library gebruikt. Of zie ik dat verkeerd, en zijn er ook alternatieve libraries?
Voor zover ik weet, werkt de mrrwa library alleen op een 328, 2560 of ESP. Niet op nieuwere Microchip processoren, zoals bijvoorbeeld dxcore (die een stuk beter en goedkoper zijn). Mijn indruk van de mrrwa library is dat deze behoorlijk veel vraagt (CPU, maar vooral timing) van de 328. Als ik het goed begrijp, vereist Loconet dat er bijvoorbeeld niet meer dan 2 microseconde verstrijkt tussen detectie van Carrier Sense en het begin van zenden. Voor zover ik weet, gebruikt de mrrwa library daarom voor het zenden ook geen UART, maar wordt ieder bit afzonderlijk door de software verstuurd. Alhoewel zoiets prima zal werken op een dedicated processor, heb ik mijn twijfels of zoiets wel altijd betrouwbaar werkt als er ook andere tijdkritische processen draaien, zoals DCC decoding. Ik vraag me bijvoorbeeld af hoe Loconet in centrales wordt geïmplementeerd: gebruikt men hiervoor een eigen Loconet processor? Zijn er ook decoders die voor Loconet een eigen processor gebruiken, of hebben alle decoders slechts één processor waarop Loconet samen met de overige functies draaien?
Als je Loconet betrouwbaarder en efficiënter zou willen bouwen, zou je het CSMA/CD deel in hardware kunnen uitvoeren. Een goed voorbeeld hiervan zag ik bij Mikael Ejberg, die een prototype heeft ontwikkeld op basis van de AVRDA (dxcore) processoren (https://www.ejberg.dk/portfolio/loconet-avr-da/). Dat lijkt me een mooie aanpak, maar het aanpassen van de mrrwa library lijkt me niet eenvoudig. Ook het zelf schrijven van een nieuwe library lijkt me, gezien de complexiteit van het Loconet protocol, niet eenvoudig. Hoe kijken jullie daar tegenaan?
Ik ben benieuwd naar jullie reacties,
Groet, Aiko
-
In mijn LocoNet communicatie gebruik ik heel veel hardware reeds ingebouwd in de Microchip µC. En ik volg niet letterlijk alles zoals beschreven in LocoNet Personal Edition. (ze hebben het veel te complex gemaakt) En Mikael Ejberg ken ik, ik heb hem getipt om zijn baudrate generator te resetten net voor verzenden om zo tot minder dan 2µs detectie te bekomen tussen Carrier Sense en het begin van zenden.
Hieronder een schema waarop je kan zien dat ik maar 5 weerstanden en transistor (en µC uiteraard) nodig heb om te communiceren met LocoNet. Daarna het door mij gebruikte programma voorgesteld als flowchart.
Succes,
Geert Giebens
(https://live.staticflickr.com/65535/53505346372_883a0443b9_h.jpg) (https://flic.kr/p/2pw5TnW)
LocoNet Interrupt (https://flic.kr/p/2pw5TnW) by Geert Giebens (https://www.flickr.com/photos/152152583@N08/), on Flickr
(https://live.staticflickr.com/65535/53506380478_1afebdcd98_h.jpg) (https://flic.kr/p/2pwbbMm)
LocoNet flowchart (https://flic.kr/p/2pwbbMm) by Geert Giebens (https://www.flickr.com/photos/152152583@N08/), on Flickr
-
Hallo Geert
Leuk jouw bijdrage hier te zien. Ik had je al eerder gezien op het Belgische Modelspoormagazine forum, YouTube, GitHub en natuurlijk je suggestie om de baudrate generator opnieuw te starten. Dank ook voor de flow chart; ik moet echter wel toegeven dat ik die nog wat langer moet bestuderen voordat ik het helemaal begrijp.
Op je GitHub site heb ik alleen ASM (en HEX) files gevonden; heb je zelf een Loconet library in assembler geschreven? Indien dat zo is, dan lijkt me dat een hele klus. Of heb je toch delen van de mrrwa bibliotheek gebruikt? Je schrijft dat alleen een low-priority interrupt nodig hebt voor de synchronisatie tussen hard- en software. Weet je ook toevallig hoeveel tijd deze interrupt nodig heeft?
Groet, Aiko
-
Ik heb een vraag aan de Loconet experts. Even wat achtergrond over mijzelf: ik heb ervaring met het bouwen van DCC en RS-Bus decoders, en heb voor beide ook Arduino libraries ontwikkeld (https://github.com/aikopras).
Nu ben ik wel benieuwd naar Loconet, maar heb mijn twijfels over het gemak en betrouwbaarheid van zelfbouw Loconet decoders. Ik weet dat er een (mrrwa) Arduino Library is,
Gemak vind ik prima. Die library werkt opzich wel goed. Alleen slots wisselen met de throttleClass is een beetje tricky, maar wel te doen. Het tricky gedeelte ligt ook niet aan de library zelf ;)
Betrouwbaarheid, daar kan ik niks over zeggen, want ik heb geen baan met heel veel loconet verkeer. Die arloco dingen van Nico lijken het volgens mij goed te doen.
Als je Loconet betrouwbaarder en efficiënter zou willen bouwen, zou je het CSMA/CD deel in hardware kunnen uitvoeren.
Hoe bedoel je dat precies? Leuk dat je een chip met interne opamp hiervoor kan gebruiken. Maar dat doet volgens mij weinig aan de betrouwbaarheid. Dat ene opampje en die paar weerstandjes. Ik zie daar geen probleem in.
Je had ook over DCC decoding. Maar een apparaat wat al loconet heeft. Waarom zou die ook DCC moeten decoden? Misschien voor een sniffer ding, bedenk ik me nu. In ieder geval. Zowel DCC decoderen (als encoderen) en loconet dat loopt allemaal over interrupts. Zolang jij in je applicatie code niet te lange for-loops plempt, is zelfs de 328 snel genoeg om beide te doen. Ik heb nog geen noodzaak gezien om van de 328 af te stappen. En ik betaal nu €1,40 voor die dingen. Ik weet niet wat zo'n dxcore kost?
Wat wel een interessante chip zou zijn, zijn die dingen die op een pico raspberry zitten. Je kan voor die IO pinnen een soort state machines maken die parallel aan je hoofdprocessor lopen. In theorie zijn ze perfect voor dingen zoals SPI, I2C, serieel, loconet, xpressnet, s88 etc. De pinnen kunnen dan zelf de bussen regelen met een berichten buffer ed en ze genereren dan een interrupt als je iets moet inlezen of kan verzenden ofzo. Ik heb alleen zelf geen ervaring met die dingen en ik kan je niet vertellen of je ze werkend kan krijgen voor loconet.
Mvg,
Bas
-
Als experiment heb ik een project gemaakt met een ATmega328 icm de mrrwa library, dat werkt prima tot nu toe, ook LNCV werkt mooi :)
Qua eigen hardware verder heb ik niet zo veel ervaring met LocoNet, ik zit meer aan de PC applicatie kant, over de inhoud van LocoNet berichten weet ik meer :) (Ook over berichten buiten de personal edition.)
-
. En ik betaal nu €1,40 voor die dingen.
Heb je daar een link van Bas? Voor die prijs heb ik ze nog niet gezien.
-
Ik koop zelf uitsluitend nog hier (https://jlcpcb.com/parts/componentSearch?searchTxt=atmega328p), ik laat ze dan meteen op de print bestellen en ik koop vaak aantallen van 30 stuks. Ik zie dat de dagprijs alweer op €1,75 staat.
En anders kan je bij alie zoeken. Voor commerciële apparatussen raad ik het niet aan natuurlijk. Maar voor de DIY'er...
https://nl.aliexpress.com/w/wholesale-atmega-328p.html?spm=a2g0o.home.search.0
(https://nl.aliexpress.com/w/wholesale-atmega-328p.html?spm=a2g0o.home.search.0)
https://nl.aliexpress.com/item/4000463929286.html (https://nl.aliexpress.com/item/4000463929286.html)
De DIP is 60ct duurder.
Bas
EDIT:
Hier bij train-science ondersteunen we de DIY waar mogelijk ;). Ik heb hier een 'bare mininum' loconet printje.
link naar gerbers (https://github.com/bask185/Train-Science-DIY/tree/master/PCB/Lnet)
(https://trainsciencecom.files.wordpress.com/2023/05/afbeelding-1.png)
(weerstand waardes staan onder de weerstanden)
-
Dank je Bas (y)
-
Als eerste wil ik jullie bedanken voor de reacties.
Misschien is het goed iets meer achtergrond informatie te geven. Ik denk aan een grote verenigingsbaan, met vele honderden wissels, seinen en terugmelders. De bekabeling kan meerdere tientallen meters lang zijn. Bij een groot aantal decoders zal de maximale stroom die Loconet kan leveren snel overschreden worden (LocoNet B: 200mA, LocoNet T: 500mA). ik weet dat er ook iets is als een LocoHubSupply, maar ook daar is 500mA het maximum. Servo's kunnen pieken van 1A trekken, dus zeker als een hele wisselstraat met servo's wordt bediend, kan je in problemen komen. Je wilt daarom misschien aparte voedingslijnen leggen, en/of de accessory commando's via DCC sturen. Één van de mogelijke problemen die dan kunnen ontstaan zijn aardlussen. Daarom zou ik ook altijd optocouplers nemen voor het ontkoppelen van de Loconet TX en Rx. Dat is allemaal wel oplosbaar.
Zolang jij in je applicatie code niet te lange for-loops plempt, is zelfs de 328 snel genoeg om beide te doen.
Stel je wilt Loconet in combinatie met de NMRA DCC library gebruiken. Een DCC Interrupt kost op de 328 (UNO, Nano) ongeveer 15 µs, en op nieuwere processoren zoals de 4809 (Nano Every) zelfs 22 µs (zie https://github.com/aikopras/AP_DCC_library/blob/main/extras/Performance_MegacoreX.md (https://github.com/aikopras/AP_DCC_library/blob/main/extras/Performance_MegacoreX.md). Tot overmaat van ramp kennen de nieuwe (MegaCoreX en DxCore) processoren geen nested interrupts meer. De eis dat je binnen 2 µs op een carrier sense moet reageren, zal je dus niet altijd halen.
Andere voorbeelden van libaries die veel tijd kunnen kosten, zijn LiquidCrystal en MobaTools; Bij de laatste library kan de interrupt routine voor steppers tot wel 200µs kosten.
Leuk dat je een chip met interne opamp hiervoor kan gebruiken. Maar dat doet volgens mij weinig aan de betrouwbaarheid. Dat ene opampje en die paar weerstandjes. Ik zie daar geen probleem in.
Het gaat niet zozeer om die paar componenten die je al of niet op de print moet plaatsen, maar dat je de tijdkritische functies niet meer door de processor laat uitvoeren, maar uitbesteed aan hardware. Dat kan met moderne microcontrollers, zoals de AVRDA processoren die Mikael Ejberg gebruikt, en ook met de PICs die Geert gebruikt. In dat geval kan je de processor voor andere taken gebruiken, zoals DCC decodering, LCD aansturing of MoBaTools.
Wat wel een interessante chip zou zijn, zijn die dingen die op een pico raspberry zitten.
Vast, maar draaien de bestaande Arduino libraries daar wel op? Als je veel libraries moet herschrijven, lijkt me dat een mega klus.
over de inhoud van LocoNet berichten weet ik meer :) (Ook over berichten buiten de personal edition.)
Goed te weten bij wie ik eventueel later terecht kan ;D ;D
Groet, Aiko
-
Op je GitHub site heb ik alleen ASM (en HEX) files gevonden; heb je zelf een Loconet library in assembler geschreven? Indien dat zo is, dan lijkt me dat een hele klus. Of heb je toch delen van de mrrwa bibliotheek gebruikt? Je schrijft dat alleen een low-priority interrupt nodig hebt voor de synchronisatie tussen hard- en software. Weet je ook toevallig hoeveel tijd deze interrupt nodig heeft?
Hoe lang de interrupt erover doet is niet zo belangrijk. Bijna alles is hardware gestuurd, receiver start automatisch en de transmitter zorgt voor correcte afhandeling te verzenden byte. Linebreak wordt o.a. herkend via framing error receiver, en dat de datalijn vrij is wordt o.a. herkend via RCIDL (receiver is idle) en nog wat andere hardware gedoe. Het low-priority Interrupt programma moet enkel ervoor zorgen dat data bytes klaar staan of verwerkt worden. (wel zeer eenvoudig voorgesteld…) Het high-priority interrupt kan gebruikt worden om correcte servo pulsen op te wekken (indien nodig)
De ASM code wordt nu omgezet naar C zodat deze op meerder Microchip µC ingezet kan worden.
Geert
-
Je hebt helemaal gelijk, mits je het CSMS/CD deel aan de hardware overlaat, dus zoals jij (en Mikael) doen.
Mooi te horen dat je met een C implementatie bezig bent. Ik ken de PIC18 ontwikkel omgeving niet, maar vermoed dat die nogal afwijkt van Arduino (of PlatformIO). Toch zou het mooi zijn als er een generieke Loconet library zou komende die op moderne processoren zou draaien, welke CSMA/CD in hardware kunnen uitvoeren.
Ik heb net nog even naar de Loconet2 library gekeken, die misschien als basis zou kunnen doen, maar "schrik" iedere keer weer als ik de licentie voorwaarden lees (zie Loconet2.h).
Groet, Aiko
-
Vast, maar draaien de bestaande Arduino libraries daar wel op? Als je veel libraries moet herschrijven, lijkt me dat een mega klus.
Nou, ik ging ff zoeken. Die pico pi heeft een Cortex M0, maar Arduino lijkt die chip ook te ondersteunen.
https://docs.arduino.cc/software/ide-v1/tutorials/getting-started/cores/arduino-samd/ (https://docs.arduino.cc/software/ide-v1/tutorials/getting-started/cores/arduino-samd/)
Ik denk dat je met die boards ook er mee wegkomt om de loconet communicatie uit te besten aan hardware. Alleen nul ervaring hier, je kan het op hun forum vragen dan word je meestal wel goed op weg geholpen.
maar "schrik" iedere keer weer als ik de licentie voorwaarden lees (
Ik weet niet wat je wilt doen? Als jij gewoon thuis dingetjes maak, kan je doen en laten wat je wilt. Dan zet je je git repo op private en ben je klaar. Als je lapjes code wilt delen, kan je digitrax even een mailtje sturen. Die doen niet zo heel moeilijk als jij iets van code voor.. een handregelaar online zet ofzo. Uhlenbrock zou ik de moeite niet voor nemen. Ik gebruik die LNCV opcodes van ze, ik heb ze gemaild maar no problemo allemaal. Ik weet eigenlijk niet wat ze nog meer hebben toegevoegd. En als nodig kan je ook 'hun' delen uit de library slopen...
Als je printen wilt verkopen die naar loconet ruiken (een shield bijvoorbeeld) zoals ik ga doen, dan heb je wel een licentie nodig van digitrax.
Mvg,
Bas
-
Volgens mij is het patent op LocoNet verlopen? Loopt af na 20 jaar en kwam al eens ter sprake op LocoNet-Hackers Forum.
Geert
-
@Geert: interessante opmerking dat het patent wel eens verlopen zou kunnen zijn. Ik zal eens op het LocoNet-Hackers Forum zoeken of ik daar meer over vind.
@Bas: mijn toepassing zou een grotere modelbaan vereniging zijn. Om continuïteit te garanderen en niet afhankelijk te zijn van een enkele persoon, zou ik graag alle hard- en software ontwerpen open source willen hebben. Natuurlijk zou je binnen de vereniging je eigen, gesloten Git infrastructuur kunnen bouwen, maar dat zou niet mijn ideaal zijn.
Je suggestie om "van scratch te beginnen" op een pico pi is natuurlijk mogelijk, maar ik zou dan liever willen voortbouwen op de ervaringen die anderen al hebben gemaakt op basis van AVRDx of PIC.
Mijn oorspronkelijke vraag ging echter vooral op de ervaringen met de mrrwa. Heeft iemand met die library al eens performance metingen uitgevoerd, en er bijvoorbeeld een logic analyser aangehangen? Of bestaan er alteratieve libraries?
Groet, Aiko
-
Ik had even een mail opgegraven. Ik had ooit aan digitrax gevraagd of ik een terugmelder online mocht zetten, zowel hard- als software.
Antwoord hierop
With regards to some of your other questions, there are a wide array of LocoNet resources available including Hardware and Software. The only time we request something be licensed is when that item is for sale.
Lijkt mij vrij duidelijk. Online gooien ;D
Ik heb nog geen performance meting gedaan. Ik denk dat ik de terugmelder ga afronden en er 10 ga bestellen. Dan kan ik die vanuit software bezetmeldingen laten triggeren en dan moet ik alleen iets bedenken om de performance goed te testen. Wellicht een simpele arduino logger ofzo? Zal binnenkort het ontwerp naar m'n DIY repo verplaatsen.
Bas
-
Dank voor de mail. Dat lijkt helder.
Heb je een logic analyzer? Dat was één van de beste aankopen die ik afgelopen jaren heb gedaan. Sinds ik dat ding heb, test ik daarmee al mijn software (en hardware) uitvoerig. Ik loop dan vaak tegen dingen aan die ik zo niet verwacht had.
Groet, Aiko
-
Ik heb er wel een, al 5 jaar. Hij zit nog steeds in het plastic ::). De laatste keer dat ik er een gebruikte was iets van 8j terug om een I2C bus te monitoren. Ik dacht dat die van mij 5V tollerant was, ik durf daar niet zo maar een loconet of rs485 bus aan te hangen zonder extra elektronica.
-
Ik wilde al een lange tijd een paar van die dingen afmaken en op een plankje schroeven. Ik bedacht me nu iets vet slims, om gewoon geen plankje te pakken maar wat tape te gebruiken. If it works...
Ik heb afgelopen week de RJ12s er op gezet en vanavond een aangepast programma er in geschoten. De enige aanpassing is dat elke melder om de 10s alle 'states' toggle't van stand.
(https://i.imgur.com/UuAQeAx.jpg)
In dit fimpje zie je eerst 5 bezetmelders die exact tegelijk hun 16 statussen willen opsturen. Je ziet dat dat niet helemaal goed gaat. Halverwege het filmpje trek ik er 1 tussen uit en dan doen de overige 4 het wel goed.
https://www.youtube.com/v/b3mqEoR5gBw
Nu zijn 5 x 16 melders die in dezelfde milliseconde (en misschien wel microseconde, het begin althans) verstuurd moeten worden ook wel erg uitzonderlijk. Als ik naar een normale iTrain baan kijk, dan heb ik er wel vertrouwen in dat de throughput meer dan toereikend is. En ik vind het toch netjes dat 4 nagenoeg identieke apparaten die op bijna exact hetzelfde tijdstip willen versturen er toch uit kunnen komen.
Wat code betreft, heb ik dit lapje wat ik continu aanroep
void updateOccupancyStatus()
{
static uint8 index ;
if( io[index].newState != io[index].oldState )
{
LN_STATUS status ;
uint8 type = io[index].type ;
uint8 address = io[index].address ;
uint8 state = io[index].newState ;
if( type == ACCESSORY ){status = LocoNet.requestSwitch( address, 1, state ) ;
status = LocoNet.requestSwitch( address, 0, state ) ; }
else {status = LocoNet.reportSensor( address, state ) ; }
//status = LocoNet.reportSensor( address, state ) ; }
if( status == LN_DONE ) // if message has transmitted succesfully...
{
io[index].oldState = io[index].newState ; // ...update status
if( ++ index == nInputs ) index = 0 ; // and go to next object
}
}
else
{
if( ++ index == nInputs ) index = 0 ; // if object's state has not changed, go to next object.
}
}
Telkens als een melder van state verandert, moet die de bus op. Dat doe ik dan zo snel als mogelijk. Na het aanroepen van het verzenden bekijk ik de status. En is die dan LN_DONE, dan verhoog ik de index naar de volgende bezetmelder. Zo wordt er geen bezetmelder overgeslagen.
Ik ben alleen nog aan het bedanken, wat nog handig is om te testen.
Hoewel ik niet denk dat het zal helpen, is om een vaste interval toe te voegen tussen iteraties van die functie. Ik dacht als ik bijvoorbeeld om de 10ms of zelfs 20ms die functie aanroept, dat het dan misschien beter zal gaan. Het kan ook niet echt kwaad om die tijd er tussen te zetten, dus baadt het niet, schaadt het niet.
Ik denk ook een kleine tijds differentiatie toevoegen van enkele milliseconde. Ik dacht misschien als apparaat 1 op 10000ms stuurt en apparaat 2 op 10010ms (en dit voor alle 7) dat het dan misschien veel beter gaat.
En in plaats van 16 melders per keer, wil ik alle 7 apparaten slechts 1 melder laten sturen.
Mvg,
Bas
-
Je maakt mooi spul Bas maar dat plakband vind ik persoonlijk een beetje jammer voor de uitstraling.
-
Hi Bas
Leuk (y)
Nu zijn 5 x 16 melders die in dezelfde milliseconde (en misschien wel microseconde, het begin althans) verstuurd moeten worden ook wel erg uitzonderlijk.
Hmm, daar ben ik niet zo zeker van. Op mijn eigen baan heb ik tussen de 60 en 70 (zelfbouw) terugmelders (RS-Bus). Als de terugmeld bus actief wordt (spanning op de bus is aan, centrale geeft aan dat hij ready is), sturen alle terugmelders zo snel mogelijk de huidige status (bezetmelding, wissels) terug. De RS-Bus is een polling bus, dus dat gaat wel goed. Loconet is echter CSMA/CD, en dan zou het wel eens niet goed kunnen gaan. Daarom zou ik bij Loconet altijd een kleine vertraging (afhankelijk van het Loconet adres??) inbouwen.
Je geeft aan dat je test met 5 hardware devices, en per hardware device 16 software melders. Dat is volgens mij toch wat anders dan 80 hardware melders, verspreid over een lange bus. In dat laatste geval zou je op 80 plaatsen CSMA/CD toepassen, en nu op "slechts" 5. Bij CSMA/CD speelt de looptijd van het signaal namelijk ook een rol: hoe langer het duurt tussen het versturen van een signaal en het detecteren van dat signaal, hoe groter de kans op collissions. Als je slechts een heel korte bus hebt, dan is de kans op collisions veel kleiner.
Als je het echt goed wil testen, dan zou je toch eens een scoop op de bus moeten zetten. Daarnaast zou je de loconet bekabeling lang moeten maken (200 meter?), en de decoders over de bus verspreiden.
Even wat hardop rekenen en een getallen voorbeeld (ik hoop dat ik me niet verreken en een factor 1000 mis zit ;))
Lichtsnelheid is 300000 km/s = 300km/ms = 300m/us.
De snelheid van een electrisch signaal in een koperen geleider is ongeveer 0,7 x de lichtsnelheid. Dus in 1us legt het signaal ongeveer 200m af. De Loconet spec zegt, dat je binnen 2us nadat je carrier free detecteert, moet beginnen met zenden. Je hebt dus (bij 200m kabel) een "onzekerheids interval" van 3us waarbinnen collissions kunnen voorkomen. In de praktijk zal deze tijd waarschijnlijk hoger zijn, omdat je hard/software misschien niet snel genoeg is (een 328 ISR kost meerdere us).
Ik zou daarom precies willen weten hoe snel de hard/software is, dus een scoop en logic analyzer gebruiken om te meten. Een redelijke combinatie USB scoop/analyser kost by Ali 60 Euro, dus dat valt best mee.
-
erg leuk om te volgen! helaas mis ik de kennis om mee te doen maar lees het graag (y)
Je maakt mooi spul Bas maar dat plakband vind ik persoonlijk een beetje jammer voor de uitstraling.
daar komt hij wel achter als over een tijdje die tape helemaal vergaan is en vastgekoekt is aan zijn printjes ;)
-
Bas,
Ik ken de CAN specs niet goed genoeg om daar iets specifieks over te kunnen zeggen. Maar het aloude Ethernet is mij iets beter bekend. Dat werkt ook met CD (colection detection). Daar is het voorgeschreven dat als een node een collision detecteert, dat hij een random tijd moet wachten voor hij het opnieuw gaat proberen. Dat is om er voor te zorgen dat er geen race conditie ontstaat tussen twee of meer nodes die op het zelfde moment willen zenden. Zit dat wel goed in je code? Vijf zenders die op het zelfde moment willen zenden vind ik niet veel. Ik werk ook met de CAN bus en heb bij het opstarten wel meer nodes die tegelijkertijd gaan zenden. Tot nu toe geen problemen gezien, maar ik werk dan wel met standaard CAN bus kaartjes waar de kaart het hele gebeuren afhandelt.
Groet Meino
-
Dat plankje was ook niet echt mooi hoor :P. Ik had ff snel iets nodig om ze bij elkaar te houden, m'n kid sliep al dus dat betekent geen accuboor. Ik denk dat ik ze alsnog op het plankje zet. Ik moet er alleen rekening meehouden dat mijn pogopins er op gaan voor updates.
Daar is het voorgeschreven dat als een node een collision detecteert, dat hij een random tijd moet wachten voor hij het opnieuw gaat proberen
Dit is volgens mij ook de enige manier waarop je identieke apparaten die gelijktijdig dingen gaan verzenden, toch in goede banen kan geleiden.
Ik denk sws dat ik alle apparaten ook hun beginstand laat opsturen, waarbij ik een adres afhankelijke opstart vertraging inbouw. En tevens wanneer een ik een status binnen krijg die != aan LN_DONE dat ik eventjes wacht met een random tijd. Het start adres kan je in arduino's randomSeed() functie proppen.
Ik heb 20 melders totaal liggen, dus ik vlam nog even door 8).
void updateOccupancyStatus()
{
static uint32 interval = 1 ; // default interval of 1ms
REPEAT_MS( interval ) // best macro ever, creates an interval
{
static uint8 index ;
if( io[index].newState != io[index].oldState )
{
LN_STATUS status ;
uint8 type = io[index].type ;
uint8 address = io[index].address ;
uint8 state = io[index].newState ;
if( type == ACCESSORY ){status = LocoNet.requestSwitch( address, 1, state ) ;
status = LocoNet.requestSwitch( address, 0, state ) ; }
else {status = LocoNet.reportSensor( address, state ) ; }
//status = LocoNet.reportSensor( address, state ) ; }
if( status == LN_DONE )
{
io[index].oldState = io[index].newState ;
if( ++ index == nInputs ) index = 0 ;
interval = 1; // if status is OK, maintain 1ms interval
}
else
{
interval = random( 5, 50 ) ; // in event of collission, wait with random interval
}
}
else
{
if( ++ index == nInputs ) index = 0 ;
}
}
END_REPEAT
}
Tijd voor middagwandeling (y)
Mvg,
Bas
-
Het start adres kan je in arduino's randomSeed() functie proppen.
Dat lijkt me een goed idee. De random() functie is niet erg random, wel bruikbaar.
Oh ja, nog wat, op welke snelheid stuur je de CAN aan. De MCP kaartjes die ik gebruik werkten voor geen meter op 1Mbit, dus staat bij mij de bus op 500Kbit.
Groet Meino
-
Het is loconet, meino. Geen Can. Ben wel van mening dat Can beter of eigenlijk makkelijker is. Loconet draait op ik dacht 16knl nog iets bps uit mn hoofd. iig niet zo snel als 500k ;D
-
LocoNet is 16k5 baud, niet erg snel, voordeel is wel dat je makkelijk aftakkingen kan en mag maken :)
CAN is zeker een mooi systeem (een auto zit er vol mee), dan wordt al die collision stuff geregeld in hardware :) Nadeel is wel dat het relatief duur is (qua componenten) t.o.v. andere bussen.
Voor de meeste tranceivers "mag" je "maar" tot 32 nodes.
Er zijn wel wat apparaten met een CAN bus, maar die hebben allemaal een eigen standaard vermoed ik.
Z21 heeft CAN, Marklin CS heeft CAN, ECoS link is ook CAN gok ik en dan is er nog LCC (https://dccwiki.com/Layout_Command_Control).
Nu kun je dat in theorie wel mixen op een bus, maar dan moet je wel een node hebben die dat allemaal snapt, misschien ben je dan beter af met een gateway naar een meer common systeem zoals LocoNet.
-
Ik heb een toepassing gevonden voor... een goto ;D.
void setup()
{
LocoNet.init(LNtxPin) ;
loadEEPROM() ;
randomSeed( io[0].address ) ; // <---
startupDelay = random( 1, 1000 ) ; // <---
for( int i = 0 ; i < nInputs ; i ++ ) input[i].begin() ;
pinMode(13, OUTPUT) ;
}
void loop()
{
waitStartDelay : if( millis() <= startupDelay ) goto waitStartDelay ; // <---
Ik moet hier een macro voor maken voor in m'n macros.h ;D
#define startupDelay( interval ) PIGS_CAN_FLY: if( millis() <= interval ) goto PIGS_CAN_FLY;
Ik vind loconet wel erg fijn omdat die kabels zo makkelijk zelf te maken zijn. ::) Dat kost zo weinig
Mvg,
Bas
-
@Bas
ipv zelf van alles en nog wat zelf (proberen) te bedenken, zou je ook de LocoNet-PE eens goed kunnen doorlezen. Daar staat precies in wat je moet doen en laten mbt het verzenden van pakketjes... ook wanneer je een carrier detecteerd, wanneer een collision, wat dan te doen en hoe dat op te lossen c.q. moet retry-en.
Overigens, zelf als je dat uit die LocoNet-PE allemaal implementeert, krijg je nog steeds bij een "groot" systeem, dat het voorgeschreven aantal retry's bij collision, niet voldoende is en je dus toch pakketjes gaat missen.
Grtzz,
Karst, met inmiddels 20 jaar ervaring in deze materie ;)
-
Dat is pas de volgende stap. Deze decoders gebruiken de open source mrrwa library van Alex Shepperd en dit draadjes gaat precies daar over.
-
waitStartDelay : if( millis() <= startupDelay ) goto waitStartDelay ; // <---
Ik moet hier een macro voor maken voor in m'n macros.h ;D
BS;
while( millis() <= startupDelay ){}
Doet het zelfde en is nog korter en duidelijker. Ken u klassieken, zeker nooit https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf gelezen.
Alleen slechte programmeurs hebben het goto statement nodig.
Groet Meino
-
Ken u klassieken, zeker nooit https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf gelezen.
Alleen slechte programmeurs hebben het goto statement nodig.
;D ;D ;D
Jeugdherinneringen :-) Uit de tijd dat de Dijkstra notes (natuurlijk, handgeschreven) per post werden verstuurd en je status werd bepaald hoe lang het duurde totdat je een kopie kreeg.
Aiko
-
BS;
while( millis() <= startupDelay ){}
Doet het zelfde en is nog korter en duidelijker.
Kan nog een paar karakters korter.
while (millis() <= startupDelay);
Ken u klassieken, zeker nooit https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf gelezen.
+1 (y) :D :D
-
Ik heb ook geen goto nodig maar ik het leuk om voor zo'n simpele oneliner een goto te gebruiken. Juist omdat het gebruik zo zeldzaam is. Vooral verwerkt met die macro. Dit is mijn vorm van programmeer humor. Ik ben het wel wel met je eens dat dit specifieke voorbeeld geenzins beter is dan een while loop.
#define startupDelay( interval ) PIGS_CAN_FLY: if( millis() <= interval ) goto PIGS_CAN_FLY;
void loop()
{
startupDelay( interval ) ;
..
..
Zo heb ik mijn check of eeprom nog goed is:
uint8 checkMyDeadBeef()
{
uint32 DEADBEEF ;
EEPROM.get( DEADBEEF_ADDRESS, DEADBEEF ) ;
if( DEADBEEF != 0xDEADBEEF )
{ DEADBEEF = 0xDEADBEEF ;
EEPROM.put( DEADBEEF_ADDRESS, DEADBEEF ) ;
return 1 ;
}
return 0 ;
}Als ik vroeger een infinite while loop nodig had voor in int main():
bool PIGS_CAN_FLY = true ;
..
while( PIGS_CAN_FLY == TRUE ) {
Alleen slechte programmeurs hebben het goto statement nodig.
Dit vind ik dus BS. Ik hoor wel vaker van die vage statements.
"Je moet altijd maar 1 return aan het einde hebben"
"alle lokale variabele moeten altijd boven in je functies gedeclareerd worden"
"macro's zijn slecht"
"static is slecht"
En mijn all-time-favourite:
"Het maakt niet uit welke accolade stijl je kiest, zolang je maar consistent bent".
Een goto en een macro. Het zijn gewoon tools en het is aan ons om de juiste tools voor de juiste klussen te gebruiken. Als iemand een hamer gebruikt om iemand mee te vermoorden, dan is het niet de hamer die slecht is maar degene die de hamer hanteert.
Het is alleen zo dat heel veel programmeurs niet snappen hoe je leesbare code moet neerkalken. Dat is echt een kunst. En een goto is helaas wel een grove tool die zich makkelijk laat misbruiken voor de verkeerde klussen (feitelijk zoals ik nu gedaan heb).
Dus om te voorkomen dat we mensen de apocalyps laten coderen met hun hamers, komen wij met die regels en ontnemen wij hen de hamers. Maar ik weet hoe ik een hamer kan gebruiken. En ik gebruik de hamer echt sporadisch, misschien 1 op 15 programma's van me die misschien 1 of 2 goto's hebben? Ik weet wel dat ik vaker goto tik dan while. Do-while heb ik nog nooit gebruikt, maar ik geloof meteen dat die ook z'n nut kan hebben.
Ik heb ook twee concrete voorbeelden waarbij het voordelig is om een goto daadwerkelijk in te zetten. Een vrij bekende is het 'onstnappen' uit een geneste for-loop()
void poorlyChosenName()
{
for( int x = 0 ; x < 100 ; x ++ )
{
for( int y = 0 ; y < 100 ; y ++ )
{
for( int z = 0 ; z < 100 ; z ++ )
{
// application code
if( coordinateFound ) goto cleanupCode ;
// more application code
}
}
}
cleanupCode:
// cleanup code
}
En eentje die ik zelf had bedacht, is het gebruik van goto binnen switch-cases. Dan zijn ze een soort van in hun natuurlijke habitat tussen andere labels. Als sommige cases dezelfde cleanup code gebruiken, kan je break vervangen door een goto en dat scheelt dan wat functie calls. Natuurlijk kan dit ook zonder goto, maar ik vind dit toepasselijk gebruik.
void poorlyChosenName()
{
switch( someCase )
{
case 1:
// case 1 code
goto cleanup123 ;
case 2:
// case 2 code
goto cleanup123 ;
case 3:
// case 3 code
goto cleanup123 ;
case 4:
// case 4 code
goto cleanup456 ;
case 5:
// case 5 code
goto cleanup456 ;
case 6:
// case 6 code
goto cleanup456 ;
cleanup123:
// cleanup123code ;
break ;
cleanup456:
// cleanup456code ;
break ;
}
}Ik vind dit dus geen 'spaghetti' code, en als iemand dat wel vindt dan vind er daar ook iets van, iets met een plaat en hoofd :P en dat vinden anderen vast ook van mij. En zo vinden we allemaal wel wat ::)
Mijn favoriete klassieker is deze style guide uit 1994 van NASA (https://ntrs.nasa.gov/api/citations/19950022400/downloads/19950022400.pdf) naast Das Boot natuurlijk ;). Ik vind dat daar veel logische dingen in staan.
Bas
-
Sorry Bas,
ik vind dit juist onzin. Ik programmeer in C sinds 1983 en heb nog nooit een goto nodig gehad. Ik weet niet of je ooit van structured programming hebt gehoord, waarschijnlijk niet. Hoe ga je dat dan doen in Java, dat heeft terecht het goto statement laten vallen.
De constructies die jij laat zien zijn in mijn ogen gewoon prutswerk waarbij niet goed over de structuur van je programma is nagedacht.
Sorry voor mijn wat hard oordeel, maar ik heb teveel van dit soort constructies moet opschonen in mijn werk, ze kunnen initieel werken totdat iemand anders iets moet wijzigen en niet in de gaten heeft dat er in bepaalde omstandigheden naar een label gesprongen wordt.
Hier laat ik het bij.
Groet Meino
-
Lees deze twee antwoorden van deze vraag eens. :P
https://stackoverflow.com/questions/24451/are-there-any-legitimate-use-cases-for-goto-in-a-language-that-supports-loops (https://stackoverflow.com/questions/24451/are-there-any-legitimate-use-cases-for-goto-in-a-language-that-supports-loops)
Die is specifiek voor voor mensen zoals jou (no offense )
Everybody who is anti-goto cites, directly or indirectly, Edsger Dijkstra's GoTo Considered Harmful article to substantiate their position
De constructies die jij laat zien zijn in mijn ogen gewoon prutswerk waarbij niet goed over de structuur van je programma is nagedacht.
Dit is oogkleppen op hebben, je ziet 2 half lege voorbeelden, ziet het woord goto en geeft instant oordeel zonder objectief te kijken.
Ik snap wel dat je deel aan terror gezien heb, maar dat is niet uitsluitend bewijs dat er geen goed gebruik goto kan bestaan. We gaan hier sws niet overeen komen dus ik laat het hier ook bij (y)
Mvg,
Vas
-
"And never the twain shall meet"
Ik behoor inderdaad stevig in het Edsger Dijkstra kamp, al hoewel ik het niet met alles van hem eens ben, zijn afkeer van OO heb ik niet.
Groet Meino
-
Goto's altijd een mooi onderwerp 8)
Ik ben er niet tegen, er zijn een aantal use cases waarin ze best handig zijn, in de Linux kernel worden goto's veelvuldig gebruikt voor clean-up, mooie oplossing om de code leesbaar te houden vind ik, anders krijg je allemaal geneste if's ook niet echt handig. Zie b.v.: https://github.com/torvalds/linux/blob/master/drivers/net/can/spi/mcp251x.c#L1245
-
Moet ik ook nog aan de tab gebruikers uitleggen waarom ze er naast zitten? :P
*omdat je andere tab grootte gebruikt dan de auteur* ;D
-
Ik behoor inderdaad stevig in het Edsger Dijkstra kamp, al hoewel ik het niet met alles van hem eens ben, zijn afkeer van OO heb ik niet.
+1 (y)
P.S. Al mijn modules werken op basis van de Counting Semaphores van "ome" Edsger ;) De grap is:
Semaphores
Semaphores are a programming construct designed by E. W. Dijkstra in the late 1960s. Dijkstra's model was the operation of railroads: consider a stretch of railroad in which there is a single track over which only one train at a time is allowed.
Guarding this track is a semaphore. A train must wait before entering the single track until the semaphore is in a state that permits travel. When the train enters the track, the semaphore changes state to prevent other trains from entering the track. A train that is leaving this section of track must again change the state of the semaphore to allow another train to enter.
Hele artikel is hier te lezen: https://docs.oracle.com/cd/E19683-01/806-6867/6jfpgdcnj/index.html (https://docs.oracle.com/cd/E19683-01/806-6867/6jfpgdcnj/index.html)
Grtzz,
Karst
-
En hier zijn de originele artikel van de 'meester' ter leerling ende vermaeck
http://www.cs.utexas.edu/users/EWD/
Remco
-
Ik had vanavond nog een test gedaan. Die random interval na een status die niet 'done' was, leek niet heel veel te helpen in het begin. Het was althans nog steeds niet goed in het begin en ik kan niet echt de mate van 'niet goed' vaststellen. Of in andere worden, ik kon niet zien of het beter was of niet.
De 2e test was om kleine differentiatie in te bouwen op het verzend moment. Het eerste apparaat moet elke 10000ms zijn dingen togglen, het volgende apparaat om de 10001ms etc. Ik hoopte eigenlijk dat ik met dat verschil toch wel een significant effect zou hebben door die identieke apparaten niet meer in deze microseconde~ish te laten verzenden...
Ook dit leek aanvankelijk erg weinig effect te hebben.
https://www.youtube.com/v/JuElzICrmw8
Maar ik liet hem een tijdje aanstaan omdat de pauzes tussen de apparaten telkens groter werden. En uiteindelijk had ik wel een stabiel punt bereikt dat het goed werkt. Dit was allemaal met 'slechts' 7 modules. Je kan hier ook de ledjes zien wat deze pauze inmiddels was geworden. Het was ook wel interessant om te zien dat de fouten hoofdzakelijk in de laatste modules lagen en dat het telkens minder werd.
https://www.youtube.com/v/4_Z1hRDNwNA
In beide gevallen werkte alles met 4 aangesloten modules wel zonder fouten vanaf de eerste transmissies.
Ik loop dat loconet documentje al een tijdje door te lezen en ook de library. Ik snapte eerst niet hoe er differentiatie moest plaats vinden. Maar ik denk dat ik hem vat. Als 2 apparaten tegelijk versturen, en apparaat 1 stuurt een '1' en de ander een '0' dan detecteert het apparaat wat de '1' stuurt een collission eerder dan de ander. Zolang er verschil zit in het bericht moeten ze er altijd uit kunnen komen, ongeacht hoeveel dingen (tot een max vanwege 25 pogingen) tegelijk proberen te versturen.
Ik denk daarom dat die library toch iets niet helemaal goed doet. Nog even verder graven.
Mvg,
Bas
-
Bas
even een vraagje, ik heb altijd het gevoel gehad dat loconet het CAN protocol gebruikt. Als dat klopt weet ik wel hoe het werkt. In het CAN bus protocol speelt de message identifier een grote rol, die moet voor iedere zender uniek zijn.
groet Meino
-
Hi Meino,
LocoNet en CAN zijn twee totaal verschillende systemen, niet alleen het bericht formaat anders, maar ook elektrische werkt het anders. Wat wel op elkaar lijkt is het "meeluisteren met zenden voor collision detection", hoe daar dan weer mee omgegaan wordt is weer anders. Bij LocoNet gebeurt dit (altijd) in software, bij CAN doet de controller dat.
Bij CAN hoeft overigens de 11/29 bit Identifier niet perse uniek te zijn, dat is aan het protocol boven op CAN om dat te bepalen. In veel gevallen zit er wel een soort systeem in natuurlijk omdat dat handig/nodig is.
Reinder
-
Reinder
Ik weet dat de message identifier technisch gezien niet uniek hoeft te zijn zolang de messages onderling ergens afwijken. Maar soms bevat data van twee zenders identieke waarden. Dus in de praktijk is het dan ook beter om te zorgen dat de message identifier uniek is.
Maar bedankt voor je informatie over Loconet.
Groet Meino
-
Hi Bas
Ik loop dat loconet documentje al een tijdje door te lezen en ook de library. Ik snapte eerst niet hoe er differentiatie moest plaats vinden. Maar ik denk dat ik hem vat. Als 2 apparaten tegelijk versturen, en apparaat 1 stuurt een '1' en de ander een '0' dan detecteert het apparaat wat de '1' stuurt een collission eerder dan de ander. Zolang er verschil zit in het bericht moeten ze er altijd uit kunnen komen, ongeacht hoeveel dingen (tot een max vanwege 25 pogingen) tegelijk proberen te versturen.
Je zou inderdaad denken dat de mrwa Library dit allemaal voor je doet. Het zou raar zijn als retransmissions (na collision) aan de gebruiker/ applicatie wordt overgelaten. Maar ik ken de Library echter niet, dus ik zou dat niet weten.
Wat ik wel weet is dat er een loconet hackers mailinglijst is, en dat daar je zeker een prima antwoord kan krijgen. Probeer het eens daar.
Wat ik van een Library verwacht, is dat het een counter aan de gebruiker geeft hoe vaak collisions hebben plaatsgevonden. Dat geeft een mooie maat voor waar de problemen precies liggen. Ik zou ook een counter verwachten die het aantal “checksom” fouten (XOR??) aangeeft. Zit dat niet in de Library?
Je beschrijving van “differential backoff” (heet dat zo?) wordt in de praktijk wel vaker gebruikt (bv ISDN). Als ook het Source Address wordt verstuurd, is er een verschil in berichten.
Groet, Aiko