Fabien Royer

Thanks Asbjorn

 

Interesting about the cart / navigation issue you bumped into...

Can you email me @ fabien <at> nwazet <dot> com and let me know how we can improve things? I'd love your feedback.

 

Cheers,

-Fabien.

Hi,

 

We are now making our Nwazet Go Kits available to folks who already own a Netduino Go

 

Check out our Nwazet Go Pro Upgrade Kit for $199 and our Nwazet Go Tinker Upgrade Kit for $99

 

 

Cheers,

-Fabien.

Cyber Monday is almost upon us and we’re celebrating it with a sweet deal: get 15% off on all items in the nwazet store!

This offer starts on Monday November 26th 2012 at 00:00 AM and ends at 11:59 PM and applies to back-ordered items as well.

Happy Hacking!

Hi Chris,

Hi Fabien,

Thank you for digging into this further. Glad that a simple code change seems to get users back up and running.

If I remember correctly, the old firmware had a bug where it would send SPI traffic at either half or double the requested speed (depending on how you look at it). This was fixed in 4.2.1 via a bugfix check-in from the STM32 core. It may have been an issue with only one of the two buses (since they run on different peripheral clocks which could run at different speeds).

Can you check the actual throughput speed on your logic analyzer (both with the old firmware and with the new firmware) and verify that it is now correct? If the bugfix shifted the speed the wrong way, then we'll want to fix that. If it shifted it the right way, then the speed was incorrect before and I would recommend updating your code.

With GoBus 1.5, these sorts of issues go away. The I/O frames are taken care of by the framework...so you can focus on your application. This also enables your gear to be used on different transports.

One other thing: the STM32 chips run SPI at an even divisor. With the 168MHz MCU and internal 84MHz peripheral clock, that means that the SPI bus can run at 21MHz or 10.5MHz. So selecting 25MHz will generate a 21MHz SPI clock and selecting 16MHz will generate a 10.5MHz SPI clock.

Chris

I'm very familiar with the complexity of the ARM Cortex clock tree and I know how easy it is to mis-configure a peripheral's clock divider / pre-scaler.

Per your request, I have attached two Logic captures running on firmware 4.2.1, with the SPI bus (socket 5) configured at 10Mhz and 5Mhz respectively. As you can see, the SPI clock frequency is half of what it should be, which explains the regression.

