HP-15C LE -- endless loop in SOLVER - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: HP-15C LE -- endless loop in SOLVER (/thread-203023.html) |
HP-15C LE -- endless loop in SOLVER - Gerson W. Barbosa - 10-27-2011 The HP-15C LE will alternate forever between "running" and "Error 0" in this example:
001- f LBL A
Re: HP-15C LE -- endless loop in SOLVER - Jeroen Van Nieuwenhove - 10-27-2011 Interesting. The 15C emulator in Nonpareil gets stuck at the first error message, as would be expected. I suppose the original 15C behaves the same. This is strange, since the 15C LE is based on the same firmware. The error handling seems to be influenced in some way.
Re: HP-15C LE -- endless loop in SOLVER - Thomas Radtke - 10-27-2011 The emulator just blinks w/o showing 'running'.
Why does it blink in the first place?
Re: HP-15C LE -- endless loop in SOLVER - Kiyoshi Akima - 10-27-2011 The HHC2010 15C+ just stops with Error 0.
Re: HP-15C LE -- endless loop in SOLVER - uhmgawa - 10-27-2011 Quote:
I'd be quite surprised if this was due to a change in the
Gerson, is the alternating between "running" and "Error 0"
Running this on KEMU I find the expected behaviour. The display
Re: HP-15C LE -- endless loop in SOLVER - Gerson W. Barbosa - 10-27-2011 Yes, exactly the same rate of the display blinking frequency (according to my measurement).
Re: HP-15C LE -- endless loop in SOLVER - Marcus von Cube, Germany - 10-27-2011 You can stop it with any key. It looks like a display problem.
Re: HP-15C LE -- endless loop in SOLVER - Gerson W. Barbosa - 10-27-2011 No big issue like the PSE bug, I agree, but worth taking into account in a future firmware upgrade.
Re: HP-15C LE -- endless loop in SOLVER - uhmgawa - 10-28-2011 Quote:
Ah, I suspected it may be rooted in the lcd controller as it
Re: HP-15C LE -- endless loop in SOLVER - Marcus von Cube, Germany - 10-28-2011 You need to wait long enough after you have written to display memory before you can safely change the mode. The docs say it takes 2 refresh cycles but my experience is that waiting even longer is a good idea. WP 34S does not do a busy wait, the display refresh triggers an interrupt (at roughly 50 Hz) and the number of interrupts is counted. The logic is in the sources in main.c under LCD_interrupt():
/*I'm not using the blink option but I need the display memory for storing intermediate data. If I remove the 'else' part and clear the variable directly after mode switching, display memory gets corrupted. The trick is to wait for another cycle after switching to 'load only' mode. |