Reply to thread

Message

<blockquote data-quote="cybrmage" data-source="post: 219950" data-attributes="member: 51680">Wel... It seems that, for me, the new year is getting off to a bad start...Although I did learn a few things...1) NEVER do coding on new years day!!!2) NEVER do coding after a &quot;party&quot;!!3) When coding a state machine... TURN IT ON!!!&nbsp;&nbsp; 8-}Opps... Sorry... mea culpa...What I am trying to do is &quot;marshal&quot; the information that the display sends to the driver... From the last set of MHC logs, it appears the the display sends an identity string to MHC when initialized (10 bytes &quot;MZ4MZ4MZ4M&quot;... and running these bytes through the data routines would generate spurious remote button presses.. so the receive routines do not start reading data until a flag is set to indicate that it should start processing the data... The data is left in the receive buffer... The Initialize() routine opens the port and sends the initialization commands, the flushes the receive buffer, the set the processing flag.... I, of course, forgot to set the processing flag!!! (BAD PROGRAMMER!!! no caffine ration for you! 8-} )Yep... I need to add a number 4 to the above list... 4) learn to count...In the changes to the Cleanup() routine, I miscounted the numbers of bytes sent to the display, causing MediaPortal to crash... So the required shutdown commands are never sent to the display... 8-{I hope so... I'm looking over the logs now... With the number of logs you provided, I should be done by July... 8-} (I'm kidding!!! the amount of logging you are doing is GREAT!!!)0XA4, 0x760x02&nbsp;&nbsp; Minutes0x0D&nbsp;&nbsp; Hours0x02&nbsp;&nbsp; Day 0x1F&nbsp;&nbsp; Days In Month0x04&nbsp;&nbsp; Day Of Week ( 1 - 7: 1 = Sunday)0x01&nbsp;&nbsp; Month0x0A&nbsp;&nbsp; Seconds0x0B&nbsp;&nbsp; Unknown (possibly the year offset)This information was provided by -Manfred- in one of his source code edits.Here is a quick fix for the last driver... complete logging is not required (yet 8-}, just the mediaportal.log for now...Feedback on it's functionality is eagerly (and fearfully) awaited 8-}Again... My appologies for all the work I caused you... hopefully, some good will come of it! 8-}Regards,CybrMage[UPDATE] Apparently, (the &quot;COMPLETE&quot; log you posted seems to verify it), the {0xAA, 0xAA } command is an &quot;Identify&quot; command... The display responds with &quot;MZ4&quot;.During initialization, MHC open the port, sends 0xA4, 0x7D0xAA, 0xAA0xAA, 0xAA0xAA, 0xAA0xAA, 0xAA0xAA, 0xAA0xAA, 0xAA0xAA, 0xAA0xAA, 0xAA0xAA, 0xAA0xAA, 0xAAand closes the port... and the opens the port and starts communication with the display... so the routine MUST be part of the MHC device detection routine.... which make the 0xA$, 0x7D a &quot;Wakeup&quot; or &quot;Reset&quot; command... (I suspect it's a soft reset... MHC sends 10 &quot;Identify&quot; commands, but only receives 8 responses...)</blockquote>

[QUOTE="cybrmage, post: 219950, member: 51680"] Wel... It seems that, for me, the new year is getting off to a bad start... Although I did learn a few things... 1) NEVER do coding on new years day!!! 2) NEVER do coding after a "party"!! 3) When coding a state machine... TURN IT ON!!! 8-} Opps... Sorry... mea culpa... What I am trying to do is "marshal" the information that the display sends to the driver... From the last set of MHC logs, it appears the the display sends an identity string to MHC when initialized (10 bytes "MZ4MZ4MZ4M"... and running these bytes through the data routines would generate spurious remote button presses.. so the receive routines do not start reading data until a flag is set to indicate that it should start processing the data... The data is left in the receive buffer... The Initialize() routine opens the port and sends the initialization commands, the flushes the receive buffer, the set the processing flag.... I, of course, forgot to set the processing flag!!! (BAD PROGRAMMER!!! no caffine ration for you! 8-} ) Yep... I need to add a number 4 to the above list... 4) learn to count... In the changes to the Cleanup() routine, I miscounted the numbers of bytes sent to the display, causing MediaPortal to crash... So the required shutdown commands are never sent to the display... 8-{ I hope so... I'm looking over the logs now... With the number of logs you provided, I should be done by July... 8-} (I'm kidding!!! the amount of logging you are doing is GREAT!!!) 0XA4, 0x76 0x02 Minutes 0x0D Hours 0x02 Day 0x1F Days In Month 0x04 Day Of Week ( 1 - 7: 1 = Sunday) 0x01 Month 0x0A Seconds 0x0B Unknown (possibly the year offset) This information was provided by -Manfred- in one of his source code edits. Here is a quick fix for the last driver... complete logging is not required (yet 8-}, just the mediaportal.log for now... Feedback on it's functionality is eagerly (and fearfully) awaited 8-} Again... My appologies for all the work I caused you... hopefully, some good will come of it! 8-} Regards, CybrMage [UPDATE] Apparently, (the "COMPLETE" log you posted seems to verify it), the {0xAA, 0xAA } command is an "Identify" command... The display responds with "MZ4". During initialization, MHC open the port, sends 0xA4, 0x7D 0xAA, 0xAA 0xAA, 0xAA 0xAA, 0xAA 0xAA, 0xAA 0xAA, 0xAA 0xAA, 0xAA 0xAA, 0xAA 0xAA, 0xAA 0xAA, 0xAA 0xAA, 0xAA and closes the port... and the opens the port and starts communication with the display... so the routine MUST be part of the MHC device detection routine.... which make the 0xA$, 0x7D a "Wakeup" or "Reset" command... (I suspect it's a soft reset... MHC sends 10 "Identify" commands, but only receives 8 responses...) [/QUOTE]

Verification