Netduino home hardware projects downloads community

Jump to content


Photo

Wonky Uart


  • Please log in to reply
12 replies to this topic

#1 DrJaymz

DrJaymz

    Advanced Member

  • Members
  • PipPipPip
  • 42 posts

Posted 02 March 2012 - 09:07 AM

I am having issues talking to a 4DLabs SGC display using the picaso serial interface. This is the issue. You talk to it at 9600 and then tell it you want 256k baud. It then changes and now you get 256k. The problem is that to change the baudrate on the netduino you need to close the port set the new rate and open it again. This causes a level change and results in the picaso interpreting that as a start bit and completely messing the whole thing up. I can prove that you need to close the port because the driver has a check for m_portopen and throws invalid operation if the port is open. Why is this the case, you can change the baudrate on just about anything else without having to do this? Surely its a case of updating the baudrate generator register and it should work - though I don't think that is possible from managed land. So, when the port is open the idle state is 1, when its closed is it 0 or floating? If it is floating then I can bodge it with a weak pull-up? Or perhaps anyone can tell me if they have closed and opened the port and it does in fact function at all after being closed? Its driving me up the wall because these are my last ideas, after which its probably game over for this project. That and the fact that I am really getting sick and tired of deployment failing after 4 or so deployments and then blue screening windows - make me wish I hadn't started with the netduino. Nobody seems to be able to fix it. If I find a solution to the 4dLabs I will remember to post it here as most people don't bother to update a forum when they fix something!

#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 6871 posts
  • LocationNew York, NY

Posted 02 March 2012 - 03:49 PM

Hi DrJaymz, Have you tried the .NET MF 4.2 beta drivers yet? On the serial port... That's an interesting scenario. I'd try using an external pull-up. If that doesn't work, let us know...and we can take a look inside the uninit/init code for the AT91SAM7X UART code and make recommendations. Chris

#3 DrJaymz

DrJaymz

    Advanced Member

  • Members
  • PipPipPip
  • 42 posts

Posted 03 March 2012 - 08:57 AM

Update - I have tried closing and opening the port at 9600 and I do not loose the connection with the display. So thats all fine and no pull ups are needed. I found port.close followed by dispose, then new port at 9600 worked, where close then new baudrate and then open didn't seem to. But it has come to my attention that the SGC slave controller has an implementation of baudrate that has rounding errors in it probably as a result of how they have implemented it. Which sounds a bit like they are bit banging. Here is my discussion with 4D http://4d.websitetoo...post?id=5734058 I have tried incrementing the baudrate in a for-next loop to find the actual rate it is talking at but I cannot get communication above 9600 with the display. At this stage in my investigation, when I open the serial port I supply an integer for the baudrate - but how does the baudrate generator work on the netduino? I would imagine it is not infinitely variable, and that there is a list of available rates somewhere that fit the internal generator scalers. My next thing is to get a scope trace from the display when it thinks its at say 115200 measure the bit period and try to find a compatible rate on the netduino. I am sure that a few other people would find this work useful once we find the magic rates! For 256kbd the actual rate is 282353bd but if I set that with the netduino it doesn't work. Without a scope I can't do anything other than trial and error - but I will have a DSO Quad next week to investigate it further.

#4 DrJaymz

DrJaymz

    Advanced Member

  • Members
  • PipPipPip
  • 42 posts

Posted 03 March 2012 - 09:03 AM

Have you tried the .NET MF 4.2 beta drivers yet?


Tried RC3 and it was hopeless, I may try RC4 later on - is there any change with the deployment? It is really tiresome when you are trying to debug something and then deploy fails after 4 or so goes. I have found the only way to avoid blue screen is to end-task on visual studio and then remove and replug the netduino then restart Visual studio.

I know its the netduino that is the problem because if it has its own 12V supply, replugging the USB doesn't help i.e. it has not been reset by power cycling.

#5 Magpie

Magpie

    Advanced Member

  • Members
  • PipPipPip
  • 279 posts
  • LocationAustralia (south island)

Posted 03 March 2012 - 10:33 AM

Hi
As far as the BSODs go, the only time I ever get them is if I reset the Netduino while Visual Studio is doing the deployment.
For me it is a golden rule, cancel a deployment via visual studio before cycling power to the netduino.

To be pedantic it is not the Netduino hardware itself causing any BSOD but it is the USB driver.

There is another thread where we discussed failed deployments that may help. Stuck Deployments

You are right about the 12v supply, I think the power cycle is critical sometimes.

I have tried quite a few embedded technologies and they are all full of compromise, the Netduinos compromises in particular are a little different than most.
but so are its advantages,

As far as your serial port problem goes, have you considered a hardware solution. Such as using a logic gate to hold the line how you want it.

eg.

