Select/Case not working correctly

matchbox

Senior Member
Hi all,
I often use SELECT/CASE over IF/ENDIF.
But in a few situations when the select/case has more complex items to handle. I have found that it seems to get bogged down more then a conventional If/Endif format.
To the point that it will refuse to work at all. Even though it checks out fine.

The below layout shows the two formats I have used.
This piece of code is used to select a scrolling message that will be displayed by an OLED, receiving data from an RF link.

Using the CASE format, 3 of 10 times, it won't display the scrolling message at all.
While it always does with the IF/ENDIF format. This is not the first time I have encountered this behavior, using SELECT/CASE, under similar circumstances.

Plus.The CASE format also makes the program 60bytes larger, than with the IF format.
Most of these messages(not included)are up to 44 characters.
Any idea why this happens?
Code:
scroll_message_selector:
  
  if rx_data=%00000001 or rx_data=%00001101 then serout b.2,n2400_16,(254,208,"")endif ;44 characters max.           
  if rx_data=%00000010 or rx_data=%00010000 then serout b.2,n2400_16,(254,208,"")endif
  if rx_data=%00000011 or rx_data=%00001111 then serout b.2,n2400_16,(254,208,"")endif
  if rx_data=%00000100 or rx_data=%00001110 then serout b.2,n2400_16,(254,208,"")endif
  if rx_data=%00000101 or rx_data=%00001100 then serout b.2,n2400_16,(254,208,"")endif
  if rx_data=%00000110 or rx_data=%00001011 then serout b.2,n2400_16,(254,208,"")endif                    
  if rx_data=%00000111                      then serout b.2,n2400_16,(254,208,"")endif
  if rx_data=%00001000                      then serout b.2,n2400_16,(254,208,"")endif
  if rx_data=%00001001                      then serout b.2,n2400_16,(254,208,"")endif          
  if rx_data=%00001010                      then serout b.2,n2400_16,(254,208,"")endif                                            
  if rx_data=%00010001                      then serout b.2,n2400_16,(254,208,"")endif                                              
  if rx_data=%00010010                      then serout b.2,n2400_16,(254,208,"")endif        
  if rx_data=%00010011                      then serout b.2,n2400_16,(254,208,"")endif
  if rx_data=%00010100                      then serout b.2,n2400_16,(254,208,"")endif
  if rx_data=%00010101                      then serout b.2,n2400_16,(254,208,"")endif
  if rx_data=%00010110                      then serout b.2,n2400_16,(254,208,"")endif
  if rx_data=%00010111                      then serout b.2,n2400_16,(254,208,"")endif
  if rx_data=%00011000                      then serout b.2,n2400_16,(254,208,"")endif  ;
  return
  

scroll_message_selector:
  select case rx_data
  case %00000001,%00001101: serout b.2,n2400_16,(254,208,"") ;44 characters max.           
  case %00000010,%00010000: serout b.2,n2400_16,(254,208,"")
  case %00000011,%00001111: serout b.2,n2400_16,(254,208,"")
  case %00000100,%00001110: serout b.2,n2400_16,(254,208,"")
  case %00000101,%00001100: serout b.2,n2400_16,(254,208,"")
  case %00000110,%00001011: serout b.2,n2400_16,(254,208,"")                       
  case =         %00000111: serout b.2,n2400_16,(254,208,"")
  case =         %00001000: serout b.2,n2400_16,(254,208,"")
  case =         %00001001: serout b.2,n2400_16,(254,208,"")           
  case =         %00001010: serout b.2,n2400_16,(254,208,"")                                            
  case =         %00010001: serout b.2,n2400_16,(254,208,"")                                              
  case =         %00010010: serout b.2,n2400_16,(254,208,"")         
  case =         %00010011: serout b.2,n2400_16,(254,208,"")
  case =         %00010100: serout b.2,n2400_16,(254,208,"")
  case =         %00010101: serout b.2,n2400_16,(254,208,"")
  case =         %00010110: serout b.2,n2400_16,(254,208,"")
  case =         %00010111: serout b.2,n2400_16,(254,208,"")
  case =         %00011000: serout b.2,n2400_16,(254,208,"")  
  endselect
  return
 
Last edited:

AllyCat

Senior Member
Hi,

