![]() The complete program compiles and work properly in all versions when $CRYSTAL = 32MHz. This code snippet has been used for some time in Bascom versions 2.0.7.8, 2.0.7.9 and 2.0.8.0. This problem is a little difficult to explain. ![]() Possibly the easiest way for me to test that theory right now is to recompile the M8's code on 2.0.8.0 - as again I will hopefully be in a position where any error cancels out. I wonder now whether utilising the double speed mode is resulting in a more accurate baud rate calculation on the M128's side and therefore causing the comms error. This didn't matter previously as both chips are clocked at 16MHz so any calc error should mutually cancel out. ![]() It occurs to me that M8 and M128 are talking to each other at 1.5Mbit/sec bitrate (at least according to the code) - but on a 16MHz crystal there is 33% baud rate calc error reported by Bascom. That's all now and I can subsequently ramp the USB interface's baud rate up to 1MBit/sec exactly as I used to - so that much at least is sorted. Loop Until Rx(i) = &H3A Or Rxdel = 255 'cut out of the loop if we reach end of line or timeoutīecause the init routine for the M8 executed first and was failing, the next one was running before the VNC1L had started up and sent its login string. Rx(i) = Inkey(#3) 'store value in byte array If Ischarwaiting(#3) = 1 Then 'check for character from VNC1L They use an Ischarwaitng loop as per P_Santos' suggestion: The real code on the M128 includes an initialisation routine that determines whether the subprocessors are connected - and if not, gracefully cuts out their functionality from the rest of execution. Okay, so the VNC1L part of the problem is now fully solved and the cause understood.
0 Comments
Leave a Reply. |