Using a 2 input gate: one input is the Tx line; one input is an IO pin, that we could call enable; one output goes to the LCD.

Would that work?
STEFF Shield High Powered Led Driver shield.

#6 DrJaymz

DrJaymz

    Advanced Member

  • Members
  • PipPipPip
  • 42 posts

Posted 04 March 2012 - 10:10 AM

Hi
As far as the BSODs go, the only time I ever get them is if I reset the Netduino while Visual Studio is doing the deployment.
For me it is a golden rule, cancel a deployment via visual studio before cycling power to the netduino.

To be pedantic it is not the Netduino hardware itself causing any BSOD but it is the USB driver.

There is another thread where we discussed failed deployments that may help. Stuck Deployments

You are right about the 12v supply, I think the power cycle is critical sometimes.

I have tried quite a few embedded technologies and they are all full of compromise, the Netduinos compromises in particular are a little different than most.
but so are its advantages,

As far as your serial port problem goes, have you considered a hardware solution. Such as using a logic gate to hold the line how you want it.

eg.

Using a 2 input gate: one input is the Tx line; one input is an IO pin, that we could call enable; one output goes to the LCD.

Would that work?


I cannot cancel deployment withing visual studio it hangs. No matter how long you wait. The other failure mode is where it says deploy failed in the status bar and then visual studio won't respond to the mouse anymore. In this case you can only end task it. If you pull the usb you will get a BSOD, thus the only thing you can do is end task. Once in this state, if you keep the board powered and remove the usb connection, and plug it back in, the device isn't recognized, thus I have just proved that whatever is going on in the atmel, it is not in the correct state. At this point the driver has been reloaded - thus its not the driver per-se, though the driver could be responsible for putting it in this not allowed state.

I am all to familiar with compromises in the world of development, I still remember the various bodges for 8051's. I have BSOD my machine before when writing USB Hid devices in assembler - but I don't really expect it in this case. I have considered using a VM for this work but the whole point of the netduino was to enable me to be lazy.

The gate idea, did cross my mind or simply a pass transistor, but I think I proved that the transition wasn't the problem by demonstrating that it doesn't occur when closing and opening again at the same speed and the communication remains unaffected.

#7 DrJaymz

DrJaymz

    Advanced Member

  • Members
  • PipPipPip
  • 42 posts

Posted 05 March 2012 - 10:19 AM

Does anyone know what baudrates are available with the netduino and what their bitrate errors are? Despite the .netMF functions for creating serial ports, the rates are not infinitely variable. I am trying to talk to a device that should be 256kbaud and its actually 282,393 and I wanted to know how close I could get to that rate. Failing that I should be able to find some happy medium somewhere above 128k. I have had a look at the Atmel datasheep and its not that useful without knowing exactly how it was implemented on for .net. For example, you can specify exactly how the input is sampled, in my case a single sample would probably work where multi-sampling probably wouldn't. Thanks if anyone knows.

#8 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1471 posts
  • LocationCzech Republic

Posted 05 March 2012 - 11:10 AM

I have had a look at the Atmel datasheep and its not that useful without knowing exactly how it was implemented on for .net. For example, you can specify exactly how the input is sampled...

You'd probably need to check the current implementation in the source code, namely AT91_UART.cpp. Unfortunately, oversampling configuration is not supported in the managed wrappers (SerialPort class). Please note COM1 is in fact Debug Unit, which has limited features (compared to 'full' USART module), as described in the datasheet section 26.4 DBGU UART Operations.

#9 DrJaymz

DrJaymz

    Advanced Member

  • Members
  • PipPipPip
  • 42 posts

Posted 05 March 2012 - 08:02 PM

You'd probably need to check the current implementation in the source code, namely AT91_UART.cpp. Unfortunately, oversampling configuration is not supported in the managed wrappers (SerialPort class). Please note COM1 is in fact Debug Unit, which has limited features (compared to 'full' USART module), as described in the datasheet section 26.4 DBGU UART Operations.


Ok, depending on if you can divide it 10 and the remainder is more than 5 it divides by 10 and adds 1. But it does look like it more or less just passes an int in for the baudrate in hz. I did look at the datasheet for this, but doesn't really help.

At the bottom, there are two functions, BaudrateBoundary and IsBaudrateSupported.

I will try to get something on the scope and we can see whats actually going on then.

#10 DrJaymz

DrJaymz

    Advanced Member

  • Members
  • PipPipPip
  • 42 posts

Posted 11 March 2012 - 10:14 AM

OK - here is the answers - hopefully its of use to someone.

When using the Netduino with the Picaso SGC neither of them operate at the correct baudrate - so I wrote a program that used trial and error to work out what the settings should be.

For 115200 bps (0x0D) the netduino serial ports peed should be set to 113250.
For 256kbps the netduino serial port speed should be set to 260900.

