Click here to go to the forum index Click here for the home page
 
Author Message

<  TAP and patch development  ~  Serial Data To The Toppy

Page 1 of 2
Goto page 1, 2  Next
EMJB
Posted: Tue May 31, 2011 9:14 am Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
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
View user's profile Send private message
ccs
Posted: Tue May 31, 2011 9:57 am Reply with quote
Frequent contributor Joined: 30 Oct 2007 Posts: 2577
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
View user's profile Send private message
EMJB
Posted: Tue May 31, 2011 1:04 pm Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
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
View user's profile Send private message
R2-D2
Posted: Tue May 31, 2011 5:41 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
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).

_________________
Troubleshooting -- User Manual -- Dark Side of the Matrix: Firmwares and Patches
View user's profile Send private message Visit poster's website
EMJB
Posted: Wed Jun 01, 2011 8:23 am Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
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
View user's profile Send private message
R2-D2
Posted: Wed Jun 01, 2011 9:40 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
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.

_________________
Troubleshooting -- User Manual -- Dark Side of the Matrix: Firmwares and Patches
View user's profile Send private message Visit poster's website
EMJB
Posted: Wed Jun 01, 2011 5:22 pm Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
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
View user's profile Send private message
Geoff Bacon
Posted: Wed Jun 01, 2011 5:38 pm Reply with quote
Frequent contributor Joined: 12 Jan 2007 Posts: 4377
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+EvEzPfUUuZ
TAPs: PcControl B1.4; StopExit v1.01; PruneEPG 1.0; fsSave 1.1; QuickJump 1.72; SecCache (UK) v0.4; EIT Sub (Game) v0.6; EPG2MEI v0.96; MyStuff 6.6; Bookmark 3.0; Extend v1.7; Font Manager 1.0d; MyInfo B5.6; MHEG On/Off A3;
Sig generated by EMJB's MyInfo.tap on 29/12/18
View user's profile Send private message Visit poster's website
EMJB
Posted: Wed Jun 01, 2011 5:55 pm Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
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
View user's profile Send private message
R2-D2
Posted: Wed Jun 01, 2011 8:30 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
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.

_________________
Troubleshooting -- User Manual -- Dark Side of the Matrix: Firmwares and Patches
View user's profile Send private message Visit poster's website
EMJB
Posted: Thu Jun 02, 2011 5:13 pm Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
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
View user's profile Send private message
R2-D2
Posted: Thu Jun 02, 2011 9:10 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
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.

_________________
Troubleshooting -- User Manual -- Dark Side of the Matrix: Firmwares and Patches
View user's profile Send private message Visit poster's website
EMJB
Posted: Sat Jun 11, 2011 12:00 pm Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
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
View user's profile Send private message
Geoff Bacon
Posted: Sat Jun 11, 2011 12:49 pm Reply with quote
Frequent contributor Joined: 12 Jan 2007 Posts: 4377
255 is maximum value in a byte?

Geoff

_________________
TopManager program
TF5800, TS On, F/W: MS6 Recommended F/W 12/9/2009 -Sy+EvEzPfUUuZ
TAPs: PcControl B1.4; StopExit v1.01; PruneEPG 1.0; fsSave 1.1; QuickJump 1.72; SecCache (UK) v0.4; EIT Sub (Game) v0.6; EPG2MEI v0.96; MyStuff 6.6; Bookmark 3.0; Extend v1.7; Font Manager 1.0d; MyInfo B5.6; MHEG On/Off A3;
Sig generated by EMJB's MyInfo.tap on 29/12/18
View user's profile Send private message Visit poster's website
R2-D2
Posted: Sat Jun 11, 2011 5:42 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
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.

_________________
Troubleshooting -- User Manual -- Dark Side of the Matrix: Firmwares and Patches
View user's profile Send private message Visit poster's website

Display posts from previous:  

All times are GMT + 1 Hour
Page 1 of 2
Goto page 1, 2  Next

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum