9 replies to this topic

[Howie Goodell]

I am trying to use a Netduino Plus board to replace the legacy controller for an industrial machine that uses a 9-bit serial protocol (the remote process controllers only read bytes with the 9th bit set until they see a packet addressed to them). Life is good if I specify 8 data bits, but if I set 9 it throws an unhandled System.ArgumentException at Microsoft.SPOT.Hardware.SerialPort.dll!System.IO.Port.InternalOpen() (call made at Line 156 of the 4.1 source file SerialPort.cs) Here's my code: mSerial = new SerialPort(SerialPorts.COM1, 375000, Parity.Even, 9); mSerial.DataReceived += new SerialDataReceivedEventHandler(mSerial_DataReceived); mSerial.Open(); I assume the DLL is complaining about a parameter it can't fully handle (9th bit needs a special register bit write; obviously not included in the data byte). Not sure if this is a SecretLabs or MS issue. Would changing to 4.2 firmware fix it? (I tried, but I gave up fighting the driver incompatibility of the Atmel tiny booter.) How do I fix this myself? First time trying managed code for low-level; reminds me of the old days when Windows worked great at the GUI high level before a low-level crash ;-) Howie Goodell

[Chris Walker]

Hi Howie, COM1 is a special "debug UART" which can only handle 8 data bits if I remember correctly. Can you try COM2? Looking at the data sheet, it can handle 9 data bits. Welcome to the Netduino community, Chris

[Howie Goodell]

Hi Howie,

COM1 is a special "debug UART" which can only handle 8 data bits if I remember correctly.

Can you try COM2? Looking at the data sheet, it can handle 9 data bits.

Welcome to the Netduino community,

Chris

[Howie Goodell]

Hi Chris, Thanks for the good suggestion, and also for the friendly welcome -- I'm looking forward to doing some good work with this cool platform. Unfortunately however, it seems that it throws exactly the same exception at exactly the same point for COM2 as for COM1. I attach an image of the debug window in case it gives clues. Probably the driver doesn't support this feature of the AT91SAM7X USARTs. I assume the next step is writing my own unmanaged code to interact with this? Since I'm new to this environment, any tips for this (or any other approach) would be most welcome. Thanks again! Howie

Attached Files

•  InternalOpenException.png   205.82KB   12 downloads

[Chris Walker]

Hmm, it could also be the requested baud rate...or the combination of even parity with 9 data bits. The USART code for Netduino Plus is in: C:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\AT91\DeviceCode\AT91_USART If it's a setting that the microcontroller can support and we don't support it yet, that's something we can also address in an update. [Or if you make the change, please consider contributing it--and everyone can have the update.] Chris

[Howie Goodell]

Hmm, it could also be the requested baud rate...or the combination of even parity with 9 data bits.

The USART code for Netduino Plus is in:
C:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\AT91\DeviceCode\AT91_USART

If it's a setting that the microcontroller can support and we don't support it yet, that's something we can also address in an update. [Or if you make the change, please consider contributing it--and everyone can have the update.]

Chris

Hi Chris,

Here's where the exception comes from in the 4.1 code (that matches the firmware I still have on the board):

