Chris is the 4.2.2.2 firmware source posted?  I think what is on the download page is for 4.2.2.1.

I likes to keep up-to-date....

oh cool, so you have a working system to compare against; that will be a helpful sanity check when diagnosing problems.

 

BTW, If you happen to see in your spi'ing, a case where an asynchronous event is reported before a command's return packet, let me know.  the doc is not clear about whether that can or cannot happen.

WOW.  I have a long weekend coming up and I know what I will be doing now!  ...

 

Haha, have phun hacking!

 

...

I completely agree with the managed approach.  It reminds me of the enc28j60 driver that Hanzibal ported from C.  When I saw the raw packets coming in, my eyes lit up and I knew it was doable to do everything managed.  And the debugging was much easier because of it.  Once we have the communication and the ..

 

I'm very impressed you and hanzibal got a tcp stack and ethernet device driver working in managed on netmf.  Thats a lot of work.

 

...

command message objects, we should be able to take it all the way.  One thing that could accelerate things greatly would be if I can get just get raw packets to work, I can bolt on mIP and immediately have a usable solution.  To me the next step would be to leverage the cc3000 TCP stack to offload the work to improve ...

My only concern with the managed approach is future changes to the cc3000 firmware and hardware may also require changes in the wrapper (but that is likely to be minimal).  

 

I'm somehow sceptical that you'll be able to get raw packets, but my understanding of this device is far from comprehensive, so don't take my word for it.  (I think it's whole raison detre is to present a high-level berkeley sockets-esque api, so that's why I'm doubtful about that).  But no matter, it will make the job 'easier' to not have to fiddle with windows, retries, mtu, congestion control, etc.  Oh wait, you already did that.  Nevermind!

 

The managed implementation is especially worthwhile if you make a shield based this device, because then you can add it onto some existing platform.  It is a small wonder to me that shield vendors do not supply rich, robust, support software, but perhaps that's due to the dynamic of this DIY market.  Still, it seems a fertile ground for an enterprising person to produce a cc3000-based shield, supply excellent support software, and just beat the pants off all the current alternatives.  (well lasting until at least the next person makes a cc3000 board, and tells folks to download your free support software, haha, but that's part of how this market works.  then you have to differentiate a different way.)

 

I suspect that they won't change the firmware and hardware in a way that would break your implementation.  That would be bad business.  Maybe they would come out with a new device, shipping both, then obsolescing this one.  But its a moderately new part.

Ziggurat29, You have to let me help you.  I was just gearing up to do a .NET MF port myself.  I have an CC3000EM and I was about to setup an Arduino and ...

 

Sure, why not?

My plans (up to this point) were:

*  prove hardware interface (done)

*  prove SPI communications (done, I believe)

*  first make a managed code 'driver'

*  then make a native code integration with the firmware

So, two 'products' come out, one managed, and one native.  I want to do the managed version first because I believe it will be easier to experiment and debug in that context, and should cement my understanding of the part (the documentation is stunningly poor), and because I think it is a useful end in it's own right.  Once I have a thorough understanding of the device, then for the firmware it's a separate exercise to plan the integration, ostensibly replacing lwip (or maybe they can coexist, but I need to get into netmf's networking code to see what that means, since you'd effectively be making a multihomed system).

 

...  Can you post a zip of what you have so far?  Being able to start with (at least) the basic SPI stuff working would be very helpful.  

 

What I have right now, such as it is, is really exploratory code with no design to speak of, so it would be an embarrassment for me to post it.  If you really need it, I can douche out my more spirited comments and send it to you PM or something, but really I can sum it up this way:

 

Electrical:

using NP2

D13 - sck

D12 - miso

D11 - mosi

D6 - /IRQ

D5 - PWREN

D4 - /CS

3.3v  - pwr *

GND - no 'earth'ly idea

 

*  this will have to change soon as I start doing radio stuff; too much load

 

I am manually managing /CS and monitoring /IRQ for now -- maybe forever.  The SPI transactions often have to be done in two parts, and /IRQ is irksome in that it has mixed duty and doesn't seem useful to use it as an interrupt source, at least not so far, and anyway it gives me the feel of being level-sensitive and that's not supported on the NP2, but I'm not sure.

 

Software:

 

things:

SPI cc3000;   //I spi something that begins with the letter 'cc'    OutputPort cs;    //active low    OutputPort pwren;  //active high    //InterruptPort irq;  //interrupt; active low    InputPort irq;    //YYY I'm going to poll this for now until I understand this device better  

