Forum - MCS Electronics

 
FAQFAQ SearchSearch RegisterRegister Log inLog in

USART issues, 2.0.7.6 vs later

 
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR
View previous topic :: View next topic  
Author Message
richhbd

Bascom Member



Joined: 03 Feb 2006
Posts: 52

blank.gif
PostPosted: Sun Feb 26, 2017 7:58 am    Post subject: USART issues, 2.0.7.6 vs later Reply with quote
Hi all,

I'm recently picking up a project after a long hiatus, and have run into a problem with the most recent builds of the IDE. My project includes three microcontrollers (an M128, which is the master controller, an M8 and an FTDI VNC1L USB host chip). The M8 is connected to UART0 on the M128 and the VNC1L to UART1. The entire project compiles and works fine in Bascom AVR 2.0.7.6 and earlier - but as soon as I upgrade to anything newer (2.0.7.7 all the way to 2.0.8.0) and recompile the M128's code, it wouldn't talk to either of the other micros. Here's an example:

Code:
$regfile = "m128def.dat"
$crystal = 16000000
$hwstack = 64
$swstack = 24
$framesize = 48


Dim R As Byte


Config Com1 = 1500000 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
Config Serialin = Buffered , Size = 8
Config Serialout = Buffered , Size = 8

Config Graphlcd = 240 * 128 , Dataport = Porta , Controlport = Portc , Cd = 0 , Rd = 1 , Wr = 2 , Ce = 3 , Reset = 4 , Fs = 5 , Mode = 6


Enable Interrupts                                           'enable the interrupts

Open "com1:" For Binary As #1                 'open the channel to the ATMega8

Wait 1                                                      'allows the M8 to initalise.

Locate 3 , 1
Lcd "sending A0 command"

Locate 5 , 1                                             'position the cursor

Printbin #1 , &HA0                                          'tells the M8 to send some data


'check for a response
Do
               R = Inkey(#1)
               If R > 0 Then Lcd Hex(r)
Loop



Close #1

Stop
 


If I compile and flash the above to the M128 using 2.0.7.6 everything works - the M8 sends back the expected responses to the A8 command. However if I compile exactly the same code with any newer version of the IDE, I get no response from the M8 at all. I've checked the History files and also scanned through the help file and here but I haven't found any hints. Any ideas before I start pulling things further to pieces to check what (if anything) the M8 is receiving? Thanks in advance :-)

(BASCOM-AVR version : 2.0.8.0 , Latest : 2.0.7.8 )
Back to top
View user's profile
P_Santos

Bascom Member



Joined: 07 Jul 2011
Posts: 112
PostPosted: Sun Feb 26, 2017 12:11 pm    Post subject: Reply with quote
Hello richbd,

For year ago i have a similar problem but with Inputbin
and to work i have to add a waitms 3 after If ischarwaiting , so
test it with a little delay in your Do ..Loop

Regards
P_Santos
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5483
Location: Holland
blank.gif
PostPosted: Sun Feb 26, 2017 1:03 pm    Post subject: Reply with quote
do you use a boot loader?
the only thing changed for the UART is when calculating the baud, the u2x bit is used when available. see also the history.txt

just compile and check with a terminal emulator if the baud is what you expect.
_________________
Mark
Back to top
View user's profile Visit poster's website
richhbd

Bascom Member



Joined: 03 Feb 2006
Posts: 52

blank.gif
PostPosted: Sun Feb 26, 2017 4:59 pm    Post subject: Reply with quote
Hi both, thanks for the responses. Mark: No bootloader, I use ISP for both the AVRs in this project. The M128 has an externally accessible port while the M8 is socketed so if there is a need to upgrade firmware or troubleshoot I can do so. I did spot the reference to the 2x bit in the 2.0.7.7 history and surmised this was the likeliest contributor but am only now reading up the chip's datasheet to understand the possible consequences. Thank you P_Santos too - I did wonder whether timing is an issue - and prior to posting the example code I tried something similar to your suggestion, and it didn't make any difference to comms with the M8 - but *is* an issue with the live code that communicates with the VNC1L.

What is potentially more confusing is that I have now re-established comms between the M128 and the VNC1L using code that works on both 2.0.8.0 and 2.0.7.6 - but the differences between the two are interesting. I will work up another example and post back in a bit. Smile
Back to top
View user's profile
richhbd

Bascom Member



Joined: 03 Feb 2006
Posts: 52

blank.gif
PostPosted: Sun Feb 26, 2017 8:22 pm    Post subject: Reply with quote
Okay, so the VNC1L part of the problem is now fully solved and the cause understood. 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. They use an Ischarwaitng loop as per P_Santos' suggestion:

Code:
Rxdel = 0                                                   'zero the RX delay counter
Do
If Ischarwaiting(#3) = 1 Then                               'check for character from VNC1L
      Incr I                                                           'increment string length counter
      Rx(i) = Inkey(#3)                                         'store value in byte array
      End If
Waitms 1
Incr Rxdel

      Loop Until Rx(i) = &H3A Or Rxdel = 255                       'cut out of the loop if we reach end of line or timeout
 



Because 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 ID/login string. That's fixed 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.

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. This didn't matter previously as both chips are clocked at 16MHz so any calc error should mutually cancel 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. 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. Will try it and see... *as soon as I find my M8 proto board... Rolling Eyes
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5483
Location: Holland
blank.gif
PostPosted: Sun Feb 26, 2017 9:37 pm    Post subject: Reply with quote
there is a simpler way : remark the U2X? in the dat file.
this will use the old method of calculating the baud.
_________________
Mark
Back to top
View user's profile Visit poster's website
richhbd

Bascom Member



Joined: 03 Feb 2006
Posts: 52

blank.gif
PostPosted: Mon Feb 27, 2017 1:28 am    Post subject: Reply with quote
Perfect, thanks Mark, that's cracked it. I was wondering if there was a way to do that - I had already explored trying to reset u2x in code.

Now I've got a handle on what the problem was, I can get used to the new features in the IDE and pick the project back up at leisure. Diolch yn fawr, as they say in Wales. Smile
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR All times are GMT + 1 Hour
Page 1 of 1

 
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
You cannot attach files in this forum
You cannot download files in this forum



Back to Main page