C:\MicroFrameworkPK_v4_1\DeviceCode\Targets\Native\AT91\DeviceCode\AT91_USART\ATI91_USART.cpp
in the function AT91_USART_Driver::Initialize (the version finally called by the code in the folder you mentioned in the case of the Netduino Plus's AT91 processor):

Lines 98-115:
switch(DataBits)
{
case 5:
USMR |= AT91_USART::US_CHRL_5_BITS;
break;
case 6:
USMR |= AT91_USART::US_CHRL_6_BITS;
break;
case 7:
USMR |= AT91_USART::US_CHRL_7_BITS;
break;
default: // not supported
fRet = FALSE;
//fall through for default
case 8:
USMR |= AT91_USART::US_CHRL_8_BITS;
break;
}

9 data bits will hit the default: case and return false, generating the exception I saw.

I will test a modified Initialize and also add functions to set the 9th bit for certain characters, etc., and contribute them back for anybody else who has similar requirements.

BTW, have you created a solution for loading unmanaged code at runtime as you suggested in this 2010-2011-2012 thread? http://forums.netdui...28-native-code/

Thanks much!
Howie

[caEstrada]

A chance to play with UART registers and take advantage of signals for RS-485

[Howie Goodell]

...

I will test a modified Initialize and also add functions to set the 9th bit for certain characters, etc., and contribute them back for anybody else who has similar requirements.

BTW, have you created a solution for loading unmanaged code at runtime as you suggested in this 2010-2011-2012 thread? http://forums.netdui...28-native-code/

Thanks much!
Howie

Hello again,

I'm trying to add just a half-dozen functions to do specific things with serial and other hardware; think I can get adequate speed just using C# for the overall framework. Chris, the Adeneo interop post you linked to last year seems to get me tantalizingly close:
http://adeneo-embedd...-framework.html
However, I'm still stuck in a few places.

1. Question: he suggested creating the Visual Studio project in
"PortingKit\Solutions\[Your Solution]\ManagedCode\",
-- so I just created that directory: in my case C:\MicroFrameworkPK_v4_1\Solutions\Serial9\
However, as I worked through his procedure, I found I needed to manually copy over various top-level files like dotnetmf.proj and folders like TinyCLR from another solution. I assumed the Template solution was correct, but he didn't say where they should come from. Do you think he assumes we initially created the solution with the MS SolutionManager he called "flimsy"??

2. A detail about his procedure: he says to edit the .featureproj file to point to the .pe (Portable Executable) file from the Library project -- but in VS2010 at least, there are TWO versions of .pe and other binary files, in two directories named:
bin/Debug/le and
bin/Debug/be .
Googling wasn't too helpful -- I mostly found "le" on French pages ;-) It turns out the choice matters: be is Big-Endian and le is Little-Endian. The ARM defaults to Little-Endian, (though initialization could change it, I'm sure yours doesn't). If you are using a Big-Endian processor, you also need to use Template_be as your model instead of Template, apparently.

3. A request for Chris: would it be possible to post a link to the 4.1 firmware sources again? I only see 4.2 on your Downloads page. Because I had trouble with the USB drivers for the boot re-flash that 4.2 firmware requires, I'd rather not mess with all that just to make these small changes. However, I can't create an image for 4.1 without them, unless perhaps I link to the downloaded object as someone suggested -- but I'd rather have all source.

4. Finally, just to clarify: although MFDeploy says it can do incremental downloads, I haven't found any procedure for that. I'd love to just deploy my small changes linked against the existing image, with or without GUI niceties. However, at this point I plan to link and compile the whole thing; then re-flash following this procedure in the wiki:
http://wiki.netduino...ep-by-step.ashx
If there is an incremental deployment procedure, I'll gladly add a wiki page explaining it, once someone explains it to me ;-)

Cheers!
Howie

[Howie Goodell]

Hi --

Just a minor point: trying to compile 4.1 firmware using the ARM RVDS compiler -- by coincidence that's also version 4.1. Unfortunately, the set_context scripts only support RVDS4.0. Here's an attempt to add an RVDS4.1 target, but I'm not sure it's correct. The compile is still giving errors that could relate to incorrect variables OR to the fact I let ARM install to Program Files -- the quotes may be what's screwing up the batch files. Chris, any suggestions? As I promised about the serial, I'll add a wiki page explaining this -- once it's working for me.

Notes about setconf_base.cmd:

• Comparing labels :SET_RVDS_V40_VARS and my new :SET_RVDS_V41_VARS, notice my environment has ARMCC41BIN/INC/LIB set, where the 4.0 version sets RVCT40/BIN/INC/LIB -- I assume that's a change between those ARM compiler versions.
• There is no PK directory tools\ads_v4_1 in the PK directories to match the RVDS_EXT set here -- however, there's also no tools\ads_v4_0 (just tools\ads_v3_1); so I assume it's not needed?
• Note I created a setenv_RVDS4.0.cmd also, but that's trivial (and you can only add one file per post).

Howie

Attached Files

•  setenv_base.cmd.txt   9.98KB   5 downloads

[Chris Walker]

Hi Howie,

Use the setenv_rvds4.1.cmd file with the latest rvds 4.1 and you should be good to go:

c:\microframeworkpk_v4_1>setenv_rvds4.1.cmd "c:\program files\arm"

Chris