config:

  //make our spi (mode 1)      cc3000 = new SPI(new SPI.Configuration(        Pins.GPIO_NONE,    // SS-pin (we will manually do it)        false,        // SS-pin active state (low)        0,          // The setup time for the SS port YYY 50 uSec        0,          // The hold time for the SS port        false,        // The idle state of the clock (low)        false,        // The sampling clock edge (trailing)        1000,        // The SPI clock rate in KHz        SPI_Devices.SPI1));  // The used SPI bus (refers to a MOSI MISO and SCLK pinset)      //make our (manually controlled) cs (active low)      cs = new OutputPort(Pins.GPIO_PIN_D4, true);      //make our power control (active high)      pwren = new OutputPort(Pins.GPIO_PIN_D5, false);      //make our interrupt input (active low)  //XXX holding off on this until I understand the device better      //irq = new InterruptPort(Pins.GPIO_PIN_D6, false, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeLow);      irq = new InputPort(Pins.GPIO_PIN_D6, false, Port.ResistorMode.Disabled);  

  //power up      pwren.Write(true);  

 

the spi clock speed was chosen semi arbitrarily, to make debugging with the scope easier.  Side note:  specifying 1000 KHz actually gave me a clock of 640 KHz.  I measured.  Maybe a Gates reference joke -- 'who will ever need more than 640K'?  anyway....

 

action:

 

The SPI transactions are mostly normal.  'Mostly', because:

*  the first one only after powerup requires a 50usec pause after the 4th byte before continuing.  seems like a workaround for device bug.  I do this by two sequential WriteRead operations.  netmf is slow enough that you don't have to use any delay code, and you get about 84 us delay.  happily there doesn't appear to be a max delay.

*  the reads involve retrieving a length of the variably sized payload that follows, so you need to do those transactions in two phases also.

 

goofy first write (also this required to be a 'link start' command):

 

  //wait for the signal that its ready      //XXX III support a timeout      while (irq.Read()){}      begin();  //assert cs and (redundantly) wait for irq      //delay(50usec);      //goofy first write has a little pause after the first busy bit before moving on with the rest      cc3000.WriteRead(pktLinkStart, 0, 4, null, 0, 0, 0);      //delay(50usec);        //and then the rest of it      cc3000.WriteRead(pktLinkStart, 4, 6, null, 0, 0, 0);      end();  //negate cs  

reading is a little interesting in that you must retrieve the length, and then complete the reading:

 

  //wait for the signal that its ready      //XXX III support a timeout      while (irq.Read()) { }      begin();  //assert cs and (redundantly) wait for irq      //write header and read the length bytes      cc3000.WriteRead(pktReadHeader, 0, 5, pktReadPayloadLen, 0, 2, 3);      //make length into a number; header is big endian.  other things are little.      int nPayloadLen = ( pktReadPayloadLen[0] << 8 ) | pktReadPayloadLen[1];      if (0 != nPayloadLen)      {        byte[] pktBogoWrite = new byte[1];  //dummy        //read payload        //XXX sanity check on length        byte[] pktReadPayload = new byte[nPayloadLen];        cc3000.WriteRead(pktBogoWrite, 0, 1, pktReadPayload, 0, nPayloadLen, 0);        //XXX III 'spatchy      }      end();  //negate cs  

OK looks like I did wind up posting most of what I did so far, haha!

 

Some things:

 

*  a healthy level of distrust of the documentation is worthwhile.  For instance, they contradict themselves in what is the spi mode to use.  It is spi mode 1.

*  you can tell that different engineering teams worked on this, not necessarily in concert for whatever reason.  For instance, some values are big endian, and others are little endian, so watch for that.

*  the 5 byte header I would probably re-phrase as:

  *  unsigned char byDir;  //1 = write, 3 = read;  from the spi master perspective

  *  unsigned short sWriteLen;  //little-endian;  when op=1, master indicates payload length; otherwise zero

  *  unsigned short wReadLen;  //little-endian;  when op=3, slave indicates payload length; otherwise zero

 

I think this covers most of the SPI; I still need to get a handle on whether there is more /IRQ consideration since the doc claims it serves some double duty, and that there is collision resolution to be performed.

 

