Matt Isenhower

Hey everyone,

I've just posted an update to my MicroTweet Twitter API library. Some of you may remember the first version of this library from a few years ago -- here's the original forum thread. This library can be used to post and retrieve tweets from NETMF devices.

MicroTweet 2 is available on GitHub here: https://github.com/m...ower/MicroTweet
I also have a blog post about it here: http://mattisenhower...6/microtweet-2/

Twitter now requires SSL to access their API, so the only Netduino model this library currently works with is the Netduino 3 Wi-Fi.

Enjoy!

Matt

And I hope the microusb connector is throughhole for the attachment?, so they don't tear off ?

It is, and it's soldered in, too (like the NP2, unlike the Netduino Go).

Here's a photo of the bottom of mine -- you can also see the new silkscreen and mini JTAG connector pads, which have been moved to the bottom of the board (and are now surface mount instead of through-hole).

P.S. Even the MicroUSB jack is new.  We obsessed over finding a jack which gave users a satisfying "click".  And then obsessed over a lot of other seemingly-insignificant-but-important things.  This board is over-engineered, as usual; we admit it.

Don't forget about the new mini button too

First off, congratulations to Chris and his team on the release of Netduino 3 Wi-Fi! I've been testing this board for the past few weeks and it really is awesome. I posted some initial thoughts on my blog here.

Being able to use GoBus on a board with network connectivity is huge. This is something I've wanted to have since the Netduino Go was first released I've included an example project in my blog post above where I pull weather data from wunderground.com's API and display it on a seven segment display module. It's remarkable how easy it is to implement something like this with NETMF and GoBus.

When I first received my N3W it was running very early firmware that didn't include the GoBus library. This gave me a chance to think about an alternate approach for GoBus implementation that would allow for more flexibility when using Go modules and their drivers. I ended up implementing this idea in an experimental library and had a lot of fun trying out some of the new possibilities it enabled. I wrote about this in a separate blog post here: GoBus: An Alternate Approach.

Anyway, congratulations again to Chris and his team on another awesome Netduino! I'm looking forward to see what everyone does with their new boards

Matt

is even the pinheaders presoldered?, would be no problem soldering those, I guess having them sticking out under would be better than on the top (for breadboard), but I guess the standing one would be the solution then?

They will be delivered exactly as shown in the pictures, unless you request a different configuration. I can also just include the pin headers loose in the bag if you'd prefer to solder them on yourself.

Also, if you'd like to have your order shipped via First Class Mail, just make a note in the order comments field and I will adjust the shipping cost before charging your credit card. I will confirm the final amount with you before making the charge.

Thanks!
Matt

Hi neslekkim,

No more of these yet?

There were some delays on one of the parts for this module, but everything is in place now and they have been sent off for assembly. They should be ready soon!

Btw, pcb's like this, do they cut them for you like that?, and drill mounting holes etc?
I tried to find out if osh or seeed suported some panelising of board, but did not look like that, but yours some like it?

All of the design parameters, including the drill locations and board outline (which becomes the final shape of the board), are specified in the PCB layout file. For this board, I rounded the top corners of the outline and placed the mounting holes in the appropriate places, and the PCBs came back exactly as specified.

These prototypes were purchased from OSH Park, which batches several different designs together on a larger panel. OSH Park uses a custom placement script combined with Gerbmerge to actually merge all the PCB gerbers together onto a large panel (source). Here's another blog post about Gerbmerge.

OSH Park then sends the panel design (including routing instructions) to their fabrication house, who in turn uses the design files to program their CNC drills and other equipment. When I get the boards back from OSH Park, they've already been drilled to the right shape and size and they arrive (mostly) broken apart from each other.

I think most PCB fabrication houses can handle non-rectangular board shapes, just as long as you specify everything correctly in your PCB layout file. You don't usually need to worry about specifying panelization layout unless you need to receive panels back (for example, to send to a board assembly house). If you just need the loose boards, then you can usually just send the single PCB layout and let the fabrication house take care of the rest.

Matt

Hi Fabien,

A while back I posted an NSIS Installer for Netduino Go Module Drivers template. This is what I use for my module driver assembly installer, and it handles adding all the necessary values to the registry, generating an uninstaller, etc.

It should be pretty easy to customize the script to your needs. Also, if you want to see the actual script used in my drivers installer, that's included in the source code and examples package on http://komodex.com/labs/downloads

Let me know if you have any questions!

Matt

Simpler modules (like an RGB LED) will communicate at a slower speed

