The root cause is that Delay_ms is a valid label so the your code jumps to the label and processes the ms delay, however , there is an assumption that the delay parameters are setup, and, with delay_ms(100) they are not.
This is resolvable but this is a design question for Hugh.
Delay_ms(100)Delay_us(100)wait100ms
The can easily be transformed into (in asm). Note the delay_ms and delay_us are transformed into the correct waits. I have changed the compiler as this was rather easy.
delay_ms, delay_us and delay_s are subs created in the ASM by the compiler for handling wait times. These should be considered key words and not be used in GCB code.
On a PIC, accidentally using one of these will compile without error. However and error will be thrown when attempting to Assemble.
Error: GCASM: Symbol SYSWAITTEMPS has not been defined at DECFSZ
SYSWAITTEMPS, F,ACCESS
Last edit: William Roth 2021-01-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as I understand, I made (involuntarily) a "direct" reference to an ASM subroutine ... My final conclusions :
- One should not use too many languages. When I had to work in VBA (in my former workplace) I terminated the first time often the lines with a semicolon, because at home I used ... Delphi ! BTW I noticed that a semicolon at the end of the line in GCB seems to cause no trouble ...
- I am a "CURSED" user (look at my new "slogan" ), and this since the Commodore 64 era : if there were bugs, You could be sure that I would meet them !
:)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I often wonder why I try to make my code more efficient when I end up using wait.
I like trying the various interrupts so my code is always doing something.
Wait is a precise waste of time to me.
Maybe go back to flashing leds :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I often wonder why I try to make my code more efficient when I end up using wait.
I like trying the various interrupts so my code is always doing something.
Wait is a precise waste of time to me.
Maybe go back to flashing leds :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some code does not need to be "always doing something".
However one could (validly) argue that waiting is actually doing something . . . Waiting for a timer to overflow, waiting for a bit to change, waiting for a byte to be received, waiting for an OSC to settle, Et al.
Sometimes an interrupt is inappropriate , unnecessary, or adds unwanted complexity when a simple "Wait" will suffice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The code that I attached is the control program for my railroad layout ; it is pure "mono-tasking" (one train at once), it works like a "washing machine sequencer", so I can waste time with "waiting" until I send the next control code to my ports ; especially there are 8 turnouts, operated together as one group of four and two groups of two, they should not flip simultaneously to avoid overloading the power supply, so I call a subroutine (line 207 to 240) which memorizes the present state of each group and flips only those to change with intervals of 500 ms, and adds an additional delay of 500 ms if some turnouts really flipped : Rokuhan turnouts cause short "short circuits" (I tested it and got the confirmation on a railroad forum) and this could be interpreted as trigger pulses by the position detectors.
Last edit: Bertrand BAROTH 2021-01-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The root cause is that Delay_ms is a valid label so the your code jumps to the label and processes the ms delay, however , there is an assumption that the delay parameters are setup, and, with delay_ms(100) they are not.
This is resolvable but this is a design question for Hugh.
The can easily be transformed into (in asm). Note the delay_ms and delay_us are transformed into the correct waits. I have changed the compiler as this was rather easy.
HUGH - Should we do this? What of delay_s .. delay_h etc?
delay_ms, delay_us and delay_s are subs created in the ASM by the compiler for handling wait times. These should be considered key words and not be used in GCB code.
On a PIC, accidentally using one of these will compile without error. However and error will be thrown when attempting to Assemble.
Error: GCASM: Symbol SYSWAITTEMPS has not been defined at DECFSZ
SYSWAITTEMPS, F,ACCESS
Last edit: William Roth 2021-01-07
I can change to transform or I can explicitly reject as a syntax error.
Happy to do either.
I vote for syntax error
I have prepared 'syntax error' and 'transform to wait'.
Get voting... but, I tend to think that it is a 'syntax error' as we will end up catering for all language variations!!
As far as I understand, I made (involuntarily) a "direct" reference to an ASM subroutine ... My final conclusions :
- One should not use too many languages. When I had to work in VBA (in my former workplace) I terminated the first time often the lines with a semicolon, because at home I used ... Delphi ! BTW I noticed that a semicolon at the end of the line in GCB seems to cause no trouble ...
- I am a "CURSED" user (look at my new "slogan" ), and this since the Commodore 64 era : if there were bugs, You could be sure that I would meet them !
:)
@alberich LOL
And, that sounds like a vote for 'syntax error'!
I often wonder why I try to make my code more efficient when I end up using wait.
I like trying the various interrupts so my code is always doing something.
Wait is a precise waste of time to me.
Maybe go back to flashing leds :)
I often wonder why I try to make my code more efficient when I end up using wait.
I like trying the various interrupts so my code is always doing something.
Wait is a precise waste of time to me.
Maybe go back to flashing leds :)
Some code does not need to be "always doing something".
However one could (validly) argue that waiting is actually doing something . . . Waiting for a timer to overflow, waiting for a bit to change, waiting for a byte to be received, waiting for an OSC to settle, Et al.
Sometimes an interrupt is inappropriate , unnecessary, or adds unwanted complexity when a simple "Wait" will suffice.
The voting is closed.
Syntax error it is.
The code that I attached is the control program for my railroad layout ; it is pure "mono-tasking" (one train at once), it works like a "washing machine sequencer", so I can waste time with "waiting" until I send the next control code to my ports ; especially there are 8 turnouts, operated together as one group of four and two groups of two, they should not flip simultaneously to avoid overloading the power supply, so I call a subroutine (line 207 to 240) which memorizes the present state of each group and flips only those to change with intervals of 500 ms, and adds an additional delay of 500 ms if some turnouts really flipped : Rokuhan turnouts cause short "short circuits" (I tested it and got the confirmation on a railroad forum) and this could be interpreted as trigger pulses by the position detectors.
Last edit: Bertrand BAROTH 2021-01-07
Interesting challenge making a train control program work. Well done.
"Interesting challenge making a train control program work. Well done."
Can you get the real ones to work? :)