I have only been able to cope with it with a watchdog to detect that the board has hung, and reset it.

The radio, when trying to set the pwr_en input pin high by applying 3.3V to it, it seems to result in a short circuit.

blick.  and how weird, because that pin is indeed a 3.3v digital input.  Maybe if you wave a dead chicken over it, and say a prayer, it will come back?  Occasionally incense helps, also.

Then maybe that's why mine won't speak back to me?  Now I must break out the oscope (and figure out a way to hook to my crazy modded pin header).  (now I wish I had a logic analyzer!)  (maybe this will finally make me use that bus pirate I got ages ago)

Unrelated, but I got a 'product obsolete' notice on this eval board (296-30564-ND), with no replacement suggestion.  Not the module itself mind you but the board.  Don't know what that means or if it is news you can use....

I think I just fried mine  Seems pwr_en is ground and it's supposed to be an input...

your radio or host board?  I've flicked pwr_en high and low just fine, so maybe double check the wiring, maybe it's OK!

OMG I am not sure if I have seen a more poorly documented device.  Does TI actually make this, or resell it?

Sounds like you guys with the TI eval boards are moving ahead with the 'stock' code to make it do something interesting.  I'm going to continue to plow through the hard and stony soil of non-docs in hopes of finding some rich volcanic earth beneath.  Or maybe only bedrock....

Hi Jamo; your handler looks sensible to my eyes, though I haven't run the code.

The DataReceived is meant to be fired when there is data available in the internal buffers, that you can retrieve with Read().  You need to retrieve all that is available, because you will not get another event fired until a new received byte comes in (i.e., merely having some unread data will not stimulate the event).

This seems to be how you interpreted it yourself, so maybe look for some bugs in managing your write index into your application buffer, or maybe in how you are pulling lines and and doing the bookkeeping of that pointer.

That being said, I do want to mention that I (and others) have had problems with DataReceived ceasing to function inexplicably after some time.  I seems to be somehow related to how much other stuff you've got going on in your app.  (some folks have it happen as soon as they do ethernet in another thread, and for me it just seems to be the number of threads while running several serial ports).  So heads-up on looking out for that.

Lastly, someone else had a serial port question, and coincidentally they were using a GPS, and also coincidentally I wrote some code that does the serial stuff of reading and emitting the NMEA lines.  Maybe that sample will be useful in some way:

http://forums.netdui...roblem/?p=47392

