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.

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.

I'm not usre I fully understand all of this but the Amani GTX is like a FPGA device onto which you can program all sorts of really fast logic functions? Could you give some more useful examples of what the Amani GTX can be programmed to do?

Yes, CPLDs are similar to FPGAs. There's an architectural difference between the two but (as far as I can tell) everything I've learned working with the CPLD is portable to FPGAs. I chose the Amani GTX because I liked its form factor and the Altera tools. One web page described CPLDs as "virtual breadboards", which appealed to me because I was in the process of building this project out of 7400 series components -- building the same design *inside* a CPLD seemed a lot simpler than buying parts, designing a PCB, etc. Altera's tools include a library of components that mimic the 7400 series, so that's where I started. By the end of the project, I had started creating my own components using Verilog.

There are a number of example projects here and here. Have a look at "Arduino SRAM Expansion: Supplemental Address Injection and Packet Interception".

Do your serial numbers need to be sequential? Each one being the previous plus one? If not, can you use the MAC address instead of assigning your own serial number?

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

I've been interested in pursuing a few projects with timing requirements that exceed what the Netduino can do for me, but I am intent on keeping Netduino/NETMF/C# at the core of these projects. A few weeks ago I posted a query about CPLD shields. I eventually settled on the Amani GTX and am so pleased with the results that I thought it would be worth sharing some info here.

The project I completed this weekend measures the velocity of flying projectiles. These are usually called "chronographs" and are used in archery, airsoft, and shooting hobbies. The basic idea is to use two optical sensors spaced some distance apart (say 2 feet) to measure the transit time of a projectile. When the first sensor fires, a timer starts. When the second sensor fires, the timer is stopped.

I used two CED M2 sensors. CED manufactures chronographs and sells these sensors individually as replacement items, since people tend to accidentally shoot them when trying to fire just above them. They have a 20ft cord with a 3.5 stereo audio jack, which I figured I'd just plug into project. I'd imagine there are lots of projects other than chronometers that could use these sensors -- at one point I was measuring the RPM of a box fan with one, while figuring out how it worked.

I cracked one open and it seemed like it took 9V, regulated it to 5V, and returned a 5V signal. Hooked one up to 9V, connected my DSO Nano V2, and learned that it sent a 5V digital signal, going low when something passes and casts a shadow onto it. (I've read that the DSO Nano is a "toy", but I get a lot of mileage out of it).

So, this is where the real problem begins. If a projectile is traveling at 2400 fps and the sensors are 2 feet apart, the time between first and second sensor detection is on the order of 800 uSec. If there's a way for the Netduino to reliably measure that with a resolution of about 1 uSec, I don't know what it is. So, this is where the Amani GTX comes in.

It comes with 'duino headers which aren't seen in the pic above. I soldered them in and stacked it onto my project. Then I whipped up a little "pmod" with 3.5mm jacks. This is how the sensors connect to the Amani GTX.

I'm told that this would have been OK for the Amani, but I decided to add resistors to divide the sensor voltage from 5V to 2.5V before actually trying it -- pictured is the version without the resistors. So, the sensors plug into my "Pmod", the "Pmod" plugs into the Amani, and the Amani plugs into the Netduino. Now I needed to configure the Amani.

Since the Amani GTX is based on an Altera Max II CPLD, I used Altera's free Quartus II and ModelSim tools for creating, testing, and deploying designs. I decided that the design would communicate back to the Netduino via serial, so I designed a simple asynchronous serial transmitter in Quartus, as part of the design. The pros will probably laugh at my design, but here's what I did, just to give an idea of what it's like to work in Quartus:


The bottom line is that I'm now able to measure the time between sensor hits to about 1/4 uSec and those times are shuffled off to the Netduino via serial. It all works like a charm and if I ever decide that I want to use the Amani for some other project, I can reconfigure it with new application-specific logic. But I've got more to do with this project, first. For instance, I'm going to add Digilent's PmodAD1 (12 bit ADC, shown below) and an Amani RAM daughterboard to solve a problem I originally raised in this thread. Should be able to measure the projectile transit times and log strain gauge data (at 1 million samples per second) simultaneously, on the Amani.



Well, I hope that made sense... It was a sort of stream-of-consciousness post, but I have been really pleased with CPLD and the Amani GTX and wanted to share something of the experience. Hope this info might be useful to others on the forum.

P.S. I have no connection to Amani, Digilent, Altera, Seeed Studio, SparkFun, or CED other than being a satisfied customer of each.

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.

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.

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.

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.

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.

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.

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.

Hi, I've read that 4.2 RC5 will allow C# code to set the PWM frequency, whereas it's fixed at 10kHz in earlier versions. If I've read correctly, what will the max frequency be? I'm hoping to use this to generate a clock signal at a frequency of about 1MHz or 10MHz. If the Netduino can generate a clock signal, another circuit will count the number of clock cycles between a start pulse and a finish pulse. Does it make sense to use something like a 74HC4020 to count (14 bits will be enough) assuming that I only send it the PWM clock signal between the start and finish pulse? Thanks

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

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?

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.

Hi Jerfy. This isn't really a Netduino-specific question, so you'll find all sorts of discussions of I2C vs SPI if you Google for "I2C vs SPI".

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

Thanks, Mario. I hadn't ever really thought about DINs vs jacks. I went with the latter since the device I'm connecting to comes from a third party and their product already had a hack. So using a jack on the N+ side seemed convenient and didn't require a special DIN-to-audio cable that I'd probably need to make myself. Once I get my project done, I hope that other people will use it, so I'm trying to minimize the need for things like non-standard cables.

Hi, I've built a shield for my N+ which includes a stereo audio jack. I have another device that also has a stereo audio jack over which it sends/receives 5V TTL data/commands. So, I connect the two using a short stereo audio cable. I want the N+ to be able to tell when the other device is connected and powered. So, I connected N+ D0 to D4. D0 and D1 will be used for serial, but I create an InputPort on D4 to monitor the voltage. When the other device is connected and powered, the InputPort returns true. GOOD. When the other device is connected and not powered, the InputPort returns false. GOOD. When the other device is not connected, I usually get true, which isn't what I want. BAD. In the third case, I think I was getting true because D0 and D4 were floating. So, I thought I'd try the Port.ResistorMode.Disabled option on D4's InputPort to see what would happen. I got an exception and now know that Netduino (or it's ARM) doesn't have the pull-down option. So, instead, I connected a 10K resistor from D4 to GND. The 10K pull-down seems to do what I want it to do. When the other device is not connected, the InputPort on D4 returns false (good). When the other device is connected, it works as before and the value depends on whether it's powered on or off (good). I used my DSO Nano to see if this had somehow messed up the serial signal, but it still looks good. If it's valid to use a pull-down in this situation, I think I'd want the highest resistance possible that gets the job done. The biggest I had on hand was 10K. Is that adequate? What sort of questions should I be asking myself that I'm not? It seems, to me, that the only difference with the 10K in place is that there would be .5 mA flowing to ground when the other device is connected and powered, and I don't imagine that would cause any problems. So, here's the sanity check part: Did I actually get this right? Thanks, in advance, for your input.

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.

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

• Sparkfun Listing
• Hardware / IO Overview
• Tutorial

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?