Then it all works dandy. So even if the Picaso was operating it the correct published speed it is unlikely that it would have worked anyway.

also change it like this:

                SetBaud(0x0F); //256K
                ChangePortSpeed(260900 , portName);
                Thread.Sleep(500);
                port.DiscardInBuffer();
                port.DiscardOutBuffer();


where: 


        private bool ChangePortSpeed(int baudrate, string portName)
        {

            Debug.Print("New Port Speed " + baudrate.ToString());
            if (port != null)
            {
                port.Close();
                port.Dispose();
            }

            port = new SerialPort(portName, baudrate, Parity.None, 8, StopBits.One);
            port.Open();

            return true;
        }


/// <summary>
        /// tells the display to go to new baud rate
        /// </summary>
        /// <param name="Baud">parameter for baudrate see data sheet</param>
        public void SetBaud(byte Baud)
        {
            var bytes = new byte[]
                            {
                                0x51, // cmd = B
                                Baud
                            };
            Write(bytes);
        }


Basically you will have to forget the response byte on baud change, but the next command is fine - I have set up a read response with a timeout so if it is not ok then I will know. There isn't a NOOP or equivalent.

Can we set this thread to -SOLVED and include details of the 4DSystems SGC so that others can find it?

#11 Coskun

Coskun

    New Member

  • Members
  • Pip
  • 8 posts

Posted 28 March 2012 - 06:46 PM

OK - here is the answers - hopefully its of use to someone.

When using the Netduino with the Picaso SGC neither of them operate at the correct baudrate - so I wrote a program that used trial and error to work out what the settings should be.

For 115200 bps (0x0D) the netduino serial ports peed should be set to 113250.
For 256kbps the netduino serial port speed should be set to 260900.

Then it all works dandy. So even if the Picaso was operating it the correct published speed it is unlikely that it would have worked anyway.

also change it like this:

                SetBaud(0x0F); //256K
                ChangePortSpeed(260900 , portName);
                Thread.Sleep(500);
                port.DiscardInBuffer();
                port.DiscardOutBuffer();


where: 


        private bool ChangePortSpeed(int baudrate, string portName)
        {

            Debug.Print("New Port Speed " + baudrate.ToString());
            if (port != null)
            {
                port.Close();
                port.Dispose();
            }

            port = new SerialPort(portName, baudrate, Parity.None, 8, StopBits.One);
            port.Open();

            return true;
        }


/// <summary>
        /// tells the display to go to new baud rate
        /// </summary>
        /// <param name="Baud">parameter for baudrate see data sheet</param>
        public void SetBaud(byte Baud)
        {
            var bytes = new byte[]
                            {
                                0x51, // cmd = B
                                Baud
                            };
            Write(bytes);
        }


Basically you will have to forget the response byte on baud change, but the next command is fine - I have set up a read response with a timeout so if it is not ok then I will know. There isn't a NOOP or equivalent.

Can we set this thread to -SOLVED and include details of the 4DSystems SGC so that others can find it?


Hey there,

Do you think you can find a similar working Baud rates, etc for the same chip but with GFX?

I cannot make it work for some reason, don't know why.

#12 DrJaymz

DrJaymz

    Advanced Member

  • Members
  • PipPipPip
  • 42 posts

Posted 28 March 2012 - 07:14 PM

Hey there,

Do you think you can find a similar working Baud rates, etc for the same chip but with GFX?

I cannot make it work for some reason, don't know why.


I don't know anything about the GFX implementation, but I do know that its sensitivity is down to the limitation of the chip they are using.

The way I set the new baudrate seems to do the trick and it doesn't seem too sensitive to the actual baudrate.

#13 Coskun

Coskun

    New Member

  • Members
  • Pip
  • 8 posts

Posted 29 March 2012 - 06:36 AM

I don't know anything about the GFX implementation, but I do know that its sensitivity is down to the limitation of the chip they are using.

The way I set the new baudrate seems to do the trick and it doesn't seem too sensitive to the actual baudrate.


I actually found the answer later on and wanted to come back and edit my post but it turned out that my first post had to be approved by the moderators so I could not find it. Sorry for that.

The thing is that, if the chip is loaded with GFX features, it becomes a standalone running chip and accepts serial connections only for "4DGL programming" purposes. I guess they wanted to let the customers get the full performance by removing unnecessary features if the customer chooses to use the chip as either GFX or SGC.

If it is loaded with SGC, then it becomes a slave device and the N+ can start connecting to it - that is what they say on their website. I could not try because I still don't have an SGC because I don't have a converter or USB cable for it.

Good news is that both devices are identical with their hardwares and the end user (being me in this case) can use their firmware loader for changing the type of the chip.

Thank you.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2010-2014 Secret Labs LLC  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.