Topics

QCX - Odd freq display behavior #qcx #80m


Scott - N1ST
 

I'm enjoying playing with the menus and learning about all the clever features (a scan feature would be nice hint, hint.)  The first day, no oddities.  The second day of play, the 2 least significant digits would disappear intermittently while tuning.  Once, an odd character appeared.  I do have battery, clock, and S-meter enabled.  This is the v5 board and latest firmware. Am I tuning too fast for the MC?


Hans Summers
 

Hello Scott 

Another person reported this display glitch yesterday and I need to have a look at what is going on here! It appears to be just an occasional self-correcting cosmetic irritation but, I will try and find out what is causing it. 

73 Hans G0UPL 

73 Hans G0UPL 

On Sun, Apr 26, 2020, 14:05 Scott via groups.io <n1st=yahoo.com@groups.io> wrote:
I'm enjoying playing with the menus and learning about all the clever features (a scan feature would be nice hint, hint.)  The first day, no oddities.  The second day of play, the 2 least significant digits would disappear intermittently while tuning.  Once, an odd character appeared.  I do have battery, clock, and S-meter enabled.  This is the v5 board and latest firmware. Am I tuning too fast for the MC?


Scott - N1ST
 

Good deal Hans.  I realize now that the odd character is simply the S-meter moved over to the left with the _ underscore beneath.
Scott


WBØAUQ
 

Also noted the frequent disappearance of, usually, two lest-significant digits while tuning.  This after updating to T1.04 firmware.
Not so bothersome, especially now that I know it's not just me.
Really like ability to select delimiter as did not like the period (.) nor comma (,).  Blank space is my preference.
Thanks Hans!
-Bob


Manuel; DL2MAN
 

I made this oberservation too, but only when turning the encoder knob (too) fast.
I guess the scan rate for the encoder might be too low.


Hans Summers
 

Nothing is related to the scan rate of the encoder being too low.

The problem is different processed in the firmware are all trying to access the LCD at the same time. Not ACTUALLY at the same time, since this IS a simple microcontroller without multiple cores in parallel. But multiple processes doing their LCD writes are interweaving with each other, and it leads to the noted corruption of the display. The display should be viewed as a resource and only one process should be allowed to access it at a time. When it completes its multiple-character write to the display, it should release the reservation and allow another process to do its writes. 

It works correctly for most of the processors updating the display but there is clearly something still in there which ignores the resource lock (reservation). So I just need to track that down...

Maybe it sounds simple but in reality it is not so. Remember there are only 32KBytes of Flash (program memory). It doesn't exactly run Windows 10 in there. There are a lot of shortcuts. A fine line can easily be crossed, into one-short-cut-too-many territory. 

Don't worry I will find it.

73 Hans G0UPL 

On Sun, Apr 26, 2020, 22:07 <DL2MAN@...> wrote:
I made this oberservation too, but only when turning the encoder knob (too) fast.
I guess the scan rate for the encoder might be too low.


Syd
 

I don't know what programming language is used for this code, but I do know a real time task should have been allocated to the display. Probably this was written as a round robin solution instead of parallel tasks. If it was task driven you will probably find that there is a deadlock. Good luck with that. 


Arv Evans
 

Syd

I think that Hans uses mostly C-language for his products, with maybe 
a bit of machine code when necessary.  The real problem is that the AVR 
micro-controller chip is a single-threaded processor.  Some functions 
need to be written in blocking manner in order to insure completion, 
but this can interfere with other time-sensitive functions.  

There are several ways to get around this and still keep the AVR or 
STM103 series of micro-controller.  The most obvious way is just to 
rearrange the sequence of actions.  Another way might be to use 
interrupt handling for problem UI stuff, allowing return() from interrupt 
to continue the interrupted action or state.

There real-time code cores for the AVR micro-controllers but they work 
by buffering everything out to a standard time step.  This makes them 
way too slow for most high-density code systems.  

Arv
_._


On Sun, Apr 26, 2020 at 1:52 PM Syd via groups.io <nhuq1=yahoo.com@groups.io> wrote:
I don't know what programming language is used for this code, but I do know a real time task should have been allocated to the display. Probably this was written as a round robin solution instead of parallel tasks. If it was task driven you will probably find that there is a deadlock. Good luck with that. 


Jim Allyn - N7JA
 

On Sun, Apr 26, 2020 at 12:33 PM, Hans Summers wrote:
It doesn't exactly run Windows 10 in there.
Well, that's certainly one point in its favor.


scot forshaw
 

Hey Hans, I had this issue in the 1.03 and 1.04 firmware, often when the radio is idle it will just loose the least significant digits until you rock the vfo. 

I feel for you buddy as a professional programmer aome of which is using 1602 displays I know how hard it is to work with that stupid memory limit!

73 for now 
Scot
2E0WWV 


On 26 Apr 2020, at 20:33, Hans Summers <hans.summers@...> wrote:


Nothing is related to the scan rate of the encoder being too low.

The problem is different processed in the firmware are all trying to access the LCD at the same time. Not ACTUALLY at the same time, since this IS a simple microcontroller without multiple cores in parallel. But multiple processes doing their LCD writes are interweaving with each other, and it leads to the noted corruption of the display. The display should be viewed as a resource and only one process should be allowed to access it at a time. When it completes its multiple-character write to the display, it should release the reservation and allow another process to do its writes. 

It works correctly for most of the processors updating the display but there is clearly something still in there which ignores the resource lock (reservation). So I just need to track that down...

Maybe it sounds simple but in reality it is not so. Remember there are only 32KBytes of Flash (program memory). It doesn't exactly run Windows 10 in there. There are a lot of shortcuts. A fine line can easily be crossed, into one-short-cut-too-many territory. 

Don't worry I will find it.

73 Hans G0UPL 

On Sun, Apr 26, 2020, 22:07 <DL2MAN@...> wrote:
I made this oberservation too, but only when turning the encoder knob (too) fast.
I guess the scan rate for the encoder might be too low.