Personally, I prefer the IF ..THEN .. ENDIF structure because it is more intuitive. Also, I believe that "IF...GOTO" is the only native command in the the PICaxe interpreter and SELECT .. CASE is converted by the Editor, so may be less efficient in using codespace.

But I don't believe your two structures are equivalent: Each line of the IF .. THENs terminates witrh an ENDIF so every line will be executed in sequence. However, your SELECT .. CASE has only a single ENDSELECT at the end of the whole block. I believe that when any CASE line is "successful" then execution passes to the next line after the ENDSELECT , so many of the lines may never be "examined".

From the Command Reference:

"Multiple tests can check for various conditions and if those conditions are met then the associated code is executed and then execution continues after the endselect command. Only one condition will ever be met within and 'select case' command and oly one section of associated code will be executed."

Cheers, Alan.
 
Last edited:

inglewoodpete

Senior Member
Personally, I prefer the IF ..THEN .. ENDIF structure because it is more intuitive. Also, I believe that "IF...GOTO" is the only native command in the the PICaxe interpreter and SELECT .. CASE is converted by the Editor, so may be less efficient in using codespace.
This is my understanding too. Select Case and If/Then/Else branching structures were introduced as an update to the programming editor (Release of PE5.0 from memory), based on the chip's native If/Goto. I use all three options, although I avoid "goto" almost to exclusion.

To be equivalent, the If/Then lines need a "GoTo <cmd after the last If/Then>" to "match" the Select Case block.

@matchbox, 1. In your supplied code the SerOut messages are all blank. I presume this is to keep your post simple. 2. You appear to have 23 input values numbered 1-24. There may be a more efficient method of referencing your messages, possibly indexed into RAM/Scratchpad, EEPROM or flash ("Table").
 

matchbox

Senior Member
Thanks for the reply guys:D

That's correct Alan. They are set out differently. IF, instead of ELSEIF was used to see if that format worked any better. And because, no more than ONE input would appear at any one time; I just used IF ENDIF.
Although it still does work well with IF ELSEIF ENDIF.

Pete. I left them blank, for the reason you stated.
Because it is an RF link that triggers these messages. I found it more reliable to just transmit a byte, to the receiving end. Then let the rest happen there.
I'm always open to more efficient ways of doing things:D
If you have any idea's. I'm listening.

This is the part of the program that scrolls the message on the display. It uses the above code as a reference to choose the message that is correct.
Code:
scroll:
  gosub scroll_message_selector
  do
  inc counter	                            
  if counter=60 then                         
  serout b.2,n2400_16,(254,1)                
  pause 200 
  let counter=0 	      	              
  goto check endif                               
  serout b.2,n2400_16,(254,24)	       
  pause 600						   
  loop
 

inglewoodpete

Senior Member
A few questions. Which PICAXE? What is the total number of characters for the 18 messages? Are there phrases or strings that appear in more than one message that would allow the storage space to be reduced?
 

matchbox

Senior Member
A few questions. Which PICAXE? What is the total number of characters for the 18 messages? Are there phrases or strings that appear in more than one message that would allow the storage space to be reduced?
There are 44 character maximum, for each line or message phrase.
As can be seen from the first code post. The first 6 messages are used for another 6 inputs as well. i.e. One message(phrase) is used for Two different references.

Currently it is using 960 character. But has the memory capacity left in the 14M2, for around another 180 character(with a few dozen bytes left over). By adding extra lines and phrases, if another device is added later on.
 

hippy

Technical Support
Staff member
There will be no functional difference between a long list of IF-ENDIF and SELECT-CASE commands.

The only difference is that after a CASE option has been matched it will jump to past the END SELECT as noted. This is what the extra program bytes are and it also means the execution time will be different and will vary depending on which CASE actually matches.

Whatever the issue is it is almost certainly not due to any error with regard to SELECT-CASE itself.
 

matchbox

Senior Member
This is what the extra program bytes are and it also means the execution time will be different and will vary depending on which CASE actually matches.

Whatever the issue is it is almost certainly not due to any error with regard to SELECT-CASE itself.
I have used this function many times with no problems, in the most part. It only seems to be a problem when it has a longer list of things to do, on each CASE. Or has a long list of CASES.
 

inglewoodpete

Senior Member
There are 44 character maximum, for each line or message phrase.
As can be seen from the first code post. The first 6 messages are used for another 6 inputs as well. i.e. One message(phrase) is used for Two different references.

