Matt Isenhower

Great stuff Chris!

chaining adds $1.00-$2.00+ to the component cost of a module. On average, it probably adds $3-$5 to the end user cost.

Just to expand on this point a bit, I imagine the downstream socket would need to implement the same features as those present on each socket on the mainboard, including:

• A socket connector (of course )
• Two P-channel MOSFETs to switch the 3.3V/5V power lines
• A gate driver to control the two power MOSFETs from the 3.3V microcontroller (e.g., an NPN transistor + base resistor + 5V pullup resistor)
• An LED (and resistor, and possibly a transistor to drive it) next to the socket connector to indicate status

Then it would just be a matter of wiring up everything to the microcontroller. Is that all correct?

Matt

Hey everyone, Just a quick update -- I'm expecting to receive the production boards for this module early next week. After that, they'll just need to be assembled and then they should be ready to ship out to customers starting early/mid July. Also, I'm now accepting pre-orders for this module on my website: http://komodex.com/l...segment-display Let me know if you have any questions! Matt

As Arron and Dan have said, there will be a "standard firmware" for the STM8 (and a few other microcontrollers) in the coming months. Currently, the protocol between the Netduino Go mainboard and modules like the RGB LED and Potentiometer is fairly simple: The mainboard sends out an enumeration request to the module, the module responds with its unique ID (a 128-bit GUID), and if the GUID matches the one the mainboard is looking for, the port is opened and further communication with the module can begin. The "further communication" part is the part that is less defined at the moment -- both the RGB LED and Potentiometer modules are using very simple SPI messages to send and receive data, where each message is 18 bytes long (and the 18th byte is the CRC8 value for the message).

(I haven't mentioned the Button module here because it doesn't actually have a microcontroller -- it uses a simple shift register for identification and uses the GPIO pin on the Go bus to indicate the button state. Also, the shield base currently uses UART for communication but it will soon be changing over to SPI. All microcontroller-based modules made for the Go bus will ultimately use SPI for communication.)

When the standard firmware is released, it will handle all of the actual SPI communication between the Go mainboard and modules. This firmware will provide several standard ways to send and receive data from your module and will, to some degree, allow you to control its behavior from the mainboard. You will still be able to (and in many cases, need to) write your own STM8 firmware based on the standard firmware, but the communication layer between your module and the mainboard will be managed in a standard way. (Using the standard firmware or a custom firmware based on it will actually be a requirement for modules to be fully GO!Bus compliant and use the "G" logo.)

If you're interested in writing your own firmware at this point, I would strongly suggest getting a logic analyzer so you can analyze the protocol used in the existing modules and debug the protocol you implement on your own. The Saleae Logic is an excellent choice, and I really wouldn't consider writing your own firmware without this or a similar device.

Unfortunately, we do not have the RGB LED or Potentiometer module firmware to give out at this point. Chris may be able to help you further there, but it is definitely possible to write your own firmware with just the information you can gather from a logic analyzer. (As an example, the firmware on my Seven Segment Display Module is completely custom.)

If you have previous microcontroller experience, all of this will be a bit easier, so you might want to start out with some smaller projects first. Forum member Nevyn has made several posts on his blog at http://blog.mark-stevens.co.uk/ about working with the STM8. CW2 has put a few tips on the wiki here: http://wiki.netduino...evelopment.ashx and there is more information about the electrical specs here: http://wiki.netduino...ders-Guide.ashx

While ultimately a lot of the communication methods will change, I definitely wouldn't say it's a waste of time to start learning how it works now as it will give you a head start for making all the pieces work together later. The standard firmware will make communication with the Go much easier, but it won't eliminate the need to write at least some custom STM8 code for a lot of modules.

Let us know if you have any other questions!

Hi Kevin, I think you have the right idea with setting other interrupts to a lower priority -- this is what I'm doing on my seven segment display module to handle the display multiplexing from a timer. The problem is that you need to set the priority level of the other interrupts you're using rather than the priority of the SPI interrupt. All interrupts start out at the highest priority level, 3. As soon as one interrupt is set to a lower priority level, the interrupt handling is switched to nested mode and you can start getting interrupts during other interrupt service routines. Try setting your other interrupt(s) to a lower priority to see if that fixes the problem. In my code, I'm using level 2 (which is actually set with 0 and 0 written to the priority level bits) for the multiplexing timer and that seems to work perfectly. Just leave the SPI interrupt vector at its default level 3 and it should take priority over everything else. If you have a logic analyzer and a few extra pins, you can actually visualize when your interrupts are being serviced by setting a different output pin high when each interrupt is being handled and setting it low when it's done. That will let you verify that your interrupts are being nested properly without much interference (unlike setting breakpoints, etc.). Oh -- one other thing. If you are connected with the debugger, you can actually view and modify the peripheral registers while the program is executing to see how its behavior changes. In IAR (and I think also STVD) you can actually change the content of these registers without pausing program execution, so you can quickly see how changing the different priority levels (or any other setting) effects execution in real time. Let me know how it goes! Matt

