36 replies to this topic

[ItsDan]

[CW2]

Awesome! What "higher-end" ST micro have you used? In case it is not compatible with STM8S003 (e.g. different register addresses, clock settings etc.), then the firmware from RGB LED module will not work correctly.

[ItsDan]

We're using a STM8S103K3T6C. For the RGB module all I seemed to have to do was locate the timer2 channels (1/2/3). There's no transitors involved here I'm just sinking the LEDs through the ST, I'm sure I'd get results closer to the real RGB module if I matched it more closely.

[Chris Walker]

Hey that's really cool, Dan. Feel free to post in this thread if you have questions about the firmware and schematics--to get your LEDs working identically to the module. As CW2 said, it should just be a matter of getting the right settings in place for how you've wired things up... Chris

[Stefan]

When can this be ordered and for which amount? So far I've got all Go! modules, you know the tagline of Pokémon? Gotta catch 'em all

[EricMeyer]

Aaron and Dan, Great job! You should make a little diffuser to put over your three LEDs, that would improve the effect quite a bit I would think. If they don't get hot, I would think the plastic from a gallon milk jug would work. (or something similiar) You would probably want to arrange them in a triangular configuration so the light from each blends with the others equally. Can't wait to buy one of the prototyping modules when it goes on sale. -Eric

[ItsDan]

Eric/Chris, Thanks for the suggestion, this was actually really just a test, no real intention of turning this into a module. Step 1 was ensuring we could replicate an existing module (more or less). Now that we know it can, I can try making something entirely new! The issue I did run into, and community member Matt Isenhower saw the same issue, was code compiled from the module source seems to send an extra byte during enumeration. If using the compiled .hex file it works just peachy. It doesn't LOOK like a code issue so it's perhaps something in the compiling process / different toolchain or something. I'm going to encourage Matt to post something about it now that he knows he's not the only one with the issue.

[CW2]

The issue I did run into, and community member Matt Isenhower saw the same issue, was code compiled from the module source seems to send an extra byte during enumeration.

Just out of curiosity, what 'module source' do you have?

[ItsDan]

When can this be ordered and for which amount?
So far I've got all Go! modules, you know the tagline of Pokémon? Gotta catch 'em all

We're still working out logistics on getting them made up and assembled and exploring all our options there. We obviously want to make them as affordable as we can so that the 'Go! Bus' isn't a barrier to entry on using the Netduino Go. We're currently waiting on quotes from some various suppliers and assembly houses. Hopefully we can state a price and timeline to being available in the next couple weeks.

[ItsDan]

Just out of curiosity, what 'module source' do you have?

I'll have to check when I get home but it's a zip with your CW2 handle on it and it's an IAR Workbench workspace from I want to say the tail end of March as timestamps on the files. I'll be more specific a bit later, obviously it would be great if that's all it was (out of date source).

[CW2]

I'll have to check when I get home but it's a zip with your CW2 handle on it and it's an IAR Workbench workspace from I want to say the tail end of March as timestamps on the files. I'll be more specific a bit later, obviously it would be great if that's all it was (out of date source).

Ok. Please note the reason module firmware source has not been released yet is because I am waiting for the go!bus protocol specification to be finalized, to avoid exactly this kind of issues.

[Arron Chapman]

Ok. Please note the reason module firmware source has not been released yet is because I am waiting for the go!bus protocol specification to be finalized, to avoid exactly this kind of issues.

Yeah, we're certainly aware of that but we bugged Chris into giving us the firmware for experimenting, as neither Dan nor I have any experience working this close to the hardware (.NetMF is the closest for me).

[ItsDan]

So I rewired the module a bit to match the original RGB LED module more closely, far far better results this time.

[ItsDan]

If anyone is still following the conversation, the Netduino Go! Protomodule should be available for sale by this time next month (around the middle of June) or possibly sooner. We'll have a final price point before then and may offer a discount on pre-orders. I or Arron will update this thread once we have more details.

[Arron Chapman]

Yay!

Protomodules are available for pre-order order and should be shipping the first week of June! Get yours now

[Chris Seto]

Nice! Awesome to see a good looking standard spaced breakout for general purpose development.

[Fabien Royer]

@Arron / Dan, Congrats! What type of software library supports this prototyping module (not talking about ST's StdPeriph stuff)? Cheers, -Fabien.

[Mike Hole]

Nice one This will come assembled right?

[ItsDan]

Fabien we've deployed code to the module using both ST's Visual Develop/Programmer tools and IAR, and the final revision of the board has a SWIM port for deployment/debugging. The initial ones will probably ship w/o any firmware, that or a basic demo so people can verify they work (plus we need to verify they work obviously). When the standard module firmware is released, we'll use that. Mike, yes they will be assembled, in fact the difficulty of soldering the fine pitch microcontroller and gobus and such are part of why we made this. The only thing some users will want to do is add the female headers and/or mini breadboard, we didn't want to assume everyone would want those, although if people do perhaps we could add it as a cheap upgrade. Those are all .1" pitch through hole components so a cheap iron is more than enough to get that done. Arron's VariableLabs store should by the time we start shipping protomodules also sell appropriate headers, the breadboards, as well as some of the raw components such as the go bus connectors.

[Fabien Royer]

@Dan

I'm always looking for ways to save myself time during module development and the ProtoModule seems to have potential for that.

However, I'm trying to understand the value proposition of the ProtoModule over the full-featured $8 STM8Discovery board made by ST, which comes with STLinkv1 and is accessible over USB for programming and debugging the chip.

The STM8Discovery board only requires soldering a Go! connector / pin headers to get going, requiring about the same soldering skill level as the ProtoModule.

I may be missing something, but in the case of the ProtoModule, it seems that the user would also have to purchase STLinkv2 separately for programming / debugging or at least would need to provide a USB -> Serial cable (i.e. FTDI-type of solution) to upload firmware to it?

It would be great if you would provide specific details on the requirements for working with the ProtoModule, end-to-end.

As far as the "Standard Module Firmware" goes: what specific features will it provide and when will it be released?

Thanks,

Cheers,
-Fabien.