Beyond that, I planned to do some reading in the light of my newfound knowledge, before I do much more coding.  There's something called 'patches' which are not really clear to me if I care about, and they use the term 'event' which I think really means 'return value' and 'asynchronous notification'.

 

On the plus side, it looks like the part is what I would describe as:

*  SPI-based RPC mechanism to Berkeley sockets, with some added stuff as needed (e.g. setting mac, wifi keys, etc).

 

So I think it should be straightforward to implement an API even on the managed side that very closely resembles the existing network api, and possibly on the native side to mesh with what exists there as well.  Hope springs eternal!

I did try the dead chicken routine but nothing in particular happened (other than our old parrot arising from the dead which was kind of freaky btw).

 

I too have a Bus Pirate laying somewhere, still untouched since I use the scope instead, it works pretty ok for me.

 

Vdd is 3V3 but I might have accidentally applied 5V logic at some point effectively killing the pin (I'm using my own USB explorer board, not a Netduino).

 

Btw, are you also using the older TiWi-SL eval board from LS Research?

TiWi-SL.jpg

I soldered short wires onto pins 7 - 12 on both the J4 and J5 headers (and left all other pins unused), then stuck it down a regular breadboard.

 

well, at least you can have the chicken for dinner.  and zombie parrots are quite the thing I hear, but careful of the bite.

 

I did read that the boards are very un 5v friendly, so you may indeed be hosed.

 

Yes, that is the board I am using.  Didn't know there was a newer one, and digikey didn't have any advice, but it was kinda spendy anyway.

I probably should have taking your pin route (on the breadboard); I make a 'conventional' upward facing header that I could use the ever-popular-and-formerly-scorned-by-myself-but-now-I-am-a-convert jumper wires with female ends, so I could simply plug them into my NP2, but then I can't connect probes at the same time, so I had to solder additional free leads to probe with.  Would have been better your way on a breadboard!

 

Anyway, I'll give it just a couple more hours, then I have to go back to my regularly scheduled work for the rest of the week, alas...

Well, stop your grinnin' and drop your linen, it responded back to my kookily-crafted initial packet in a cogent way.  Now I will have to Shake a Leg, haha.

You can usually ignore those warnings, vendors typically stress such things on samples to maximize the probability of users achieving success in evaluating the part. I'm pretty sure you can leave the bag open for years and it will still work and yield an ok product for hobby purposes.

yes, moisture can absorb into the epoxy, potentially causing issues in reflow oven, so they recommend baking to drive it back out if it becomes 'moist' (i think physical distortion during the process, but I can't recall precisely).  important if you're wondering why your yields are lower than expected when making a zillion units, but if you're prototyping, you're probably more suspicious of your manual soldering; at least I always am haha.

your mention (hanzibal) of the .6 dip header reminded me of something:  The width of the cc3000 is such that the pins would be under the edges of the unit;  since the sparkcore photo shows the pins will to the side of the radio module, then I suspect that it is not a standard DIP footprint, that it is two rows of pin headers on a .7 or maybe even .8 width.

well I'll be back in town in a few days.  we'll see if any coding work is left for me to do....

we've got functioning dev boards and plenty of coding work to do.  Have fun on holiday (well, if it is holiday; 'good luck' if it's business)

Sweet Jesus!  That's great valkyrie; if you want, go ahead and put it on the codeplex; it probably would be messy to shuffle intermediate builds back and forth as forum attachments, and possibly confusing for someone who wants to download it.  I've not used the codeplex, but I imagine it is similar to all the other hosted scm, but with a dotnet focus.

I look forward to checking it out!

 

Hanzibal, I'd love to see your board layout when your ready to share (and if you're open to possibly annoying but respetful feedback).  Maybe even you could stick your eagles in a directory in the hypothetical hosted scm?

...

@ziggurat29: Have you ever considered politics or have they perhaps already got to you?    SMD.

politics?  never.  you got me beat this time on the reference joke, though!

 

But the ancient dusty frustum of a pyramid numbered 3^3 + 3 - 3/3 will give it a rest until the day of the moon....