For STM8 modules, the fastest I've been able to go (while still actually handling and responding to messages, etc.) is about 650 kHz. Currently all of the STM8-based modules run at 325 kHz.

The final part of the video shows the reading from the DHT22 shown on the Komodex Labs 4 digit seven segment display.

Nice video, Mark, thanks for sharing!

By the way, in the Module Drivers Source Code and Examples package, I include an extension method called SetTemperatureDisplay (in ModuleTestApp/SevenSegmentDisplayUtilities.cs). This extension method uses the apostrophe as a "degrees" symbol and allows you to specify a "C" or "F" to be displayed as the last digit.

Looks like there's a breakout module down there on your breadboard as well Cool stuff!

Matt

To help build and debug the new GoBus 1.5 protocol, I have created a pair of protocol analyzer plugins for use with the Saleae Logic software. There are two versions of the analyzer: one for GoBus over asynchronous serial, and one for GoBus over SPI.

After installing the new Netduino Go firmware and Shield Base firmware released earlier today, you can use the serial analyzer to view the protocol between the Netduino Go mainboard and the Shield Base module. Using a breakout board (for example, the GoBus Breakout Module), simply connect your logic analyzer to GoBus pins 4, 5, and GND and you'll be able to capture and view the serial GoBus traffic between the module and the mainboard. (On the GoBus Breakout Module pins 4 and 5 are labeled with the STM8 functions SWIM and NRST.)

Download: Beta 1
Includes compiled files for Windows and Mac OS X, as well as the source code for both analyzers.

Here's what the analyzer looks like:

When you zoom in you can see a few more details about each byte:

Here's what the SPI analyzer looks like. At the moment I only have sample ("fake") data to display but it should work correctly with actual GoBus SPI traffic when that is available


Installation:

Windows:

Copy the following files:

• GoBusAsyncSerial.dll
• GoBusSPI.dll

to the Logic Analyzers directory: C:\Program Files\Saleae LLC\Analyzers

If the GoBus analyzers don't show up within the Logic software, make sure you have the Microsoft Visual C++ 2010 Redistributable Package installed. This can be downloaded from: http://www.microsoft...ls.aspx?id=5555

Mac OS X

Copy the following files:

• libGoBusAsyncSerial.dylib
• libGoBusSPI.dylib

to the Logic Analyzers directory: /Applications/Logic.app/Contents/Resources/Analyzers

Right click Logic.app and select "Show Package Contents" to access the "Contents" folder.

Limitations:

• The analyzers currently only support CRC8 frames. This is due, in part, to CRC8/16 being a transport setting that is not indicated within each packet. This will be fixed in the future, either from a change in the protocol or through a setting in the analyzer.
• The SPI analyzer currently uses the Enable line to determine frame length (and therefore where the CRC byte is located) as well as where each new frame begins. This could cause issues if the Enable line is not cycled between frames.
• For both analyzers, the CRC value is only displayed and not actually verified by the analyzer. The CRC value in simulated data is not accurate and will always be set to 0xFF.
• I haven't worked on the export function yet, these features are purely for displaying GoBus traffic at the moment. That will be fixed later

Enjoy, and let me know what you think!

Matt

Hi neslekkim,

The komodex one would be nice, but where to buy?

I should have these back in stock in a few weeks. I'll make a post in the forums when they're available.

Matt

Hi Jason,

Welcome to the Netduino community!

The NetduinoGo.Button class can only be used with the Button module. This class inherits from the GoModule class, which is the base class for all GoBus module drivers. "First available button" here actually refers to the first uninitialized button module connected to the GoBus sockets and doesn't include the onboard button.

The onboard button is treated as a standard GPIO pin, similar to the I/O pins on the Netduino and Netduino Plus. Netduino Go only makes two standard GPIO pins available, including the onboard button and the power LED (which can be turned on or off by initializing it in an OutputPort).

Here's a modified version of your program that accepts input from either the onboard button or a button module (if one is attached):

static int controlledColor;

public static void Main()
{
    byte redValue = 0;
    byte greenValue = 0;
    byte blueValue = 0;

    var led = new RgbLed();

    NetduinoGo.Button button;
    try
    {
        button = new NetduinoGo.Button();
        button.ButtonPressed += new NetduinoGo.Button.ButtonEventHandler(button_ButtonPressed);
    }
    catch { }

    var onboardButton = new InterruptPort(Pins.Button, true, Port.ResistorMode.PullDown, Port.InterruptMode.InterruptEdgeHigh);
    onboardButton.OnInterrupt += new NativeEventHandler(onboardButton_OnInterrupt);

    controlledColor = 0;
    var pot = new Potentiometer();

    while (true)
    {
        switch (controlledColor)
        {
            case 0:
                redValue = (byte)(255 * pot.GetValue());
                break;
            case 1:
                greenValue = (byte)(255 * pot.GetValue());
                break;
            case 2:
                blueValue = (byte)(255 * pot.GetValue());
                break;
        }

        led.SetColor(redValue, greenValue, blueValue);
    }

}