Currently it is using 960 character. But has the memory capacity left in the 14M2, for around another 180 character(with a few dozen bytes left over). By adding extra lines and phrases, if another device is added later on.
I certainly can't explain why you are having messages dropped when you use a Select Case branching structure. Is your code otherwise identical?

Since you are using a 14M2, there is not much you can do with restructuring your code as I was thinking/suggesting. I can see, too, that there is more to the project than you are telling us Eg 18 messages x 44 characters maximum = 792 but you refer to 960 in post #6.
 

matchbox

Senior Member
That's correct Pete. Although i do have another list of messages(phrases). That increases the total to just under 960. I thought I would give you the high end of the characters needed, rather than just what was displayed in post #1.

The operation part of the code for this device has stayed the same for years now. And it was just recently that I thought I would change a few messages and use the OR "," in the CASE option, in 1 to 6. By integrating 11 to 16 with them. Because they where the same phrase, for two separate device of the same kind. So they just wasted memory for no reason.
It would appear that this has played some part in it. Or its the way the "=" sign works in-conjunction with the CASE Select in this layout.
To be honest, I only see the effect here. And from what I notice...Every time I remove the = sign after each CASE. The memory byte count goes up by 2 and the code checks out the same with or without the "=" sign.
Do you know how the compiler drives the CASE SELECT function under these conditions?

Forgot to mention. The reason I know this is centered around the CASE/SELECT function. Is because I encountered a similar issue to this a year back. And could not find a way around that either. I just settled for using IF ELSEIF ENDIF instead.
So after this happened yesterday. I thought I would ask here; if anyone else has experienced this. Because I would like to understand why this has happened.
 
Last edited:

techElder

Well-known member
matchbox, are you simplifying something beyond reason?

In your code, no matter what the input is, your output is exactly the same.

What's the purpose of the code if it doesn't matter what the input is?

PS. Even if the code does nothing in its present state, you do need " : " before the endif at the end of each line.

PPS. Sort your list of inputs, when you use the SELECT/CASE method, so the most often encountered input is the first/top one. It will be quicker.
 

matchbox

Senior Member
matchbox, is this some kind of joke or are you simplifying something beyond reason?

In your code, no matter what the input is, your output is exactly the same.

What's the purpose of the code if it doesn't matter what the input is?

PS. Even if the code does nothing in its present state, you do need " : " before the endif at the end of each line.

PPS. Sort your list of inputs, when you use the SELECT/CASE method, so the most often encountered input is the first/top one. It will be quicker.
I wish it was a joke. I wouldn't be having any issues;)
Which part of what I mentioned earlier, are you referencing too?
I am leaving a lot of stuff out of the general operation code, that makes this function. Because I'm just trying to keep the focus on the CASE/SELECT issue. Which is where I know the problem is originating from. Like I mentioned in my post before this.

Below. It looks at a specific input byte and references that to a message.


Code:
scroll_message_selector:
  select case rx_data
  case %00000001,%00001101: serout b.2,n2400_16,(254,208,"") ;44 characters max.           
  case %00000010,%00010000: serout b.2,n2400_16,(254,208,"")
  case %00000011,%00001111: serout b.2,n2400_16,(254,208,"")
  case %00000100,%00001110: serout b.2,n2400_16,(254,208,"")
  case %00000101,%00001100: serout b.2,n2400_16,(254,208,"")
  case %00000110,%00001011: serout b.2,n2400_16,(254,208,"")                       
  case =         %00000111: serout b.2,n2400_16,(254,208,"")
  case =         %00001000: serout b.2,n2400_16,(254,208,"")
  case =         %00001001: serout b.2,n2400_16,(254,208,"")           
  case =         %00001010: serout b.2,n2400_16,(254,208,"")                                            
  case =         %00010001: serout b.2,n2400_16,(254,208,"")                                              
  case =         %00010010: serout b.2,n2400_16,(254,208,"")         
  case =         %00010011: serout b.2,n2400_16,(254,208,"")
  case =         %00010100: serout b.2,n2400_16,(254,208,"")
  case =         %00010101: serout b.2,n2400_16,(254,208,"")
  case =         %00010110: serout b.2,n2400_16,(254,208,"")
  case =         %00010111: serout b.2,n2400_16,(254,208,"")
  case =         %00011000: serout b.2,n2400_16,(254,208,"")  
  endselect
  return
 

