Just wanted to join the chorus and say that I'm happy to see the NP2 announcement. When the STM32F4-based Go was announced, I was worried that firmware development for the AT91SAM7X-based NP would suffer as a result of it being based on "the old platform". Whether nor not my fears were well-founded, the NP2 eliminates them. I'll certainly be buying one.

Is this diagram perpetuating the myth of COM2 RTS/CTS functionality or is hardware flow control actually working on the NP2? Please see the discussion at http://forums.netdui...ts-always-high/ and the bug at http://netduino.code...com/workitem/5. As far as I can tell, there has never been a shred of evidence supporting the claim that hardware flow control has ever worked on Netduino Plus and I assume that the same is true for Netduino Plus 2. If somebody can prove otherwise for NP2, it would make my day.

Hi all,

I'd like to try to capture events, such as those seen in the graph, from a Vishay 125UN strain gauge.



The time between events is on the order of 15 seconds to a minute, or so. The individual events are (as seen in the graph) on the order of a few milliseconds. I'm not sure how many samples there are in the data that's graphed, but it's probably a few hundred, so let's say that samples will be taken on the order of every 10 microseconds.

My thinking, so far, is that I'll need to build a shield that uses a more-real-time µC to monitor the strain signal, watch for some trigger level, and record something like 1000 samples after the trigger level is reached. Maybe the shield could signal the N+ once the samples have been collected and the N+ would then fetch them and write them to a .dat file on a micro SD.

If I use a 16 bit ADC on the shield, I guess each event would be about 16K. If the helper µC has 16K of RAM and i2c, I guess it could signal the N+ (digital out on the helper connected to digital in on the N+) and the N+ would then pull the sample data via an i2c connection between them? The data xfer from helper to N+ to SD doesn't need to be super fast and I could put an LED on the shield indicating "transfer in progress" so that I know when I can or can't kick off the next event.

Does this sound like a reasonable approach? Are there simpler approaches? Any suggestions as to what would be a good helper µC, keeping in mind that ease of programming and an active user community are more important than cost of the device.

Thanks in advance for any advice!

I received a Netduino Plus for Christmas this year to keep my other Netduino company. After working my way through the "Internet of things" book from O'Reilly, I decided to write a Netduino MQTT client after hearing about MQTT a few weeks earlier.

Thanks for writing this, Dan. I've been curious to learn more about MQTT and this gives me something concrete to play with on my Netduino.

To date, I've been doing all my Netduino-->iPad/browser communication using HTTP and AJAX, but this is slightly awkward when it comes to event streams from the Netduino to the iPad. I've modified Netduino "http server" code to allow for preemptable HTTP "long polls", but it sounds like MQTT might be a more elegant way to handle the event oriented portion of the communication.

Hopefully there's a JavaScript implementation of subscriber-side MQTT.

G.D. Sever's class has served me well for months, but I finally ran into a bug, so I thought I'd document it here.

The 24LCxxx EEPROMs have page write buffers (PWB). The PWB size varies from model to model and is not necessarily the same for all models with the same capacity:

    24LC16B:  16 bytes
    24LC32A:  32 bytes
    24LC64:   32 bytes
    24LC128:  64 bytes
    24LC256:  64 bytes
    24LC512: 128 bytes
    24LC515:  64 bytes

Here's what the data sheet says about pages:

Page write operations are limited to writing bytes within a single physical page, regardless of the number of bytes actually being written. Physical page boundaries start at addresses that are integer multiples of the page buffer size (or ‘page size’) and end at addresses that are integer multiples of [page size – 1]. If a Page Write command attempts to write across a physical page boundary, the result is that the data wraps around to the beginning of the current page (overwriting data previously stored there), instead of being written to the next page, as might be expected. It is, therefore, necessary for the application software to prevent page write operations that would attempt to cross a page boundary.

It seems as though there are two situations where you can run into trouble when writing to EEPROM with the _24LC01 class:

• Writing any value longer than the page size.
• Writing any value (even short ones) across page boundaries.

This is a quick and dirty fix, but I thought I better post something if I was going to point out the problem. I've tested this by writing a long string value (several pages long) to a starting address that's not a page boundary. I'm not sure how much this can be cleaned up without modifying the underlying I2CBus case so that it allows writing of specific data out of buffers (i.e. by start index and length) instead of assuming that the entire buffer should be sent. Any clean up suggestions will be welcome.