static void NextColor()
{
    // Change The LED Flag that tells the program which color to be controlling
    controlledColor++;
    if (controlledColor > 2)
        controlledColor = 0;
}

static void button_ButtonPressed(object sender, bool isPressed)
{
    NextColor();
}

static void onboardButton_OnInterrupt(uint data1, uint data2, DateTime time)
{
    NextColor();
}

Hope that helps Let me know if you have any other questions.

Matt

Edit: Just realized I talked with you in chat about this earlier, I think your post got delayed because of the spam filter... I'll leave the answer though just in case anyone else has the same problem

Just a quick informal poll -- how many people are interested in the RGB backlight vs. a single color backlight (e.g., the white-on-blue display in the original post)? I'm planning on offering both styles but I'd just like to get an idea of how many people are interested in each kind. Thanks!

Nicely done. Is it setup like an LCD backpack so we can easily connect our own choice of LCD? Say a 4x20 RGB Backlit?

I am planning on selling this module fully assembled, with an LCD attached so no soldering is required. There will likely be several LCDs to choose from (e.g., positive RGB, negative RGB, and white-on-blue).

If you (or anyone else) would like to purchase the module without an LCD, please let me know once the modules are available and I'll be happy to send you one with a discount. If there's enough demand I might make that option available on the store as well.

Regarding other sizes -- this shouldn't be a problem, but I will need to do some testing to be sure. The PCB has been sized around a standard 16x2 display, but it should also work with other HD44780 displays as long as they have the same pin configuration. The display will be a bit bigger than the module, but that shouldn't cause too much trouble unless it hangs over the module connector on the left. You may need to make some changes to the module drivers, but I'll try to make sure the module firmware works for either situation.

Regarding other RGB displays -- the board is currently designed around an RGB display that has a common cathode line. I think the only 20x4 RGB LCD I've seen is the one sold at Adafruit, and that has a common anode backlight so it wouldn't work with this module in its current configuration.

By the way, I did some testing with Adafruit's 16x2 RGB LCDs (which are also common anode) but I found a few problems with them. First, they appeared to be STN displays (similar to the one pictured in the original post) and had a blue tint in the dark areas rather than the deep black you get with FSTN displays. Also, while they feature integrated backlight resistors, the largest resistor was on the common anode line. The RGB cathode lines each had 10 ohm resistors, but the anode line had a 100 ohm resistor. As a result, I wasn't able to turn all three colors on at once and mixing colors turned out to be pretty difficult as well.

The datasheet for their 20x4 RGB display says it has an FSTN LCD, so it should be better in that regard but I'm not sure what its resistor configuration is. Regardless, since it's common anode it wouldn't work with this module but I might be able to make some changes to accommodate that.

Hey everyone,

Just a quick preview of the next go!bus module I'm working on -- a character LCD!



This module works with most standard HD44780-compatible character LCDs. Above is a picture of a prototype with a white-on-blue LCD, and here's a picture of the module connected to the mainboard:



The small component near the module connector is a potentiometer for setting the display contrast.

This module will also support LCDs with RGB backlights. With RGB backlit LCDs you will be able to set the color and brightness of the backlight, similar to how you set the color of the RGB LED module.

Quick preview videos of the RGB displays: dark-on-light and light-on-dark.

More information coming soon! It will be at least another month before this module is available for sale, but I'll post more information in this thread when it becomes available

Hi everyone,

Just wanted to show a few pictures of a new GoBus module I developed recently, the GoBus Breakout Module:



This module is very similar to some of the existing Gadgeteer breakout modules, but it is specifically designed for use with go!bus modules and has a few extra features to make it easier to program and debug STM8-based modules.

The biggest feature for module developers is the SWIM connector at the top of the module. When the programming mode switch is pushed to the right, pins 4 and 5 are disconnected from the Netduino Go mainboard and instead connected to this SWIM connector. This allows you to program and debug modules while they are still connected to the mainboard without affecting other modules on the same go!bus channel.

More information is available in this blog post over on the Komodex Blog.

Please let me know if you have any questions!

Matt