This did not happen with firmware 4.2.0 where the actual SPI clock frequency matched the frequency requested by the application (give or take the rounding delta introduced by the configuration of the peripheral's divider / pre-scaler).

You should be able to reproduce my findings and do regression-testing on your own ARM-based modules (SD, Ethernet and ShieldBase), assuming that they are configured to use the SPI buses on the Go at frequencies above 16MHz.

Regarding GoBus: adaptive bus speed negotiation will be useful when dealing with runtime bandwidth issues. However this 4.2.1 firmware bug would impact GoBus just the same because it affects the configuration of the ARM Cortex clock tree for the SPI peripheral, systematically cutting the maximum frequency in half.

I certainly look forward to your native reference implementation of GoBus 1.x+.

While we wait for a firmware revision addressing this SPI frequency regression, we'll document the mitigation on our site.

-Fabien.

I just completed the investigation of the issue and here's what I have observed and my recommendations moving forward.

Context
The touch display SPI frames are fixed-size and 8192 bytes long.
The DAQ SPI frames are fixed-size and 576 bytes long.

By default, the SPI bus speed configured by the display driver is 25MHz
By default, the SPI bus speed configured by the DAQ driver is 16MHz

Here's what I have observed using 4.2.1 using the Touch Display module at the default 25 MHz speed:

First SPI request:

Sent: 0,0,3,0,7,86,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.[...]
Received: 128,91,110,119,97,97,97,97,97,97,97,97,97,97,97,97,97,97,122,101,116,46,100,105,115,112,46,49,46,48,54,0,[...]
Expected: 128,91,110,119,97,122,101,116,46,100,105,115,112,46,49,46,48,54,0,[...]

Second SPI request:

Sent: 0,0,3,0,7,86,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.[...]
Received: 0,[...]
Expected: 128,91,110,119,97,122,101,116,46,100,105,115,112,46,49,46,48,54,0,[...]

Subsequent SPI requests:

Sent: 0,0,3,0,7,86,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.[...]
Received: 0,[...]
Expected: 128,91,110,119,97,122,101,116,46,100,105,115,112,46,49,46,48,54,0,[...]

Observations
1. in the first request, the received buffer is being corrupted as seen with the repeated '97'
2. subsequent requests with the same query string only return '0', indefinitely.
3. the data corruption and where it occurs in the buffer is random.
4. on occasions, the data is not corrupted and the display responds...until the next data corruption occurs.
5. connecting the display to either side of the GoBus yields the same results

Resolution
1. Dropping the SPI bus speed to 10MHz eliminates data corruptions and allows the display to work again
2. Anyone who is affected by this issue in 4.2.1 should try initializing their Nwazet modules like so (replace Socketx with the proper socket):

canvas.Initialize(GoSockets.Socketx, 10000); // 10 MHz

or if the issue persists:

canvas.Initialize(GoSockets.Socketx, 5000); // 5 MHz

3. The same recommendation applies to the DAQ

Conclusion
With release 4.2.1, the Netduino Go firmware introduced a change which made SPI communication above 10MHz unstable.
The Nwazet display and DAQ modules use ARM Cortex chips capable of high SPI frequencies and are configured to maximize SPI throughput by default, well above 10 MHz.
Other STM8S-based modules are unaffected by the change introduced in 4.2.1 because they work at much lower frequencies, typically much lower than 5MHz.

Erik. I respectfully disagree with your assessment of what is and isn't out of spec or a so-called "poor implementation" of a spec that never was until recently. Breaking changes happen. In all industries. Merci.

Ulrik,

I felt that your reaction was offensive and unfair. I'm only interested in one thing: getting our users unblocked asap and for issues such as this one to never repeat themselves in the future.


Software releases generally follow a process which involves regression testing to mitigate potential user impact when changes are introduced. It's a reasonable thing to ask if regression-testing occurred because it is a standard best practice in our industry. No one should be offended by that and I am confused as to why anyone would perceive my question to be a wrongful attempt at keeping anyone waiting.


As far as moving on, I'd like that very much too.


-Fabien.

Ulrik,


Thank you for sharing your wisdom with us and showing us the error of our ways. You're clearly experienced in ways that I cannot fathom. Please, by all means, enlighten us all on how to resolve a software regression we have no control over...


-Fabien.

In this video, I demonstrate how to build a simple breakout board to connect a Go! module to an FTDI ‘USB to Serial’ breakout board for the purpose of updating the module’s firmware. The application used to download the firmware to the module is provided by ST Microelectronics. This method has been tested with ARM Cortex Mx and STM8S chips and works very reliably.

http://www.youtube.com/watch?v=jB3nFQso2Vs

Cheers,
-Fabien.

Links & References

Nwazet Source repository
Nwazet firmware files
Map file for the STM32F051x
Adafruit FTDI Friend + extras - v1.0
Adafruit USB FTDI cable - TTL-232R 3.3V
Sparkfun FTDI Basic Breakout - 3.3V
Sparkfun FTDI Cable 5V VCC-3.3V I/O
ST Flash Loader Demonstrator
Netduino Go! IDC Cable Breakout
Netduino GO! Hacking - Breaking out sockets

Hi,

I added an archive containing all the Nwazet Debug and Release assemblies needed to build projects without the source code: https://bitbucket.or...tAssemblies.zip

I don't have the time to build a nice installer for these assemblies but if someone would like to contribute that piece, that would be greatly appreciated

Cheers,
-Fabien.

Get serious building solutions on the .Net Micro Framework with this superb kit!

Be proud to showcase your work, presenting an image of quality from concept to finished product: your work deserves the polish of our black acrylic plates, laser-cut to exquisite precision around the best Netduino Go modules available today.


Composition
The Touch Screen will take complex user input and will display rich graphical feedback.
The 7-segment module will show essential numeric data that must be visible at a glance.
The Data Acquisition module will handle high volume inputs and outputs, serial communications, sensors, data storage and time.
The potentiometer is equipped with a heavy metal knob providing a very satisfying user feedback and blending perfectly with the look and feel of the kit.
A powerful Netduino Go, juiced by our USB power supply, orchestrates your show.

Prototyping
The black acrylic plates feature two main prototyping areas, ready to receive two breadboards (included in the kit). Additionally, a third mini breadboard can be placed between the DAQ module connectors. The kit includes two clear auto-adhesive breadboards, each providing two power rails and 400 connection points. The kit also includes forty 6" M/M premium jumper wires.

Value
If you wanted to put this exact kit together yourself, you'd have to spend over $300.
By carefully selecting our parts and designing for manufacturing, we were able to offer it for $250. Our hope is that you'll invest the $50 difference in building your next idea with us

For more details, check out the product page.

Cheers,
-Fabien.

Guys, You may not realize this, but taking pre-orders that remain in the pipeline for too long has a direct negative impact on our business and affects customer satisfaction: our customers generally buy other things along with the pre-ordered item(s). Once the pre-ordered item becomes available, the entire order ships. So, if the availability date of a pre-ordered item keeps being pushed back, with no foreseeable ETA, you can see how a large order backlog can build up quickly. In turn, our customers are unhappy because their hardware can't ship for weeks and we are unable to provide a specific ETA. Predictability and reliability are extremely important to us and we feel that we can't be successful without that. We made the decision to only carry products that are currently shipping and functional. Cheers, -Fabien.

Since you've implemented I2C via some sort of proxy (I don't know how this works since I don't have a DAQ, and won't cause I cant afford it) I hope that you'll give guidance to Chris and Secret Labs so as to help them make quick work of finishing the ShieldBase. Something which would greatly benefit the entire community. And would gain you a significant amount of respect from people like me, who have uses for the ShieldBase that the DAQ is unable to fulfill.