public int WriteBytes(UInt16 writeAddress, byte[] data)
{
    if (writeAddress + data.Length - 1 <= MaxSize)
    {
        int result = 0;
        int offset = 0;
        int availableInPage = PageWriteBufferSize - (writeAddress % PageWriteBufferSize);
        while (offset < data.Length)
        {
            int bytesRemaining = data.Length - offset;
            int bytesToWrite = bytesRemaining > availableInPage ? availableInPage : bytesRemaining;
            byte[] pageData = new byte[bytesToWrite];
            for (int i = 0; i < bytesToWrite; i++) pageData[i] = data[i+offset];
            // Grab the low byte.
            byte addrLow = (byte)((writeAddress + offset) & 0xFF);
            if (MaxSize > 0xFF)
            {
                // double byte address.
                byte addrHigh = (byte)(((writeAddress + offset) >> 8) & 0xFF);
                result += Write(new byte[] { addrHigh, addrLow }, pageData);
            }
            else
            {
                // single byte address
                result += Write(new byte[] { addrLow }, pageData);
            }
            offset += bytesToWrite;
            availableInPage = PageWriteBufferSize; // After start page, all of page is available.
        }
        return result;
    }
    else
    {
        throw new Exception("Address too high and/or value too long.");
    }
}

It depends on the following... A cleaned up version would save the PWB size instead of switching for it every time.

public ushort PageWriteBufferSize
{
    get
    {
        // Note: PWB size is NOT a function of capacity. 
        // E.g. 24LC512 and 24LC515 are both 512 kbit, but have PWB sizes of 64 and 128 bits, respectively. 
        switch (ic)
        {
            case IC._24LC16B: return 16;
            case IC._24LC32A: return 32;
            case IC._24LC64: return 32;
            case IC._24LC128: return 64;
            case IC._24LC256: return 64;
            case IC._24LC512: return 128;
        }
        throw new Exception(); 
    }                
}

The arduino is only able to reach a 9600Hz sampling rate for the adc, so it will not suffice.

Thanks for ruling that out. I think I'll want something on the order of 150kHz to 300kHz sampling rate. The DSO Nano claims to do 1MHz and it's based on a ARM Cortex-M3, so maybe I'll look at something like:

• NXP mbed
• Maple Mini

Both of these look fairly friendly.

Thanks for the comments. I don't need to match the graph exactly in terms of resolution in either direction. Finer resolution is obviously better but I'll weigh that against simplicity of implementation.

As far as triggering, it seems like it would be similar to a rising trigger on an oscilloscope. In fact, I sometimes think of the project as a "dumbed down" DSO Nano that would have a fixed trigger mode, fixed trigger level, and no screen. Maybe I could actually hack the DSO Nano firmware to save after each trigger, as it also has an micro SD.

I'm completely clueless when it comes to making calls into native code on an N+, but that sounds like it might be an interesting approach for a first version. The native call would need to monitor the strain gauge level indefinitely, watching for a rise up through the trigger level. Once the trigger level is noted, it would sample for something like 3ms, then return. Managed MF code would then shuffle the result to the micro SD. Is MF blocked when native code is running? If so, it wouldn't matter for this application, unless there's something in MF that must run at regular intervals.

What should I read to get up to speed on native code on the N+?

I was reading the at91sam7x512-au manual and it says that there is a conversion sequencer built into the adc section of the chip and that the adc also has 16kbytes of peripheral memory. It seems that the sequencer was designed for exactly this purpose, ie fast synchronous adc when you can't guarantee processor availability.

Sounds interesting. The 384K samples/sec rate is just about right. It also says that it has "automatic wakeup on trigger and back to sleep mode after conversions of all enabled channels." How would the sequencer get triggered? A little bit of extra electronics that would raise an interrupt signal on an external trigger pin when the signal is above the threshold voltage?

If Dave is still following this thread...

FusionWare.SPOT.Hardware.I2CBus::Write code appears below. Does i2cDevice.Execute return (i.e. not throw an exception) if it times out? If so, that might be why you're seeing the System.IO.IOException (timeout happens before the specified number of bytes were written, so the test fails, and the exception is thrown).

        public void Write(I2CDevice.Configuration Config, byte[] WriteBuffer, int TimeOut)
        {
            ThrowIfDisposed();
            lock(this.Device)
            {
                this.Device.Config = Config;
                I2CDevice.I2CTransaction[] xacts = new I2CDevice.I2CTransaction[] {
                    I2CDevice.CreateWriteTransaction(WriteBuffer)
                };

                // I2CDevice.Execute returns the total number of bytes
                // transfered in BOTH directions for all transactions
                int byteCount = this.Device.Execute(xacts, TimeOut);
                if(byteCount < WriteBuffer.Length)
                    throw new System.IO.IOException();
            }
        }