(don't worry, there is still be plenty of coding to do; that sample does not interpret the NMEA, it just assembles the lines from the incoming data and emits them for something else to handle).

my main current project (which is paid work) deploys at 99430, and the runtime free memory can be as low as about 50k (depends on what features are running), and uses 7 threads.  A major part of the deployed code comes from referenced assemblies; in particular I'm using the regex assembly and its a big one.  Also Ive found that if your ram gets down to about 20k free, the system can become unstable.

well I soldered on some pin headers ('custom made' since they are on an unusual 2mm pitch).  we'll see if I can get something to go over the spi; maybe there's a 'version' command or something similar....

.. Also, I think arrays will end up in RAM anyway and that someone (was it you?) recently investigated the latter and came to that very conclusion....

'twas indeed, alas.  I haven't tried it for ints, though, but I'm skeptical that they will avoid ram; only strings it seems  But your table is quite small, so no biggie!

sine and cosine are related by a phase shift, so you don't need a separate array (much like your 4-quadrant optimization)

Hmm, doesn't 'byte' only hold 0-255 (or is it -128 to 127?), but never +/- 255?  Oh never mind you get an extra bit of precision since you're in the first quadrant, which is always positive (and you get the negative values in your [] method).

I wonder if private static byte[] _sin; could be just be a constant array (i.e. not need initialization in the constructor, and stored in ROM).  Then again, I've found that netmf only seems to be clever like that (storing in ROM) for strings, but admittedly I haven't tried an array of integers...  If it's not, then perhaps on the upside you can claim that 'sine table' has a double meaning....

Looks like someones gonna be doing some Fourier transforms?

to wit, the processor's usarts support 8 and 9 bit modes only; maybe if you had parity, you could emulate it with an 8 bit mode, but you have no parity, so I think probably not; or maybe you can make it look like an extra stop bi.?  Interfacing to an ancient device?

let us know how it goes; I could have had 2.5 for the price of 1 relative to the behemoth TI board I got!  Maybe I should get a couple myself....

EDIT:  my eval board arrived, so maybe 3-4 days from now I can carve out some time to at least solder on some pin headers and try out the SPI a little.

EDIT2:  well, the existing holes for headers are not on .1" pitch for common snappable headers; blick.  well, I suppose I can jury-rig something, I only need 8 points, I think...

OK, well it will probably a a couple weeks before I can fiddle with it.  Too bad centerblack doesn't have spares of his breakout board, I'd rather than than the gauche TI dev board, but I did order one.  Digikey thanks you, at least; haha.

you're not doomed, you can make it work, though it will have to be on COM1 since for some reason they didn't bring out D2/D3, and as you observed only the one D0-7 header (and so don't have a complete COM3).

First, I have not used this shield.  But, I have used the underlying BT module, the HC-05, and with it connected to the netduino.  So it is doable.

NB datasheet:

ftp://imall.iteadstudio.com/IM120417010_BT_Shield_v2.2/DS_BluetoothHC05.pdf

p2 indicates:  "Default Baud rate: 38400, Data bits:8, Stop bit:1,Parity:No parity"

your code shows 9600.

However the various ITead docs are inconsistent, so take them with appropriate salt.  For example one says the PIN code is 0000, and another says it is 1234.  They also state that Vih is 4.5v, which you will not get out of a 3.3v board, but I suspect that rating is actual Vimax instead of Vih.

You netduino code at first glance looks like an OK 'loopback' test.  But I havent' run it so thats just a desk check.  I can say that I have had problems with SerialDataReceivedEventHandler, but those are sporadic, so let's not worry about that now.

You are wise to do a loopback test as a sanity check.  If you like, you can loopback even closer by connecting the TX to the RX of the radio, bypassing the netduino.  You can do that either by removing all the jumpers, and connecting the TX to the RX with a jumper wire; or by temporarily removing all your code in main (thereby leaving the netduino pins in high-impedance) and jumpering at the header.  You should be able to connect to the radio as you have been, and see data sent comes right back.  This will verfify from the radio to your windows phone code, and take com configuration out of the equation.

Next I suspect you just have to configure your jumpers correctly.  I love the ascii art but I confess I got confused by the [] and the colors, so let me just say that the way it is shown in your datasheet's 'figure 3', is probably the way you want.  I.e. the TX of the board to D0 (rx of netduino) and the RX of the board to D1 (tx of netduino).  Depending on their sense of RX and TX you might reverse that, but I think that is it.

Keep at it, it will (probably!) work.

...
http://www.lsr.com/d...ts/330-0086.pdf

What do you need to know?...

hmm, could be usable for development at least.  won't win any 'sexy dev board of the month' contests, but hey its a dev board.

I was needing software info, but I found these two that should give me enough reading for today:

http://processors.wi...Interface_(SPI)
http://processors.wi...ogramming_Guide
 

at the outset it might be too much for a managed 'driver'.  well maybe.  maybe not!  I say this only because its' interrupt driven and I was concerned about latency, but then if it's handling the network stack, then it is also handling acks and retries so the host may be able to be more leisurely about servicing requests.

...Too bad there's no F4 in 48 pin package....

well the current mini uses a 64-pin package does it not?  anyway I know the various ghi boards in dip form factors do, so it should be doable from a layout perspective.

OK well hmm I may have to carve out some time this summer.  I am currently distracted trying to port an RTOS to the NP2, and ultimately port netmf on top of the RTOS, but that could take a while (if it even works out), and I may need a distraction from my distraction.  Plus, this wifi capability is germane to some paid work I'm doing, so maybe I can fold it in that way....

Thanks for the links!

-dave

ps hanzibal, I have been meaning to do your oscilloscope art, but I haven't been able to get to it yet, haha

ps baxter, I have always been envious of your avatar -- it reminds me of Lord Melchett from Blackadder, and consequently when I read your posts it is always in that character's voice, haha

well, if the goal is 'use the spark core' then you probably are out-of-luck for netmf directly, as you point out.  but if the goal is 'make a new hardware', then it should be easier, because you can put in a better processor.  the package of the 415 is 64 pin, and spark core's is 48, so you might have some placement challenges, but I think the mini is already using a 64 pin device, so it should be doable.

if you talk to it through a uart, that kinda loses the benefit of spi, right?  I haven't looked at the datasheet, but now I'm curious about the difficulty you mention.  From the outside, it looked like it presented a high-level interface to networking; i.e. it has its own tcp/ip stack, and works similar to how many of the shields work.  In a way this might make integraiton easier.  Well let me rephrase that; it would make integration easier except for the fact that lwip/enc38j60 is already integrated, and what can be easier that work already done?  So it requires positive, non-zero, effort, but probably would reduce the code footprint a bunch.

Hmm.  now I'm curious.  I wonder if someone has a cc3000 on a breakout board....  I don't know how digikey is selling them for 12.50 when others (e.g. mouser) are selling them for about double that.  Maybe they have a special deal with ti...

hmm.  are you sure that will work on netmf?  you are right about the syntax itself for VB.  but making a netmf vb quicky just now:

Module Module1    Sub Main()	    REM write your code here	    REM this will not compile:	    Dim aColors As Boolean(,) = New Boolean(,) {		    {False, True, True},		    {True, False, True},		    {True, True, False},		    {False, False, True},		    {False, True, False},		    {True, False, False}	    }	    REM but this will:	    Dim aColors()() As Boolean = {		    New Boolean() {False, True, True},		    New Boolean() {True, False, True},		    New Boolean() {True, True, False},		    New Boolean() {False, False, True},		    New Boolean() {False, True, False},		    New Boolean() {True, False, False}	    }    End SubEnd Module

with the first part in, it fails, but with the second it's ok.  

I don't consider myself a VB programmer, but the multidimensional array limitation is a fundamental one to the netmf CLR, I believe, so it shouldn't have to do with language differences.

that stm32 has 128k flash, and 20k ram, and apparently netmf needs 256/64 min:

http://en.wikipedia....Micro_Framework

pity that they couldn't have splurged another $3 for an F415 (well the package is bigger, but for a dev board why not have more power?)

Have to look at that wifi module though, a good bit cheaper than the roving networks ones...

yes.  you have a lot of options, and as always with security, you can make something that looks like it works (e.g. stuff is encrypted, and your commands execute) but is alas, ultimately, is insecure.  Here is a paraphrased version of my work on a recent project regarding similar concerns:

all things considered, I would prefer to do it this way:

*  public key in your netduino app

*  private key on your systems that generate the command that needs to be authenticated

*  your command-issuing system signs the command, ideally with a nonce or sequence number to prevent replay attacks

this should be secure so long as your command-issuing systems protect their private key correctly (and so long as their aren't bugs in your impl to exploit!), and disregarding DOS attacks (which are a separate class of threat anyway).  end of story.

fly in that ointment is that netduino doesn't have any crypto in the firmware, so you have to add crypto in managed code.  OK, not the end of the world, and I personally recommend the BouncyCastle crypto lib -- it's reputable, the license is good, and you can pluck out the modules you want with a few hours effort.

fly in that ointment is that the netmf will go TU on large constant data arrays (like s-boxes for symmetric algos), and it's just too much stuff for all the bignum calcs that you need for the asymmetric crypto.  this last part is a pretty big deal because it means you are going to have to use symmetric encryption methods, and that means key management -- yuck.

so, what I did was use a HMAC-SHA1 with a random per-device shared-secret key that I put on SD.  This functions as a signature algorithm, but using symmetric methods.  I stock pregenerated SD cards containing profiles, and just get the rest of the hardware as-needed.  When deploying, the key is loaded into my (trusted) backend systems that generate the commands, and the SD is stuck into the unit.  I have online and offline systems; the online systems use timestamps to avoid replay attacks (they are constantly synchronized with the backend), and the offline systems use a sequence number scheme to do similar.  Using the SD card isn't that big of a deal for me since I have plenty of other non-secure config and log storage needs anyway.

I really do not like this arrangement at all, but that's as good as it gets without assymmetric crypto.  Also, don't be tempted to use any onboard device info for your shared secret key (like mac, or even chip serial number).  The key must be random (or at least not not derivable solely from device data.  an acid test is:  if the netduino can generate the secret key without some additional data somehow injected onto it, then so can anyone else, and you are insecure).

Also, because the shared secret is on the SD, which is removable, this is a significant weakness.  But my units are in a locked enclosure, and I mostly mitigate that with some revocation capability and logging to detect fraud.  But that stuff all depends on the design of the rest of the system, and you may or may not have those luxuries.  But as they say, there is no security without physical security.  If someone can diddle with the wires going to your unit then all the crypto in the world doesn't matter.

But to truly be good, you really need assymmetric crypto.  Then almost all of this goes away, and you are just left with securing trust.  But we don't have it right now, alas...

-dave

p.s. and of course security is a continuum.  if you just want to exclude silliness, but not a motivated adversary, then even non-secure things help.  For instance, I got tired of dictionary attacks on my servers.  Just moving my SSH port off the default took the attack level to narily zero.  Secure approach?  Not at all. Quieted attack rate?  Oh, youbetcha.  So a valuable action nonetheless....

Of curiosity, a "jagged" array would be one like this in C# right?

bool[][] bColors = new bool[]{ new bool[]{ false, true, true}, new bool[]{ true, false, true}};

almost; rhs needs the [][]:

bool[][] bColors = new [color=#ff0000;]bool[][][/color]{ new bool[]{ false, true, true}, new bool[]{ true, false, true}};

but you get it.  actually I have to look up the syntax every time I do it.

Now since I had to reach for my dev studio, I went ahead and did try the multidimensional equivalent (in C#):

bool[,] bColors = new bool[,] { { false, true, true }, { true, false, true } };

and I do get a metatdataprocessor error

error MMP0000

so it will be interesting to hear from the OP if this helps in his case with the VB.

and again, that particular error seems to be generic -- I get it all the time from a variety of things.

you idea is very cool.  bluetooth might be better:

*  only a very few phones have nfc

*  last I messed with android NFC, I found the api pretty tedious

*  there are readily available bluetooth doodads you can plug into one of your netduino serial ports for about $10 in unit quantities on ebay from china.

on the other hand, I have not done bluetooth serial on the android, so who knows maybe thats even worse.  on iphone is a pita because (last I looked at least), you cant programattically engage the BT (but maybe in your datacollection app, that's not a biggie).

Lastly, I don't know if the pairing issue with bluetooth will be a nightmare.  Maybe not, but something to think about.

I'm assuming that is a compile-time (not runtime) error?

When I get those at compile-time it is because the build step with the 'meta data processor' goes awry, and that can happen for many reasons -- for me usually too many static initializers, but other things cause it as well.

OK, so I'm not hip to VB.net, but in C# on .NetMF we cannot have multi-dimensional arrays.  We can have 'jagged' arrays.  The language supports multidimensional arrays, of course, but the runtime does not.  As a quicky, see if you can convert your array to a 'jagged' array, and if that makes things all better.

or maybe setting the boards date time from a sever accessed through the ethernet?  like NTP?

If so, here's at least one impl I came across:

http://www.jaypm.com...-automatically/

I'm pretty sure you can not set the thread name; that it's either not available in netmf, or at best would mean changing a build option of the firmware if it is capable.

In my case, I get around it by having my worker threads emit a log message identifying themselves by id.  Then at least I can correlate it in my logs.  E.g.

Debug.Print("XXX starting on thread: " + Thread.CurrentThread.ManagedThreadId);

woohoo! Asteroids and BattleZone, here we come!

... If you're using the new WinUSB drivers with the gen1 boards (i.e. the latest 4.2 firmware), you do need to go into TinyBooter mode to save or flash firmware--or to change network settings....

'gen 1'?  I assume not, since I am using NP2, and I am assuming gen1/2 approximately means Atmel/STM

'WinUSB'?  unknown; but probably I guess, since I am using what is installed with 4.2x SDK?

But how /does/ one go into TinyBooter mode?  Explicitly.  I can only get there if my TinyCLR is damaged (accidentally or deliberately).

I've not had luck either; some discussion here:

http://forums.netdui...oading-my-code/

I have, however, been able to make a DFU from the hex file and update the application that way.