techElder

Well-known member
Sorry about making light of the problem, but your simplification is not delineated.

I'm late to the party, but I was referring to the following code being repeated a few times.

Code:
serout b.2,n2400_16,(254,208,""
So, "leaving a lot of stuff out" has nothing to do with what you are experiencing?
 

matchbox

Senior Member
So, "leaving a lot of stuff out" has nothing to do with what you are experiencing?
That's correct.
I am sure it has to do with the way the SELECT/CASE function operates, when it has a longer list CASES and those CASES have many characters or conditions to check.

It would be good if someone here can tell me the difference in the way the compiler treats the IF/ENDIF function, compared to the SELECT/CASE function.
 

hippy

Technical Support
Staff member
Whether using "CASE X" or "CASE = X" the functionality is the same, but with "=" specified the compiler is able to optimise the code better. It could possibly optimise it better even without but it doesn't, presumably because it needs to be prepared for additional matches which could follow, eg "CASE X, Y".

Code:
Select Case b0
  Case 0 : SerTxd( "0")
  Case 1 : SerTxd( "1")
End Select
Code:
        IF b0 = 0 THEN L1
        GOTO L2
L1:
        SERTXD("0")
        GOTO L4
L2:
        IF b0 = 1 THEN L3
        GOTO L4
L3:
        SERTXD("1")
L4:
Code:
Select Case b0
  Case = 0 : SerTxd( "0")
  Case = 1 : SerTxd( "1")
End Select
Code:
        IF b0 <> 0 THEN L1
        SERTXD("0")
        GOTO L2
L1:
        IF b0 <> 1 THEN L2
        SERTXD("1")
L2:
What the SELECT-CASE generates is, as stated, almost certainly a red herring, isn't the cause of the issue you are experiencing.
 

hippy

Technical Support
Staff member
I am leaving a lot of stuff out of the general operation code, that makes this function. Because I'm just trying to keep the focus on the CASE/SELECT issue.
I think it would be best to post your full code. Then it may become easier to tell what the issue may be. Focusing on the SELECT-CASE issue is almost certainly the wrong place to be focused.

It may be that moving to SELECT-CASE has altered the program's timing when the program may have been more dependent on its timing than you may have realised and that may be making it no longer work.

Or there may be some subtle difference with what you had and what you now have which does materially affect what is now happening.

In both cases it may be a case of revealing a problem which had been hidded rather than creating it.
 

hippy

Technical Support
Staff member
Having checked the executable token code generated by the IF-ENDIF, after adding GOTO so the sequence is jumped out of as soon as a SEROUT has been executed, the 14M2 compiler generates exactly the same code with your IF-ENDIF and SELECT-CASE versions, right down to the same number of bytes and bits of tokens produced.

It is not a code generation issue, nothing to do with the SELECT-CASE itself.
 

inglewoodpete

Senior Member
I think it would be best to post your full code. Then it may become easier to tell what the issue may be. Focusing on the SELECT-CASE issue is almost certainly the wrong place to be focused.
Better still, cut the code down to the smallest working model that exhibits the problem.
 

BESQUEUT

Senior Member
It is not a code generation issue, nothing to do with the SELECT-CASE itself.
+1...

+ IHMO : ANY code with at least one GOTO statement may behave strangely... Remove any of them, and your code will do what you want...


Code:
[color=Blue]Select Case [/color][color=Purple]b0
  [/color][color=Blue]Case [/color][color=Navy]0 [/color][color=Black]: [/color][color=Blue]SerTxd( [/color][color=Red]"000000000"[/color][color=Blue])
  Case [/color][color=Navy]1 [/color][color=Black]: [/color][color=Blue]SerTxd( [/color][color=Red]"111111111"[/color][color=Blue])
  Case [/color][color=Navy]2 [/color][color=Black]: [/color][color=Blue]SerTxd( [/color][color=Red]"222222222"[/color][color=Blue])
  End Select[/color]
84 bytes


Code:
[color=Blue]on [/color][color=Purple]b0 [/color][color=Blue]gosub [/color][color=Black]S0,S1,S2[/color]
[color=Blue]end[/color]


[color=Black]S0:[/color][color=Blue]SerTxd( [/color][color=Red]"000000000"[/color][color=Blue])[/color][color=Black]:[/color][color=Blue]return[/color]
[color=Black]S1:[/color][color=Blue]SerTxd( [/color][color=Red]"111111111"[/color][color=Blue])[/color][color=Black]:[/color][color=Blue]return[/color]
[color=Black]S2:[/color][color=Blue]SerTxd( [/color][color=Red]"222222222"[/color][color=Blue])[/color][color=Black]:[/color][color=Blue]return[/color]
82 bytes (and quicker as no test at all...)
 
Last edited:

matchbox

Senior Member
Having checked the executable token code generated by the IF-ENDIF, after adding GOTO so the sequence is jumped out of as soon as a SEROUT has been executed, the 14M2 compiler generates exactly the same code with your IF-ENDIF and SELECT-CASE versions, right down to the same number of bytes and bits of tokens produced.

It is not a code generation issue, nothing to do with the SELECT-CASE itself.
Thank you Hippy for the explanation, and running a simulation.
That would mean that it would be a timing issue then. Which should not be surprising, with serial communication to a display driver.

Here is the full part of the code, in which the problem is occurring.
The first part takes the received byte number and uses it to extract a message from the 18M2 OLED displays EEPROM
Which it then flashes 3 times on the top line of the display.
Then it moves on to the next process, by scrolling the preset message from the 14M2, along the bottom line of the display.
Once complete, it returns to wait for another fault or the same fault.

My issue is occurring between the flashing selection and the scrolling selection. The message flashes, but it does not always scroll the message following anymore.
I did remove this statement after having the problem. But it made no difference.
Code:
 if eeprom_message = %00000100 or eeprom_message =%00000101 then               ;this messages has no scrolling selection
 goto check 
 endif
It does not seem to be related to the message length, whether long or short. Plus I have used many different length messages over the years
and this has not occurred before.
And when it does occur. It will miss the scrolling message the first time. Then in most cases it will scroll next time around, if the error is still occurring.

Code:
flash_message_selector:
  select case rx_data
  case %00000001 to %00000110: eeprom_message = 10             
  case %00000111 to %00001001: eeprom_message = 8           
  case            = %00001010: eeprom_message = 1              
  case %00001011 to %00010000: eeprom_message = 7              
  case            = %00010001: eeprom_message = 1              
  case %00010010 to %00011000: eeprom_message = 13             
  case            = %00011101: eeprom_message = 4              
  case            = %00011110: eeprom_message = 5              
  endselect
 
 
flash:
  serout b.2,n2400_16,(254,1)
  pause 120
  for cycle=1 to 3                                             
  serout b.2,n2400_16,(254,2,254,128,253,eeprom_message)       
  pause 3000                                                   
  serout b.2,n2400_16,(254,128,253,1)	                  
  pause 800                                                    
  next cycle
  if eeprom_message = %00000100 or eeprom_message =%00000101 then               ;messages have no scroll selection
  goto check 
  endif
  
scroll:
  gosub scroll_message_selector
  do
  inc counter	                            
  if counter=60 then                        
  serout b.2,n2400_16,(254,1)                
  pause 200 
  let counter=0 	      	               
  goto check 
  endif                               
  serout b.2,n2400_16,(254,24)	         
  pause 600						   
  loop
     

scroll_message_selector:
  select case rx_data
  case %00000001,%00001101: serout b.2,n2400_16,(254,208,"message ")                            
  case %00000010,%00010000: serout b.2,n2400_16,(254,208,"message ")
  case %00000011,%00001111: serout b.2,n2400_16,(254,208,"message ")
  case %00000100,%00001110: serout b.2,n2400_16,(254,208,"message ")
  case %00000101,%00001100: serout b.2,n2400_16,(254,208,"message ")
  case %00000110,%00001011: serout b.2,n2400_16,(254,208,"message ")                      
  case =         %00000111: serout b.2,n2400_16,(254,208,"message ")
  case =         %00001000: serout b.2,n2400_16,(254,208,"message ")
  case =         %00001001: serout b.2,n2400_16,(254,208,"message ")        
  case =         %00001010: serout b.2,n2400_16,(254,208,"message ")                                            
  case =         %00010001: serout b.2,n2400_16,(254,208,"message ")                                              
  case =         %00010010: serout b.2,n2400_16,(254,208,"message ")       
  case =         %00010011: serout b.2,n2400_16,(254,208,"message ")
  case =         %00010100: serout b.2,n2400_16,(254,208,"message ")
  case =         %00010101: serout b.2,n2400_16,(254,208,"message ")
  case =         %00010110: serout b.2,n2400_16,(254,208,"message ")
  case =         %00010111: serout b.2,n2400_16,(254,208,"message ")
  case =         %00011000: serout b.2,n2400_16,(254,208,"message ")  
  endselect
  return
 

BESQUEUT

Senior Member
Thank you Hippy for the explanation, and running a simulation.
That would mean that it would be a timing issue then. Which should not be surprising, with serial communication to a display driver.

Here is the full part of the code, in which the problem is occurring.
The first part takes the received byte number and uses it to extract a message from the 18M2 OLED displays EEPROM
Which it then flashes 3 times on the top line of the display.
Then it moves on to the next process, by scrolling the preset message from the 14M2, along the bottom line of the display.
Once complete, it returns to wait for another fault or the same fault.

My issue is occurring between the flashing selection and the scrolling selection. The message flashes, but it does not always scroll the message following anymore.
I did remove this statement after having the problem. But it made no difference.
Code:
 if eeprom_message = %00000100 or eeprom_message =%00000101 then               ;this messages has no scrolling selection
 goto check 
 endif
It does not seem to be related to the message length, whether long or short. Plus I have used many different length messages over the years
and this has not occurred before.
And when it does occur. It will miss the scrolling message the first time. Then in most cases it will scroll next time around, if the error is still occurring.

Code:
flash_message_selector:
  select case rx_data
  case %00000001 to %00000110: eeprom_message = 10             
  case %00000111 to %00001001: eeprom_message = 8           
  case            = %00001010: eeprom_message = 1              
  case %00001011 to %00010000: eeprom_message = 7              
  case            = %00010001: eeprom_message = 1              
  case %00010010 to %00011000: eeprom_message = 13             
  case            = %00011101: eeprom_message = 4              
  case            = %00011110: eeprom_message = 5              
  endselect
 
 
flash:
  serout b.2,n2400_16,(254,1)
  pause 120
  for cycle=1 to 3                                             
  serout b.2,n2400_16,(254,2,254,128,253,eeprom_message)       
  pause 3000                                                   
  serout b.2,n2400_16,(254,128,253,1)	                  
  pause 800                                                    
  next cycle
  if eeprom_message = %00000100 or eeprom_message =%00000101 then               ;messages have no scroll selection
  goto check 
  endif
  
scroll:
  gosub scroll_message_selector
  do
  inc counter	                            
  if counter=60 then                        
  serout b.2,n2400_16,(254,1)                
  pause 200 
  let counter=0 	      	               
  goto check 
  endif                               
  serout b.2,n2400_16,(254,24)	         
  pause 600						   
  loop
     

scroll_message_selector:
  select case rx_data
  case %00000001,%00001101: serout b.2,n2400_16,(254,208,"message ")                            
  case %00000010,%00010000: serout b.2,n2400_16,(254,208,"message ")
  case %00000011,%00001111: serout b.2,n2400_16,(254,208,"message ")
  case %00000100,%00001110: serout b.2,n2400_16,(254,208,"message ")
  case %00000101,%00001100: serout b.2,n2400_16,(254,208,"message ")
  case %00000110,%00001011: serout b.2,n2400_16,(254,208,"message ")                      
  case =         %00000111: serout b.2,n2400_16,(254,208,"message ")
  case =         %00001000: serout b.2,n2400_16,(254,208,"message ")
  case =         %00001001: serout b.2,n2400_16,(254,208,"message ")        
  case =         %00001010: serout b.2,n2400_16,(254,208,"message ")                                            
  case =         %00010001: serout b.2,n2400_16,(254,208,"message ")                                              
  case =         %00010010: serout b.2,n2400_16,(254,208,"message ")       
  case =         %00010011: serout b.2,n2400_16,(254,208,"message ")
  case =         %00010100: serout b.2,n2400_16,(254,208,"message ")
  case =         %00010101: serout b.2,n2400_16,(254,208,"message ")
  case =         %00010110: serout b.2,n2400_16,(254,208,"message ")
  case =         %00010111: serout b.2,n2400_16,(254,208,"message ")
  case =         %00011000: serout b.2,n2400_16,(254,208,"message ")  
  endselect
  return
It is not possible to débug partial code...
Please, publish whole code or nothing
 

matchbox

Senior Member
It is not possible to débug partial code...
Please, publish whole code or nothing
To be honest. I don't want anyone to spend their time debugging this. Because the simulator shows everything to be working fine, throughout my testing.
Besides. There has already been much confusion to the reason I am trying to focus just on the Select/Case problem.
It may work in 99.9% application. But it hasn't for me in this application.
So even if its a timing issue of sorts. I am not going to limit the way I can add messages to this device, just for the sake of Select/Case issue, when I can just use IF/ENDIF and it all works fine.
Some things just aren't worth our time if we can work around them.

Thanks for your help in listening guys
 
Last edited:

hippy

Technical Support
Staff member
While you have a version which works it would be interesting to know what the actual cause of the issue is seeing as the PICAXE or compilers are getting blamed for the issue when that does not seem reasonable to us.

With more detail as to the exact nature of the problem; that it's the scrolling of the message which does not work, it suggest the error lies within that area. It would seem the issue is that the display is either not seeing those shifts or is not being sent any shifts.

In your code; where is 'counter' set ? And what value does it have on entry to the shift routine ?

From the N2400_16 it seems you are running at 16MHz so all your PAUSE times are shorter and characters are sent back-to-back with shorter inter-byte gaps than at default speed. Because your code is different it could be that token alignment in memory is being affected in that area which is altering the timing.

If it is a timing issue, the code on the brink of working and not working, then that is going to persist. You might have found a version which worked and a version which works now but any change in the future could push it from working to not working.

My opinion is that it would be better to try and determine what the cause is, make the code which doesn't work actually work, reveal what's actually making it not work.
 

BESQUEUT

Senior Member
While you have a version which works it would be interesting to know what the actual cause of the issue is seeing as the PICAXE or compilers are getting blamed for the issue when that does not seem reasonable to us...

If it is a timing issue, the code on the brink of working and not working, then that is going to persist. You might have found a version which worked and a version which works now but any change in the future could push it from working to not working.

My opinion is that it would be better to try and determine what the cause is, make the code which doesn't work actually work, reveal what's actually making it not work.
+1
We have an expression for this : ce programme est tombé en marche...
It may work in 99.9% application. But it hasn't for me in this application.
99.9% is not enought. I need 100%, and I am not alone...
 

hippy

Technical Support
Staff member
It may work in 99.9% application. But it hasn't for me in this application.
99.9% is not enought. I need 100%, and I am not alone...
As far as we are concerned SELECT-CASE is 100% correct but if it can be proven that it is not we will investigate that with the intent of fixing it.

So far we can see no evidence that there is any issue with SELECT-CASE but we are willing to help as much as we can to identify where the issue may lie.
 

BESQUEUT

Senior Member
As far as we are concerned SELECT-CASE is 100% correct but if it can be proven that it is not we will investigate that with the intent of fixing it.

So far we can see no evidence that there is any issue with SELECT-CASE but we are willing to help as much as we can to identify where the issue may lie.
I agree 999% :p
 

matchbox

Senior Member
While you have a version which works it would be interesting to know what the actual cause of the issue is seeing as the PICAXE or compilers are getting blamed for the issue when that does not seem reasonable to us.

With more detail as to the exact nature of the problem; that it's the scrolling of the message which does not work, it suggest the error lies within that area. It would seem the issue is that the display is either not seeing those shifts or is not being sent any shifts.

In your code; where is 'counter' set ? And what value does it have on entry to the shift routine ?

From the N2400_16 it seems you are running at 16MHz so all your PAUSE times are shorter and characters are sent back-to-back with shorter inter-byte gaps than at default speed. Because your code is different it could be that token alignment in memory is being affected in that area which is altering the timing.

If it is a timing issue, the code on the brink of working and not working, then that is going to persist. You might have found a version which worked and a version which works now but any change in the future could push it from working to not working.

My opinion is that it would be better to try and determine what the cause is, make the code which doesn't work actually work, reveal what's actually making it not work.
I agree with all you said Hippy.
Life is a little busy at the moment.
I suppose, when I started the post. I was looking for a quick answer that some else had experienced in this area. But it appears not.
When I get the time, I will look through everything at the level you explained above. And report back anything of interest or cause.

Thanks again for your time, and everyone's input who posted back.
 
Top