Wonky Uart
#1
Posted 02 March 2012 - 09:07 AM
#2
Posted 02 March 2012 - 03:49 PM
#3
Posted 03 March 2012 - 08:57 AM
#4
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
Posted 03 March 2012 - 10:33 AM
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?
#6
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
Posted 05 March 2012 - 10:19 AM
#8
Posted 05 March 2012 - 11:10 AM
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.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...
#9
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
Posted 11 March 2012 - 10:14 AM
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
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
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
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.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users