Hi everyone,

I just received some prototype boards for my Seven Segment Display Module. Here's what the assembled board looks like:



These prototype boards are green, but the final production boards will be black. Other than that, everything else should be pretty much the same. Black production boards are in!

I also made a quick video showing how the display works:

http://www.youtube.com/watch?v=0s7QWRz9_rM

These should be available for purchase within the next few weeks. I will be accepting preorders soon, and I'll update this thread as soon as the store is online.

Now shipping!

Let me know if you have any questions!

Matt

Hi Kevin,

Are you enabling interrupts? If you are using the ST standard peripheral libraries, you can enable interrupts with:

enableInterrupts();

What are you looking to do with Timer 2? If you want to use it for PWM output you don't actually need to use (or enable) interrupts. Here's a PWM example using the ST libraries:

    /* Time base configuration */
    TIM2_TimeBaseInit(TIM2_PRESCALER_1, 0x03FF);
    
    /* PWM1 Mode configuration: Channel1 */ 
    TIM2_OC1Init(TIM2_OCMODE_PWM1, TIM2_OUTPUTSTATE_ENABLE, 125, TIM2_OCPOLARITY_HIGH);
    TIM2_OC1PreloadConfig(ENABLE);
    TIM2_ARRPreloadConfig(ENABLE);
    
    /* TIM2 enable counter */
    TIM2_Cmd(ENABLE);

Matt

Hi Kevin, This wiki page details most of the hardware/electrical requirements for STM8S-based modules: http://wiki.netduino...ders-Guide.ashx Pin 4 should be connected to SWIM and pin 5 should be connected to NRST. The wiki pages for the potentiometer and RGB LED modules have Eagle schematics attached in the top right corner, and you can pretty much follow the schematics for those modules as a base for custom modules. Matt

Hi everyone,

If you're making a module for the Netduino Go, you'll probably need to distribute some driver libraries to go along with it. Providing a module driver installer is a great way to make it extremely easy for your users to get started with your module.

NSIS is a popular free and open source Windows installation system. NSIS is script-based, and allows you to use relatively simple scripts to define the behavior of your installer. I have created an NSIS script that can be used as a starting point for Netduino Go module driver installers.

This script copies all the necessary files for your module to a directory within the Program Files directory. It also creates the registry keys necessary for your assemblies to appear within Visual Studio's "Add Reference" window for .NET Micro Framework projects.

Additionally, an uninstaller is created and users will be able to uninstall your drivers through the "Add/Remove Programs" control panel.

This script generates a single installer executable that works on both 32 and 64-bit systems. It has been tested on Windows XP, Vista, and 7.

This script is distributed under the Apache License 2.0.

To use this script:

• Install the latest version of NSIS.
• Download the script (attached to this post, see below for link).
• Copy the script to your library's solution folder. I recommend creating an "Installer" directory within your solution folder and copying the script files there. This keeps all the files related to the installer (including any custom icons or other plugins, etc.) contained and separate from the rest of your code.
• Update the settings in the first part of Installer.nsi (see below for more details). The .nsi and .nsh files are just plain text files that can be edited with Notepad or any other text editor, but several NSIS development environments are available. I like HM NIS Edit.

There are a few important settings you should update in Installer.nsi:

• Your company name, product name, website, etc.
• The installer version number. You can use any version number you'd like, but it must be in X.X.X.X format.
• If you would like to include a EULA page in the installer, uncomment the EULA Filename line and specify a file that contains your EULA text. This can be either a plain or rich text file.
• The .NET Micro Framework version you are targeting (e.g., v4.2). This is used for the installation path (to keep different .NETMF versions separate) and for the registry keys that make your assembly appear in the "Add Reference" dialog.
• A list of all assemblies you'd like to include in the installer. For each assembly, specify the target name (i.e., the assembly filename without the .dll extension) and the build output directory. You can include multiple assemblies if necessary, and instructions for doing so are provided within the configuration section of Installer.nsi.

There are a few other settings as well:

• The installer output filename. By default this will include the full product name and version.
• Custom installer/uninstaller icons.
• A link to be shown on the installer's Finish page, typically used as a link for "Getting Started" documentation.
• Default installation directory, defaults to "Company Name\Product Name" (within the Program Files directory).

After updating the script with your settings, you should be able to compile the script to generate your installer. If you are using one of the NSIS IDEs, there should be a menu item or button within the program to compile the script. Otherwise, you can compile it from the command line:

"%PROGRAMFILES(X86)%\NSIS\MakeNSIS.exe" Installer.nsi

I have included a batch file called "CompileInstaller.bat" to make this a little easier.

Please let me know if you find this useful or if you have any questions

Matt