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 2 of 2
Goto page Previous  1, 2
EMJB
Posted: Sat Jun 11, 2011 8:37 pm Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
R2-D2 wrote:
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.


Unfortunately we have lost the wiki site which contained that sort of info, so I don't know where to look when using a function for the first time, or using it under different circumstances. Is there another with a list of all the TAP interface bugs?

EMJB
View user's profile Send private message
R2-D2
Posted: Sun Jun 12, 2011 9:43 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
Most of the normal ones you'd come across are fixed in FireBirdLib's TAPAPIFix section. I think that there isn't a fix for TAP_Print() because it'd have to use memory from somewhere so it's more about just being aware of what the size limit is.

_________________
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 23, 2011 10:48 am Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
I am beginning to think that acheiving zero lost bytes is going to be impossible. With only 8 byte hardware buffer, receipt of any messages longer than this is dependent on the processor not being grabbed for other purposes in any loop waiting for bytes to arrive. Am I right in thinking that a loop such as:
Code:
do
{
    if (TAP_KbHit() != 0)
         RxChar = TAP_GetCh();
    else
       RxChar = 0;
} while ...   


can get interrupted for low level housekeeping tasks?

If so are there any of these I can supend?

EMJB
View user's profile Send private message
R2-D2
Posted: Fri Jun 24, 2011 9:13 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
EMJB wrote:
can get interrupted for low level housekeeping tasks?

Yes, all "processes" get time-sliced, even the main one (which runs TAPs). This is the difference between normal USB transfer mode and Turbo (where this time-slicing is disabled). So all the functions which don't work in Turbo mode are the sorts of things that will also be eating up processor time when your TAP is running. Plus, TAPs don't get given every EVT_IDLE: they get 1/8 of them (in pairs). And then, on top of that, all of the main process's TSRs (like doing the recording handling) do get serviced on every Idle.

_________________
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 25, 2011 8:53 am Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
R2-D2 wrote:
EMJB wrote:
can get interrupted for low level housekeeping tasks?

Yes, all "processes" get time-sliced, even the main one (which runs TAPs). This is the difference between normal USB transfer mode and Turbo (where this time-slicing is disabled). So all the functions which don't work in Turbo mode are the sorts of things that will also be eating up processor time when your TAP is running. Plus, TAPs don't get given every EVT_IDLE: they get 1/8 of them (in pairs). And then, on top of that, all of the main process's TSRs (like doing the recording handling) do get serviced on every Idle.
Thanks for the clarification - looks like I need to concentrate on error tolerance rather than further efforts to reduce the error rate.

EMJB
View user's profile Send private message
EMJB
Posted: Sun Jun 26, 2011 12:06 pm Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
R2-D2 wrote:
EMJB wrote:
can get interrupted for low level housekeeping tasks?

Yes, all "processes" get time-sliced, even the main one (which runs TAPs). This is the difference between normal USB transfer mode and Turbo (where this time-slicing is disabled). So all the functions which don't work in Turbo mode are the sorts of things that will also be eating up processor time when your TAP is running. Plus, TAPs don't get given every EVT_IDLE: they get 1/8 of them (in pairs). And then, on top of that, all of the main process's TSRs (like doing the recording handling) do get serviced on every Idle.


Interactive On consumes so much time that the chances of a 150 byte message getting through unscathed seem minimal. Recording, including time-shifting, and Subtitles On both seem to approximately double the lost byte rate.

EMJB
View user's profile Send private message
EMJB
Posted: Tue Jun 28, 2011 7:21 pm Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
R2-D2 wrote:
Most of the normal ones you'd come across are fixed in FireBirdLib's TAPAPIFix section. I think that there isn't a fix for TAP_Print() because it'd have to use memory from somewhere so it's more about just being aware of what the size limit is.


Is the size limit actually 255 bytes, or is it something less? I am having trouble with some spurious output. I have tried doing a TAP_PutCh() on each byte of the string but that is no better>

EMJB
View user's profile Send private message
R2-D2
Posted: Wed Jun 29, 2011 6:52 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
EMJB wrote:
Is the size limit actually 255 bytes, or is it something less?

The area of stack reserved is exactly 256 bytes, so that's a maximum string length of 255 real characters (with null termination). Any more than that and the first thing that gets overwritten is the return address of the calling function (EEK!).

_________________
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 30, 2011 7:09 pm Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
R2-D2 wrote:
EMJB wrote:
Is the size limit actually 255 bytes, or is it something less?

The area of stack reserved is exactly 256 bytes, so that's a maximum string length of 255 real characters (with null termination). Any more than that and the first thing that gets overwritten is the return address of the calling function (EEK!).


Thanks for confirming that - have found my source of stray bytes elsewhere!

EMJB
View user's profile Send private message
EMJB
Posted: Tue Jul 19, 2011 6:43 pm Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3632 Location: Maldon Essex
This is the code I am using to receive the serial data:
Code:
switch(wEvent)
   /* ------------------------------------------------------------------------------------ */
   {
       case EVT_UART:                                    // Character(s) received on serial input. Note 8 byte hardware buffer only!!

      {   
         bool      FoundLastChar = FALSE;
         
         RxChar = (byte) dwParam1;
         MsgTimeOut = TAP_GetTick() + MaxMsgTime;            // Define latest end of message time, so don't wait for ever if terminating character lost
         do
         {
            if (TAP_GetTick() > MsgTimeOut)                  // Terminating character apparently lost
            {
               memset(M1Str,0,sizeof(M1Str));
               strncpy(M1Str,Msg,40);
               if (Active)
               {
                  DisplayProgress("End of message not recd within allowed time",M1Str,"",TRUE);
                  TAP_Delay(ErrorDisplayTime);
               }
               memset(Msg,0,sizeof(Msg));            // Abandon message
               CharNo = 0;
               break;                           // From do/while loop, not from EVT_UART!!!
            }
         
            if (RxChar == TermChar)                   // Found terminating character
            {
               FoundLastChar = TRUE;
               ClearRxBuffer();
               if (PosString(Msg,"41") == 0) SetActive(TRUE);
               if (Active)
               {
                  if (strlen(Msg) > 0)
                     ProcessMsg();                  // Process message and take relevant action
                  else
                  {
                     TAP_SPrint(SData,"34 - Blank message received by %s%c",StateName,(char) TermChar);
                     SendSerialMsg(SData);
                     DisplayProgress("Blank message received","","",TRUE);
                  }
               }
               CharNo = 0;
               RxChar = 0;
               memset(Msg,0,sizeof(Msg));
               break;                           // From do/while loop, not from EVT_UART!!!
            }
            else
            {
               if ((CharNo + 2 < MaxMsgLength) && (RxChar !=  0)) 
               {
                  Msg[CharNo] = RxChar;
                  CharNo++;
               }
            }
            if (TAP_KbHit() != 0)
               RxChar = TAP_GetCh();
            else
               RxChar = 0;   
         }   while (!FoundLastChar);
         returnKey = 0;
         break;
      }

just in case anyone else wants to try using the serial channel.

If messages of more than 8 bytes are to be sent, it is essentail that "Interactive" is switched off. To minimise erors, ensure subtitles are off and both channels stopped.

EMJB
View user's profile Send private message

Display posts from previous:  

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

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