For discussions about development of TAPs, patches and other software for the Toppy

Moderator: Technical

EMJB
Frequent contributor
Posts: 3645
Joined: Fri Jul 08, 2005 9:43 am
Location: Maldon Essex

Serial Data To The Toppy

Post by EMJB »

The TAP functions include those necessary for TAPs to receive data from the serial port, and these seem to work OK provided the text does not include any substring recognisedby the command console.

Does anyone know how to disable the command console from within a TAP, or know of any other solution to this problem?

EMJB
ccs
Frequent contributor
Posts: 2689
Joined: Tue Oct 30, 2007 3:19 pm

Post by ccs »

The command console seems to be off by default, and [Gx] can switch it on.

edit: maybe this only applies to the extended command console.
TF5810, F/W: MS6 Recommended F/W 12/9/2009 -FmXl+CtEzIScVdZ
TAPs: EIT Sub v0.6; EPG2MEI v0.96; MPDisplayLITE V1.2; MyInfo B5.6; SecCache (UK) v0.4; Extend v1.7; MyStuff 6.6;
Sig generated by MyInfo on 20/10/14
ccsx
EMJB
Frequent contributor
Posts: 3645
Joined: Fri Jul 08, 2005 9:43 am
Location: Maldon Essex

Post by EMJB »

ccs wrote:The command console seems to be off by default, and [Gx] can switch it on.

edit: maybe this only applies to the extended command console.
My understanding is Gx only applies to extended console - simple console works with MS recommended S/W without any conscious action on my part.

EMJB
R2-D2
Frequent contributor
Posts: 12148
Joined: Mon Dec 18, 2006 11:15 am
Contact:

Post by R2-D2 »

I think you're meant to collect the EVT_UART that are sent to your TAP's event handler, and return 0 when you want to absorb a char (so it isn't passed to the command console, or other TAPs).
EMJB
Frequent contributor
Posts: 3645
Joined: Fri Jul 08, 2005 9:43 am
Location: Maldon Essex

Post by EMJB »

R2-D2 wrote:I think you're meant to collect the EVT_UART that are sent to your TAP's event handler, and return 0 when you want to absorb a char (so it isn't passed to the command console, or other TAPs).
Doing the EVT_UART bit, but:

(1) According to V1.22 of the Topfield TAP document para 4.2 the return value has no effect. However knowing the reliability of such info, I will try reurning zero and see what happens!

(2) Within the EVT_UART call I have a loop inputting characters so long as TAP_KbHit is non-zero on the basis that I expect a character ~ evry 100 microsecs which seems too frequent for evant handling.

Incidentally I have tried slowing the serial rate by a factor of 7, and the problem seems much the same.

EMJB
R2-D2
Frequent contributor
Posts: 12148
Joined: Mon Dec 18, 2006 11:15 am
Contact:

Post by R2-D2 »

How much data are you expecting? And how much do you get before it does wrong? A tight loop of TAP_KbHit() and TAP_GetCh() triggered from an EVT_UART seems to me like it ought to work.
EMJB
Frequent contributor
Posts: 3645
Joined: Fri Jul 08, 2005 9:43 am
Location: Maldon Essex

Post by EMJB »

R2-D2 wrote:How much data are you expecting? And how much do you get before it does wrong? A tight loop of TAP_KbHit() and TAP_GetCh() triggered from an EVT_UART seems to me like it ought to work.
Currently typically trying to transfer strings ~ 20 bytes, and it seems fairly random whether it fails, and where in the string it fails. Often it is the front that is missing, which was what made me suspect that the command console might be getting the data. If my loop were too slow, I would have expected cutting the spped to make a dramatic improvement, but didn't seem to make any difference
Geoff Bacon
Frequent contributor
Posts: 4663
Joined: Fri Jan 12, 2007 12:21 am
Location: Bristol
Contact:

Post by Geoff Bacon »

Are you polling the UART to see if it is ready or are you using interrupts when the device is ready to receive/send?

I know that in my distant past (programming PDPs with realtime models), we used to occasionally miss characters when we polled (I think the problem arises if you poll at the same time as a character is being received). Our solution was to collect the characters in an interrupt routine and then to retrieve these at our leisure.
Whether this fits into how you want to program it is another matter!

Geoff
TopManager program
TF5800, TS On, F/W: MS6 Recommended F/W 12/9/2009 -Sy+EvEzPePfUUuZ
TAPs: PcControl B1.4; StopExit v1.01; MHEG On/Off A3; QuickJump 1.72; EIT Sub (Game) v0.6; SecCache (UK) v0.4; EPG2MEI v0.96; Font Manager 1.0d; Extend v1.7; WSSkiller V2.12d; MyInfo B5.6; fsSave 1.1; PruneEPG 1.0; MyStuff 6.6-1;
Sig generated by EMJB's MyInfo.tap on 3/5/21
EMJB
Frequent contributor
Posts: 3645
Joined: Fri Jul 08, 2005 9:43 am
Location: Maldon Essex

Post by EMJB »

Geoff Bacon wrote:Are you polling the UART to see if it is ready or are you using interrupts when the device is ready to receive/send?

I know that in my distant past (programming PDPs with realtime models), we used to occasionally miss characters when we polled (I think the problem arises if you poll at the same time as a character is being received). Our solution was to collect the characters in an interrupt routine and then to retrieve these at our leisure.
Whether this fits into how you want to program it is another matter!

Geoff
The EVT_UART mentioned by R2-D2 is an interrupt, and the TAP_KbHit() and TAP_GetCh() loop is effectively polling. I would have expected the UART's buffer to cope with the problem you saw on PDPs.

Does nayone know the UART buffer length? Perhaps other Toppy activities are locking out the interrupt for long enough for the buffer to overflow - will look more carefully at that possibility in the next few days.

EMJB
R2-D2
Frequent contributor
Posts: 12148
Joined: Mon Dec 18, 2006 11:15 am
Contact:

Post by R2-D2 »

Vaguely remember that it's a 16-byte buffer on the hardware. If the Toppy being overloaded is messing this up then you could try always doing the TAP_KbHit()/TAP_GetCh() in your event handler even when you didn't get an EVT_UART. You may also want to see whether there's a significant difference in accuracy when you're running no other TAPs. And the Toppy is most likely to be overloaded a bit for the first few minutes after booting, due to EIT processing.
EMJB
Frequent contributor
Posts: 3645
Joined: Fri Jul 08, 2005 9:43 am
Location: Maldon Essex

Post by EMJB »

If the UART Buffer is only 16 bytes, that fills within ~2ms at 115200 bits per second, so it will be very easy for any other Toppy activities to cause the buffer to overflow, or let the command console get at the received data string.

Have improved things by making sure no other TAPs are receiving events, and ensuring the TAP_KbHit() and TAP_GetCh() loop is as short as possible, but not done enough tests to be sure all is well.

If I do end up with code that works, I will post it here for others to use.

Thanks everyone for your help.

EMJB
R2-D2
Frequent contributor
Posts: 12148
Joined: Mon Dec 18, 2006 11:15 am
Contact:

Post by R2-D2 »

Try a tight TAP_KbHit()/TAP_GetCh() loop and then TAP_SystemProc() outside of it? This way you force the EVT_IDLE processing to when the buffer is empty, but that may still not be enough if there's lots of other stuff going on.
EMJB
Frequent contributor
Posts: 3645
Joined: Fri Jul 08, 2005 9:43 am
Location: Maldon Essex

Post by EMJB »

Have failed to get 100% successful transfer rate to the Toppy - losing ~1 byte in 10,000 but have a few things to investigate.

As an aside, there appears to be a limit on the sting length sent by TAP_Print - I seem to get crashes if the string is longer than something around 256 bytes. Anyone else seen this?

EMJB
Geoff Bacon
Frequent contributor
Posts: 4663
Joined: Fri Jan 12, 2007 12:21 am
Location: Bristol
Contact:

Post by Geoff Bacon »

255 is maximum value in a byte?

Geoff
TopManager program
TF5800, TS On, F/W: MS6 Recommended F/W 12/9/2009 -Sy+EvEzPePfUUuZ
TAPs: PcControl B1.4; StopExit v1.01; MHEG On/Off A3; QuickJump 1.72; EIT Sub (Game) v0.6; SecCache (UK) v0.4; EPG2MEI v0.96; Font Manager 1.0d; Extend v1.7; WSSkiller V2.12d; MyInfo B5.6; fsSave 1.1; PruneEPG 1.0; MyStuff 6.6-1;
Sig generated by EMJB's MyInfo.tap on 3/5/21
R2-D2
Frequent contributor
Posts: 12148
Joined: Mon Dec 18, 2006 11:15 am
Contact:

Post by R2-D2 »

EMJB wrote:As an aside, there appears to be a limit on the sting length sent by TAP_Print - I seem to get crashes if the string is longer than something around 256 bytes. Anyone else seen this?
One of the oldest known firmware bugs, I thought? It formats its string using a temporary on the stack. Very bad things can happen without being immediately obvious.
Post Reply