Contrast with the following Write implementation from http://blog.codeblac...-with-I2C.aspx. It assumes that the timeout will sometimes occur. Instead of throwing an exception, it executes in a loop until all the bytes are written.

    private void Write(byte[] writeBuffer)
    {
        // create a write transaction containing the bytes to be written to the device
        I2CDevice.I2CTransaction[] writeTransaction = new I2CDevice.I2CTransaction[]
        {
            I2CDevice.CreateWriteTransaction(writeBuffer)
        };
 
        // write the data to the device
        int written = this.i2cDevice.Execute(writeTransaction, TransactionTimeout);
 
        while (written < writeBuffer.Length)
        {
            byte[] newBuffer = new byte[writeBuffer.Length - written];
            Array.Copy(writeBuffer, written, newBuffer, 0, newBuffer.Length);
 
            writeTransaction = new I2CDevice.I2CTransaction[]
            {
                I2CDevice.CreateWriteTransaction(newBuffer)
            };
 
            written += this.i2cDevice.Execute(writeTransaction, TransactionTimeout);
        }
 
        // make sure the data was sent
        if (written != writeBuffer.Length)
        {
            throw new Exception("Could not write to device.");
        }
    }

Maybe FusionWare.SPOT.Hardware.I2CBus::Write should do the same, but then I guess it would get stuck in an infinite loop if faced with anything other than an intermittent problem. I suppose the exception approach is better, if it's caught and dealt with somewhere appropriate up the call stack.

You could always argue that the netduino is a really big CPLD.

No, I don't think that argument can be made. Seems to me that the distinguishing feature of CPLD or FPGA is that you're working the "bare metal", literally wiring together logic gates. Something like the Netduino builds many levels of helpful hard-wired and hard-coded abstractions and services on top of that (ARM7, NETMF, C#, etc), and you're forced (but usually very happy) to work through them.

CPLD lets me configure logic. Netduino lets me run software on hardwired logic. You can't say that the latter is a version of the former.

Wow! That is a cool little item! I see one in my future.

I've been talking to the guy who designed and sells the Amani and he's got me convinced that I can skip the MCP23017 and implement i2c in the CPLD along with the rest of my project. The idea seemed crazy, at first, but I've been reading up on i2c implementation and might actually try it. But I'd try the VHDL and Verilog implementations on www.OpenCores.org first, to see if I can modify them for my needs.

the biggest complaint that I've read from hobbyists is that they just don't "get" how CPLD's work because of the steep learning curve

There's some truth to that... I read a lot of FPGA and CPLD stuff before I finally realized that environments like Altera's Quartus II ($0) make it as simple as transcribing the design I had already drawn up in Eagle. Quartus has a library of 74-series components, so it really was very straight forward. I think it's safe to say that anybody who can fumble their way through a design based on 74 series logic can certainly do the same in Quartus for CLPDs or FPGAs.

Hi all,

I've been working on a digital circuit that I was hoping to put onto a Netduino shield. It's not huge, but it does require the following:

   2x 74hc21 (4-in and)
   2x 74hc393 (counter)
   1x 74hc109 (flip flop)
   1x 74hc08 (2-in and)
   1x 74hc32 (2-in or)
   1x 74hc04 (inverter)
   1x MCP23017 (i2c expander)
   2x 3.5mm jacks
   9 capacitors

My morbid fear of SMDs continues, so I spec'ed it as using DIPs in Eagle. Then I realized that you can't really fit 9 DIPs on an Arduino shield (haven't yet found a Netduino shield for Eagle).

So, I went out onto the web looking for programmable logic. Finally stumbled across CPLD which seems to be what I was looking for. Here are my CLPD questions:

1) Why isn't it more popular among hobbyists? SparkFun, for example, seems to have nothing related to CLPD.
2) Anybody have any CPLD preferences they'd recommend?
3) I'm leaning toward this Xilinx on a 40 pin DIP breakout product. Any comments on it?

Should be simple to fit the MCP23017, the 40 pin Xilinx breakout, the jacks, and a couple caps on a shield, but let me know if you think I'm heading off in a bad direction.