The DAQ schematics and the source are open for anyone to review and re-use provided that attribution is given: https://bitbucket.or...r/nwazet.go/src
What more do you need? How is this not of benefit to the community?

And would gain you a significant amount of respect from people like me, who have uses for the ShieldBase that the DAQ is unable to fulfill.

Like what?

I think that overall you'll sell more by showing us that you know how to build products

You're joking right? Do I need to provide links to the Go! modules that we have designed and shared with the community or would that be considered too much spam?

it feels like most of your recent posts have been about the DAQ, which is great, but I think that overall you'll sell more by showing us that you know how to build products, and that you are a good guy (good will can get you far in business).

I'm the 'bad guy' now? WTF is that even supposed to mean?

Build good modules and do everything I can to help the community grow. I accomplish the latter part primarily by helping users, via posting in threads, and never seeming to leave chat.

That's exactly what Nwazet does and we share everything that we produce with the community. We're trying to make an honest living from our work. What more do you want from us?

I also don't have any problem with you promoting your newest module, the DAQ, but there comes a point when you go from promoting it to spamming please keep that in mind

I very much appreciate the work that Mark put into his prototype temp / humidity sensor module and the video he made showing it. You certainly don't attack him for "spamming' and hijacking" your thread. But when I post something related to sensing temperature and humidity, I'm a thread spammer and a hijacker?

Fabien Royer, on 30 September 2012 - 02:22 PM, said:

<br style="background-color: rgb(250, 251, 252); ">Now, show me an alternative to the DAQ that allows connecting *any* kind of I2C sensors to a Netduino Go!
<br style="color: rgb(28, 40, 55); font-size: 12.727272033691406px; line-height: 19.09090805053711px; background-color: rgb(250, 251, 252); ">Done

Once again, this is misinformation: the Shield Base doesn't have I2C implemented even though the hardware exposes the SDA and SCL pins.

I've yet to lobby a single personal attack at you, and I'm not going to start now. I will ask that keep things respectful both here and elsewhere I know you have complaints about how certain things are going, or have gone, but the forums are not the place to air them.

You can't be serious. What was that Twitter post if not a personal, public attack?

Arron,

I'm not really sure $75 for a any number of small sensors is even remotely reasonable. I think individual $10-15 sensors are going to be better options for most users, both on price an ease of use. The IDC cable provides a much better user experience than just wires, after all I could do that with a breadboard for much cheaper.

I understand that you're still bitter about my questioning the value of your ProtoModule many months ago, that you took it personally and resent me for it, and that since then, you have taken great care of discrediting my contributions to the community any occasion you get. I know what to expect from you and that's ok.

However, if you had done the cost analysis instead of spreading misinformation, you'd know that:

• Selling the seven features offered by the DAQ as individual modules would cost well over $75
• I2C sensors, without the overhead of the supporting Go hardware, can cost anywhere between $10 to $20 by themselves depending on brand / function
• IDC cables cost at least $2 each

Now, show me an alternative to the DAQ that allows connecting *any* kind of I2C sensors to a Netduino Go!