Only comments I can add (for what they're worth) to Baxter's statement are:

*  LDO; low dropout from what input?  If it's a big enough difference, like 5 > 3.3., maybe ldo is not needed?  or maybe my bar for low is high? haha

*  it seems there are two potential hardware realizations:]

  1) a DIP form factor, with a premium on size/shape

  2) a shield form factor, with a premium on electrical compatibility (3.3/5v) (and also a form factor, but that's easy to achieve, but please do support the v3 pinout)

 

'2' speaks for itself, I think, and you'd probably be just fine using the Vin pin without needed a barrel connector.  Or if you really want to, use the Vin, and support an unpopulated barrel connector that can be selected via jumper or probably even solder bridge, because I suspect that the need for external versus using Vin is rare.

 

'1' maybe bears more discussion.  I do personally put a premium on the 0.6" spacing, and similarly on a 24/28/40 pin layout.  Also, I am not a mini user, so I'm naive to that market.  But...  Secret Labs' made a conscientious choice in designing the mini to be BASICStamp compatible (much as the netduinii are arduino compatible), ostensibly because this makes them more marketable by being able to leverage the existing community.  I think this has definitely worked with the 'duino' line -- can't say about mini because I'm unfamiliar.  Maybe what folks want more is 'small' rather than 'basicstamp compatible'.  In which case, I'd argue to make a 40-pin factor, with whatever pinout gives the strongest capability.

 

Lastly, out of respect for our host, Secret Labs is a hardware company.  They don't make anything off the software at all.  The software is free, and open (happily), and exists to support their hardware sales.  So, personally I feel a little awkward about discussing too much the notion of making alternative hardware in this forum, unless it's in the context of 'if you build this, we will come'.  Everything discussed up to this point has been completely open, but I mention this now really just to be explicit and clear.

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....

...
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

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...

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.

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...

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...

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....

Curious, what module/shield are you using?

 

I did a SIM900 interface recently, but it was contract work, so I can't post source right now without explicit permission from my client (I did talk to them already about posting non-core-ip source, and they were receptive, but I haven't made actually doing it a priority yet since I'm still pretty busy in pilot).  If you want to forge ahead in advance of the coming of that day, here at least are my experiences with it.  Shortest story:  SIM900 works, but is quite quirky!

 

OK, first, let me say that I was focused on the TCP client feature, and I did not do SMS.  My application supports wired ethernet (on the NP2), and also TCP/IP connectivity over the SIM900 module, (and some other communications channels I won't mention since they are off topic).  Truthfully, I think SMS is easier than TCPIP since it's oriented towards short, atomic, messages, rather than a stream, but much of what follows will still be relevant.

 

The SIM900 has an /embedded/ TCP/IP stack that exposes connection functionality via ancient-style Hayes modem-y AT commands.  You don't get to do tcpip proper, but rather you squirt chunklets of data back and forth via AT commands.  This has some challenges:

• since you are mixing channel data with control data (e.g. the AT commands themselves, and error responses), you've got to demultiplex that.  There is a 'transparent mode' that works a little like an old-school modem, switching inline between control and data, but you still have to look out for and use the +++ escape to get into and out of command mode.  Blick!  I chose to use 'non-transparent' mode, where the delineation is unambiguous, but you've got more parsing to do.  Also, if you are going to support multiple client connetions, or a single server connection, you will need this mode.  I would suggest coding against non-transparent unless you are really sure you will never need anything else, or if you are supporting a dialup modem as your fallback where this mode would be a natural analog.
• there is a single-connect and multi-connect mode.  I implemented multi-connect because, why not?  Single connect only gets you limitations as far as I can tell, and it doesn't really simplify coding.  And you have to use multi-connect if you ever want to do 'server'.
• it's not really documented, but the SIM900 is an idle-request design; i.e., you must wait until you have received some acknowledgement to an issued command before issuing another one.  Don't pour out a sequence of commands then eat the various responses.  Wait for each and every command to complete with a response; and, if you time out getting a positive/negative acknowledgement, you might be best off just throwing and letting some recovery logic get things back into a know state.  Oh!...
• the responses to all the standard GSM AT commands are minimal, clear, and parseable with a handcoded parser.  The reponses to all the simcom extensions, and certainly to all the TCPIP stuff, are not so much so.  Horror!  However I had an early epiphany in that the Netduino supports regular expressions.  You'll take a 30k or so hit on your app's image size, but parsing will actually become the pleasant part.  I was concerned about RAM usage, and so I did not pre-compile the regexes, and rather did that each time needed.  I was concerned about speed, but this is actually quite quick relative to the 19.2 data rate.
• there are so many error codes/scenarios that you will be happiest if you define an exception that you can throw for undefined/unknown/unhandled scenarios.  That way the calling module can catch it and at least recycle to recover.  My servicing thread looks like vaguely this:

while ( keepOnKeepinOn ){    try    {         initModemStuff();  //setting all the registers/options/whatnot         doAllModemyStuffs(); //actually pumping data        teardownModemStuff();	//down, you go!     }     catch ( ModemBooBoo e )     {         log ( e );         //Maybe Sleep() a bit before recycling around    }}

?

(^^ sorry, can't make this look right.  looks correct while editing; at least its super short)

 

In this way you can have something functional, yet robust against errors, right away, and then you refine the error handling as a separate task (e.g. maybe you don't need to throw, but can adapt to the condition).

• the AT interface to TCPIP is so peculiar that I created an abstraction that mostly looks like a socket.  This way I was able to strap on my protocol handler code on top of a real socket, or on top of a connection provided by the SIM900 with minimal effort.  You'll need to implement internal buffers for each channel (the module supports up to 8 client connections, or 7 client + 1 server).
• you send channel data by telling the modem that you want to do so, and it will present you with a prompt (which they call a 'promoting mark' haha).  Then you emit your data.  Then the modem returns automatically to command mode and you carry on.  This has some caveats:
  • they mention using Ctrl-Z to terminate the data.  There is no escaping mechanism, so if you happen to need to send an 0x26 yourself, you are hosed.  I designed my protocol to be textual (against my better wishes) because of this.  However, I made a booboo.  I failed to notice that the AT+CIPSEND= can take an optional 'length' parameter, in which case you /don't/ send the Ctrl-Z to terminate -- the modem will simply know you are done, and automatically return to command mode.  So now you actually can send binary with impunity!
  • the modem will asynchronously notify you of receive data.  Consequently, you must be prepared to receive it at all times and buffer it for your client's subsequent recv().  You must be prepared to throw away any overrun data.
  • the send channel has a limit on how much you can write at any given time.  This is like an MTU, and maybe it event is derived from the MTU because it is not fixed.  It depends on which network you connected to.  You must be prepared to take client send() calls and chunk the data up into multiple AT+CIPSEND= subject to this limit.  In my case, I keep an array of these per-channel limit values, which I query and setup as part of my connect() process.  That way they are always up-to-date when I need to do a send().
• because of all these things, I structured my SIM900 interface module somewhat like this:
  • receive data event handler (more on this later)
  • incoming data buffer, used for building textual lines.  This is a fixed 128 bytes which is more than long enough for any text lines that the modem produces (channel data doesn't go through this)
  • an array of received text lines; an event is signaled when new ones are added.  I limit this to 20 max, which really is way more than enough for all the commands the modem supports.
  • an array of channel info, including:
    • an event for 'received'
    • a receive data buffer
    • a 'max send len' value
  • state machine with states of:
    • Normal  -- making text lines, for command mode
    • PromotingMarkWaitGreaterThan -- first waiting state for the signal to send channel data
    • PromotingMarkWaitSpace -- second waiting state for the signal to send channel data
    • PromotingMarkPendingNormal -- we were waiting for a promoting mark, but are receiving an asynchronous text line (like a status change) before the promoting mark came, and so need to switch back to PromotingMarkWaitGreaterThan when it is finished
    • NormalReceive -- receiving channel data; put in channel buffer instead of using to build text lines
  • the receive data event handler notionally drives the state machine, taking the raw data and either building text lines (which will be interpreted as responses or asynchronous notifications), or buffering into the relevant receive channel, or the special case of noticing that the promoting mark has been received.  It signals an event when these things happen, on which the client thread can synchronize to pace it's activities.  For what it's worth, my code has 10 events -- one for each of 8 possible data channels, 1 for 'text line received' and one for 'promoting mark found'.
• I originally implemented using a dotNet SerialPort.DataReceived event for the COM port.  This works for a little while, then the event stops getting fired.  I don't know what this is, and others have complained about it.  I think it's a bug in the firmware.  I was distraught at the propect of redesigning until I hit upon this idea:
  • worker thread
  • while ! should end
  • if valid com and com is open and 0 != BytesToRead
    • read into buffer, signal 'come and get it' event
  • else sleep for a time guaranteed not to cause an overrun, which in my case for 19.2 and a 256 byte buffer in the firmware was 100ms

This scheme functionally resembles the DataReceived approach, so I was able to shim it in without disrupting the rest of the design.  In fact, since it is a fundamental problem with the com port, and because I use three com ports, I factored this out, and made a virtual method for the 'DataReceived'.  Then it really looked a lot like the dotnet mechanism.

• The rest of the module consisted of methods that wrapped the AT command dialogs that I was interested in exposing.  They all followed a general form:
  • lock()  //the modem has an idle-request design, and an issued AT command should be fully processed before issuing another
  • generate the AT command text from parameters
  • send the command, collect received text lines subject to various conditions such as count, timeout, and where the response is expected to be found in the sequence
  • inspect the result; perhaps parsing out return data.  As mentioned, I use regex's for the non-trivial ones, but you can certainly hand parse if you can't or don't want to use the regex assembly
• OK fun stuff, the SIM900 is not consistent across commands as to where things like 'OK' are emitted.  Most commands response by sending info, and then finish with an 'OK'.  So you can pull text lines until you hit 'OK' or an error indicator for most things.  But not all!  Some (particularly the SimCom extensions) return 'OK' and /then/ return the requested data, so you have to just know how many lines that will be on a command-by-command basis.  Because of this, I have a couple helper methods like 'sendATCommandGetResponse' and 'sendATCommandGetNLines' so I can tweak those particulars as needed.

So, once you have all that framework in place, you can just crank out all the AT commands you want with relative ease, since you're now working at a higher level of abstraction (completed text lines and chunks of channel data).  This is also why I said that adding SMS will be easy; it's just another AT command.

 

OK, hardware quirks.  The particulars will depend on the module/shield you are using, but in my case:

• Power.  There is no pin you can read to know if the modem is on!  WTF?  So, the way I do it is:
  • send empty 'AT' command.  This will alway return 'OK' if it is in command mode and your serial port is set up.  It has a secondary benefit in that this is what you must do to trigger autobaudding.  Note, for autobauding, the AT is case-sensitive.  Anyway, I interpret a failure of this command to mean 'power is off' which is not strictly true but is good enough for my purposes.
• Power.  To turn on the power, you simulate a button push by pulsing D9.  Haha, yes.  OK, that's how it's done.  Be sure to hold it long enough and wait after releasing it for the modem to 'boot' before sending the intial blank 'AT' command for autobauding (and sanity check that it is indeed on).
• There is no handshaking.  The SIM900 module has RTC/CTS lines, but on my module they are not brought out.  This normally gives me the heebiejeebies, but since the modem has an idle-request design, and because there are well-defined maximal sized data chunklets involved in the various interactions, you can robustly get away without the handshaking so long as you are punctual about consuming the receive dataas it comes.
• Some of the early boards out there will suck the living daylights out of your Vcc when powering the radio up, causing a spurious reset, so you really need to power the board from the jack.  Later rev boards are more gentle.

OK, GPRS quirks:

• you need to get a SIM card.  I used EmbeddedWorks.
• the GPRS acts a bit like a dialup mode, and uses a thing called an 'Access Point Name', which looks like a DNS name, but don't get too hung up on that.  Its a magic text string that you must provide at certain times to make your board able to get to the Internet.  You do this by 'activating a PDP context', which requires the APN to do so.

Your wireless provider will tell you what it is.  I don't know why they don't just put it on their web site -- its not a security issue because its not actually a DNS name and you have to have a valid SIM card to use it, but there it is.  Save yourself hours of trouble and just ask support immediately what the APN you need is.

• the SIM900 needs the APN at various times.  Moreover, sometimes it needs the APN indirectly, by referencing an 'index' to some stored APNs, and at other times it needs it explicitly in the AT command.  Sheesh.  Anyway, when it is 'indexed', the index is into some NVRAM, which you only need to set once.  In fact, you want to avoid writing to it too much for wear reasons, so what I do is:
• query what's there
• see if it's already set to what I want
• if so carry on
• if not set it

that way the board is self-initializing.

• be prepared for the mobile provider to terminate your PDP context out of the blue.  If you implemented the exception mechanism I described, you will be robust against this automatically, but you can also handle the asynchronous notification from the modem and try to restablish connection more 'surgically' if you want.
• be aware that the mobile provider will consider hammering out reconnect attempts as abusive, and will make it so you cannot reconnect!  I did this several times while in my code/test/debug process.  You just have to wait a while (hours) and then you can resume.  I put a Sleep in my recovery loop to avoid hammering their system.
• I do not know why, but I seem to pay for about 4 times as much actual channel data that I send.  I think they charge even for IP headers, but even that seems like way too much.  I need to follow up with my mobile provider about that, but I'm still within my monthly limit so it's not a crisis for me to understand.  I do mention this so you can take it into consideration for planning.
• little secret:  these devices operate on some different 'part' of the cellular network, and the connection is stony-solid even when festivals are in town, which normally result in a no-talk/no-text zone for consumer's handsets.  Hmm!

So my modem init sequence looks like this:

• setup COM port
• send empty AT command to test for power on
• flick power switch if needed, and retest power on
• reset modem with ATZ
• turn off echo mode with ATE0
• query stored APN, set if needed.  There are two slots (indices) you can store it in, and I arbitrarily store mine in slot 1.
• query SIM card ICCID.  I do this to detect if there is a SIM installed.  You won't get far without it, but you will get far enough that you will not know you are without it.
• give the modem a chance to get on the network, which can be slow the very first time; presumably because there is first-time activation stuff going on in the mobile provider's system.
• activate the PDP context (this will refer to the APN by index) with an AT+CGACT.  This can be very very slow the first time; I use a timeout of 60 sec
• set the TCP to the 'multiconnect' option with an AT+CIPMUX.  This will imply 'non-transparent'; don't issue a 'set non-transparent' command, because that will now return an error (even though the option value is correct, hmm!).
• start the 'TCP task' wtih an AT+CSTT.  Here you will need the APN again, but this time not by index; rather it's part of the AT command itself.  Hmm!  Whatever.  I am guessing that this is some sort of separate program running in the SIM900 module that you have to crank up.
• 'bring up the wireless' for the TCP 'task' with an AT+CIICR.  You just have to do it, and it can take a while; I use a timeout of 30 sec.
• 'get local IP address' with an AT+CIFSR.  This is more than a gratuitous query, it is required to make you actually have an IP address assigned.  You can throw it away or just log it for fun as I do.

Now you're ready to make connections!  You make a connection by supplying host and port number, and a connection slot number.  As mentioned, the SIM900 will support 8 connections 0-7, but since the first connection is special, I use connection 1-7.  The first is special in that it is the only one that can support server functionality.  So if you make a client connection on 0, you can forget about server.  You establish the connection with AT+CIPSTART.  Internally, if successful, I immediately also issue a AT+CIPSEND? to update the connection max length values.

 

Now you can finally do useful things with your emulated socket Send() and Recv() (and Poll(), isConnected(), etc).

 

My teardown does:

• shutdown the TCP task
• detach from network
• pulse power to turn off (there is an AT command for this as well, but I don't use it)

Oh, one last thing worth mentioning.  Your connected modem will probably NOT be internet reachable.  You get a non-routeable address like 10.x.x.x.  If you need your units to take inbound requests, you will need to either:

a)  work with your mobile provider, who will probably set up a VPN into your device's subnet.  This will be thousands of dollars up front with also some monthly costs.

b)  set up a 'relay agent' that your devices connect out to, which will forward inbound requests (and responses) through that single device connection.

I did 'b' since I've done this many times before to achieve firewall/NAT traversal.

 

Oh, one last last thing:

• avoid some self-inflicted baldness by investing in one of those FTDI modules.  You can develop all your code on the desktop, which is way way easier (I find) to develop and debug than on the device.
• you can also use this same module to 'monitor' the communications to the modem using something like putty, etc.  I only found it necessary to monitor the modem data back, so I only needed one, but if you want to monitor both sides, you can use a pair of them.
• If you do develop on the desktop, remember that not everything there is available on dotNetMF.  I routinely did trial compiles to validate that as I went; especially when developing fancy stuff to avoid coding myself into a porting corner.
• Also be aware that some of those platform differences will be visible only at runtime.  E.g. the regex impl on dotNetMF actually derives from a Java project, and not all the features are there.  In my case, I had designed my regexs with 'named capture groups', which aren't supported on netmf, so I had some boring porting work to do.  You only find out that at runtime, however, with a rather uninformative error message in the exception thrown.

 

Hope that is of some use!

 

-dave

unknown, however the stuff above arises mostly from the fact that these modules are effectively 'systems-on-the-side' of the *duino, and communicate via a high-level application protocol rather than a low-level driver protocol.  I just took a look at the Spread Spectrum SM5100B module and it has an eerily similar AT command set for performing the TCP/IP stuff (for some reason I thought the SIM900 commands were their own proprietary creation).

 

On the plus side, maybe, I think the TCP/IP stuff was the most complex on the module's features  (well, maybe except for Server mode, which I haven't yet implemented).  But there's still a fair amount of AT commands that are needed to be issued just to get it up on the network and ready to do what you wanted.

 

On the other plus side, once you have bit the bullet and made a library that is robust, then you can use the module with relative ease.

 

The modem-style AT command approach is established practice and indeed much of the command set is derived from the GSM standards, and it's probably a great boon to the 8-bit folks.  But if I were a module designer, I think I would have preferred to expose an SPI interface to IP-level functions, and have the module integrate more-or-less transparently into the existing TCPIP stack.  Then your app could use sockets like anything else (you'd still need to do some stuff somehow to get the radio up and on GPRS beforehand, but please no AT commands).

 

-dave

yay, jtag pods and micro 10pin adapters and pin headers and soldering has happened.  and I downloaded, installed, configured, and ran OpenOCD and can connect to it.  Because I don't know gdb natively, I also installed Eclipse, the CDT, and am configuring that.  There is no 'elf' output file from the build (that I can see), so I have to think about that some more....

Edit:  looks like the AXF file is in fact, an elf file.  cuz we need more filename extensions, I suppose.  Anyway, at length I have debugged past the boot loader, into the tinyclr, and fairly early in the process it goes off the rails with an illegal instruction. At present it looks like the PrepareImageRegions is where the fault is stimulated, so I need to look at that some more...

Edit2:  I discovered that the stack was smashed during Prepare_Zero; I disassembled the stock firmware for comparison and discovered some erroneous constants stemming from scatterfile errors.  I corrected those and got past that crash, but have happened upon another one in HAL_Initialize(), so the process continues.  This time it seems to happen at ENABLE_INTERRUPTS(), and interestingly doesn't happen when I single-step, only when I 'continue' through it, so maybe some interrupt aspect is wrong...

Edit3:  I discovered a couple more scatterfile problems involving placement of the interrupt vectors and the 'custom heap', I am still trapping, however I notice a curiosity:  In the disassembled firmware, the vector addresses are odd, and in the built firmware, they are even.  Looking in the armarm (for v7m) I see that the low bit MUST be set, so I am really curious as to why this is not being done for the gcc build; almost like an arm/thumb problem.

Edit4:  Well, I got it to the point that I can connect with the MF Deployment tool, and ping, and get Device Capabilities, so it's getting there.  However PlugIn Debug Show Device Info faults, so still more work to do.  I also wish there was a comprehensive test app so that I can get some code coverage, to weed out any other faults.  I'm still distressed about the item described in Edit3, which I worked-around in the interim by explicitly setting the low bit, but I'm sure that's not the 'correct' fix.

can't say for sure about your vs2010 problems going back-and-forth because I havne't tried yet.  My only guess at a suggestion (if it's not immediately obvious) would be do remove the .netmfqfe2 sdk, and the netduino sdk, and install the versions of qfe1 (and for the netduino 4.2.1, which is qfe1 based).  But maybe that's overkill.

 

I did not complete the eclipse setup of jtag because I was having initial problems with my openocd config so I needed to get closer to the wire to reduce the number of variables.  Once I got there, I just plugged along with gdb.  You're welcome to the config and a couple batches I used to setup, if interested.  I might go back to trying to configure Eclipse at some point, because automating the gdb is certainly nice.

 

I don't remember needing to join a forum to download openocd, though.  I might have gotten a build off of freddie chopin's site.  It was named openocd-0.6.1.zip.  The binaries worked fine for me, and I just made a board script (which really was just copied from the existing stm32f4discovery.cfg)

I'm using the 4.7.2 yagarto toolchain, but I can't complete the build right now because of function signature mismatch in
CLR_RT_HeapCluster.cpp for HeapCluster_Initialize

It appears that TinyCLR_Runtime.h and also Execution.cpp in the source are oriented towards an older version of .netmf where HeapCluster_Initialize() took one parameter, instead of two as in the 4.2QFE2 version. It's not yet obvious to me how to correct it myself properly, but then I haven't spent any time on it yet. But otherwise there was about nine minutes of compiling happening, so thats a start.

-dave