Can't comment on the Xilinx but are you aware of the Ubershield?

Thanks for the pointer -- I'm definitely curious about any CPLD or FPGA option but, so far, CPLD seems more straight-forward to me.

CPLDs aren't very popular with hobbyists due to their complexity and difficulty of use.

I dunno... I'm new to digital and CPLD doesn't look that complex or difficult and it seems like a big convenience to have a device that will basically do everything digital and is forgiving of design mistakes.

I would recommend the Altera MAX series 7032S or 7064S.

How about the EPM3064ALC44-10 as seen on the Amani 64 shield? Or the EPM240 as on the Amani GT shield? Haven't figured out the connectors on the Amani GT, but maybe I could put the MCP23017 on a daughter board, although I'm not sure how the i2c would get back to the Netduino through the Amani GT shield.

This might be a crazy suggestion, but there is a JSON parser available: netduino.helpers.Helpers.JSONParser. As is, it wouldn't solve the OP's problem, but I wonder how hard it would be to modify it so that instead of building up a data structure of Hashtables and ArrayLists it would fire off SAX-type events to a ContentHandler? Maybe I'm kidding myself, but it looks like it might be easy. I guess the result would be called "SAJ" (Simple API for JSON). Googling "SAJ Simple API for JSON" shows that at least one person has already done something like this for other platforms.

Just FYI, pins D7/D8 can be used for either RTS/CTS _or_ a third serial port on the Shield Base.

So I read elsewhere, but I think the original post was w.r.t. the "plain old Netduino" (hereinafter "PON"). Still, the Netduino Go looks interesting, so I will almost certainly switch my application onto a Shield Base, once Ethernet and SD are available, and I guess that will finally end my RTS/CTS agony. Glad to see you guys working on new stuff.

Netduino's pins D7/D8 are RTS/CTS (flow control for COM2), not another serial port.

This is a little late, but I wanted to post a correction: D7/D8 are supposed to be flow control for COM2. They don't function as such in 4.1 or 4.2. If anybody reading this thread cares about RTS/CTS, please comment and/or vote on the CodePlex issue, as it's still "unassigned" with no resolution in sight.

Thanks

You could write your own ultra-super-efficient compiler in your copious free time. But seriously: I share your pain. Chris (or whoever): This might be a stupid question, but will there ever be a SAM7X1024 that would let us get around this problem? If not, and SAM7X512 is the end of the line, what's next for Netduino?

Thanks for responding to the OP, Chris. Unfortunately, I guess my question was, indeed, too stupid to merit a response.

Valkyrie,

How can you tell if an Ain is fried? Does it no-longer function at all or does it just give bad readings?

What does it read if you jump 3V3 to it?

Here's some reading:

A thread about BM085, i2c, and pull-up resistors: here.

A really good web page about pull-up resistors and i2c: here.

In a nutshell, you need to choose pull-up resistors to match the characteristics of the bus and all the devices on it, but it seems like i2c is pretty forgiving. If you keep adding breakouts with built-in pull-ups, the total pull-up resistance will be LOWER than the LOWEST value on any given breakout (resistors in parallel rule). I eventually ended up cutting some resistors off a breakout to solve this problem.

IOIO looks interesting. USB host, Bluetooth, beta firmware supports ADK. More info:

• Sparkfun Listing
• Hardware / IO Overview
• Tutorial

As far as I know, generics aren't supported in NETMF. See http://forums.netdui...rics-in-netmf/.

i would like to implement a wishbone bus interface between my netduino plus and an FPGA.

I can't speak to your CLR question, but isn't Wishbone intended to be used between components on the FPGA? When it comes to bridging the gap between the FPGA and the Netduino, wouldn't you use i2c or SPI? There is a Wishbone compliant implementation of i2c (and probably an SPI one too) at www.OpenCores.org.

Sorry if this reply isn't a direct response to your question, but I'm wondering if you could comment.

Hi Andy.

I think you might want to look at DataReceived. You can create an event handler for this event type and have it write out to the SD card. Since interrupts might come in quick succession, you might need to make sure that the event handler protects its critical section so that there aren't threading issues.

Somewhere in the forums there is a SerialHelper class which builds up a buffer in response to DataReceived events. You might want to hunt it down and use it as a starting point. Instead of building up a buffer, you'd be writing to SD.

Do you know, in advance, how many bytes the JPG will be? If not, it will probably be a little tricky to detect the end of the image.