Zelfbouw decoders: vraag aan de loconet experts

[AP3737]

Ken u klassieken, zeker nooit https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf gelezen.
Alleen slechte programmeurs hebben het goto statement nodig.

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

[Karst Drenth]

BS;

Code: [Selecteer]

while( millis() <= startupDelay ){}
Doet het zelfde en is nog korter en duidelijker.

Kan nog een paar karakters korter.

Code: [Selecteer]

while (millis() <= startupDelay);


Ken u klassieken, zeker nooit https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf gelezen.

+1

[bask185]

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.

Code: [Selecteer]

#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:

Code: [Selecteer]

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():

Code: [Selecteer]

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()

Code: [Selecteer]

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.

Code: [Selecteer]

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  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 naast Das Boot natuurlijk  . Ik vind dat daar veel logische dingen in staan.

Bas

[meino]

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

[bask185]

Lees deze twee antwoorden van deze vraag eens. 
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 

Mvg,

Vas

[meino]

"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

[reinderlf]

Goto's altijd een mooi onderwerp

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

[bask185]

Moet ik ook nog aan de tab gebruikers uitleggen waarom ze er naast zitten? 

*omdat je andere tab grootte gebruikt dan de auteur* 

[Karst Drenth]

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 

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

Grtzz,
Karst

[Remco_Nzo]

En hier zijn de originele artikel van de 'meester'  ter leerling ende vermaeck
http://www.cs.utexas.edu/users/EWD/

Remco

[bask185]

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.
<a href="https://www.youtube.com/v/JuElzICrmw8" target="_blank" class="new_win">https://www.youtube.com/v/JuElzICrmw8</a>

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.
<a href="https://www.youtube.com/v/4_Z1hRDNwNA" target="_blank" class="new_win">https://www.youtube.com/v/4_Z1hRDNwNA</a>

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

[meino]

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

[reinderlf]

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

[meino]

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

[AP3737]

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