Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

Fabien Royer's Content

There have been 203 items by Fabien Royer (Search limited from 29-March 23)


By content type

See this member's


Sort by                Order  

#46716 Trouble writing to SD card on Nwazet DAQ

Posted by Fabien Royer on 05 March 2013 - 10:33 PM in Netduino Go

Hi Seattle Food Geek,

 

I just notice that the order of the calls is incorrect:

 

 


    [*][color=rgb(0,0,0);]daq[/color][color=rgb(102,102,0);].[/color][color=rgb(102,0,102);]FatFs[/color][color=rgb(102,102,0);].[/color][color=rgb(102,0,102);]CloseFile[/color][color=rgb(102,102,0);]([/color][color=rgb(0,0,0);]fileId[/color][color=rgb(102,102,0);]);[/color]
    [*][color=rgb(102,0,102);]Debug[/color][color=rgb(102,102,0);].[/color][color=rgb(102,0,102);]Print[/color][color=rgb(102,102,0);]([/color][color=rgb(0,136,0);]"file closed"[/color][color=rgb(102,102,0);]);[/color]
    [*][color=rgb(0,0,0);]daq[/color][color=rgb(102,102,0);].[/color][color=rgb(102,0,102);]FatFs[/color][color=rgb(102,102,0);].[/color][color=rgb(102,0,102);]SyncFile[/color][color=rgb(102,102,0);]([/color][color=rgb(0,0,0);]fileId[/color][color=rgb(102,102,0);]);[/color]
    [/list]

    Closing the file invalidates the fileId, and it should not be used afterward.

    [color=rgb(102,102,0);font-size:14px;]Just call SyncFile() before closing the file and things should be OK :)[/color]

     

    I hope this helps.

     

    -Fabien.




#46715 GetSocketsByUniqueId - not working?

Posted by Fabien Royer on 05 March 2013 - 10:25 PM in Netduino Go

[font="arial, sans-serif;font-size:12.800000190734863px;"]Hi Asbjorn,[/font]

 
I have a DAQ demo (https://bitbucket.or...Demo?at=default) in the repository that works just fine with the following modules:
  • DAQ w/ SD card
  • Touch Display
  • SL Potentiometer
  • Komodex 7-segment display
  • 3x I2C sensors
  • 1x XBee radio
It's using .Net MF 4.2.2 or something like that, which still requires dropping the speed on the SPI bus. It's been extremely stable and has been running for months now. I don't use any module discovery features.
 
In my experience, sticking with the basics of .Net MF is the only reliable way to go with Netduino Go.
 
Cheers,
-Fabien.



#46224 How to upgrade to the .NET Micro Framework v4.3 SDK

Posted by Fabien Royer on 25 February 2013 - 06:26 PM in Beta Firmware and Drivers

Chris,

 

"[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;font-size:14px;]I'm guessing that 10.5 mbps was too fast for the module. That's a lot of data for a 48MHz microcontroller to handle that's also updating a display...so 5.25 mbps seems totally reasonable"[/color]

 

[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;font-size:14px;]You guessed wrong.[/color]

 

  • [color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;font-size:14px;]The Touch Display module runs on a [/color]STM32F205RET6 [color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;font-size:14px;]at 120 Mhz.[/color]
  • [color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;font-size:14px;]The DAQ module runs on a [/color]STM32F051R8T6 at 48 MHz.

In both cases, the processing work that they perform is independent of the SPI communication throughput because it's buffered and asynchronous. A simple examination of our SPI over DMA source code would have avoid a misleading statement.

 

For the record, throughput has never been an issue with our modules until GoBus introduced SPI handling changes. 




#44544 All Nwazet modules for Netduino Go on sale

Posted by Fabien Royer on 29 January 2013 - 09:03 PM in Netduino Go

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.




#44534 All Nwazet modules for Netduino Go on sale

Posted by Fabien Royer on 29 January 2013 - 08:41 PM in Netduino Go

Hi,

 

We're happy to let you know that we're having a sale on all Nwazet Netduino Go modules:

 

 

Nwazet Touch Display: $54 (was $69.99)
Nwazet Data Acquisition module: $52 (was $75)
Nwazet Power Supply module: $13 (was $14.99)
Nwazet Relay module: $14 (was $16.60)
 
Enjoy while supplies last :)
 
Cheers,
-Fabien.
 



#42284 Already own a Netduino Go? Check out the Nwazet Go Upgrade Kits

Posted by Fabien Royer on 27 December 2012 - 08:53 PM in Netduino Go

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

 

Posted Image

 

Cheers,

-Fabien.




#40250 Cyber Monday @ Nwazet: 15% OFF everything

Posted by Fabien Royer on 26 November 2012 - 07:02 PM in Netduino Go

Yup, this is Pacific time :) Cheers, -Fabien



#39964 Cyber Monday @ Nwazet: 15% OFF everything

Posted by Fabien Royer on 22 November 2012 - 08:13 PM in Netduino Go

Posted Image

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!



#39787 Shieldbase "Retired"?

Posted by Fabien Royer on 21 November 2012 - 03:45 AM in Netduino Go

I don't have anything to add to what Chris wrote and I believe that we have beaten the "DAQ vs. ShieldBase" horse to death already. Sorry Ulrik, this isn't going to be entertaining to watch after all ;) -Fabien.



#39359 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 14 November 2012 - 06:17 PM in Netduino Go

In this case, it would mean to the Netduino is rendering a bitmap, and then sends it to the module, which updates it immediately?


Yes, same method used today for rendering bitmaps. Just keep in mind that bitmaps get quite large at 16-bit / pixel and will eat up your flash / RAM in a hurry ;)

For research purpose only: If need, would it be possible to order a batch of screens with custom logos?


Yup, it would be possible. You should email me at contact <at> nwazet <dot> com to discuss the details.

Cheers,
-Fabien.



#39357 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 14 November 2012 - 05:46 PM in Netduino Go

Ah that wasn't exactly what I meant.. it's the yellow screen when it initializes i was referring to ;)

Sorry, I misunderstood you. It can be replaced by recompiling the module's firmware with your own. You can do it using a variety of tool chains on Windows, Linux, Mac. I use IAR WorkBench but OpenOCD works too. You can then reflash the module serially using ST's own Windows utilities or if you're under Linux, a bunch of STLinkv2 alternatives such as http://code.google.com/p/qstlink2/ among others.

Ah I see.. and this is the case for all Go Modules, right?


Yes, the SPI latency aspect is unavoidable with Go modules: it's akin to sending a network packet from one computer to another. In the case of the touch display, the packet size is fixed at 8KB to accommodate sending bitmaps relatively quickly. Depending on your main scenario, you could change the default 8KB packet size to something smaller to reduce latency (that requires a firmware change too btw). What happens on the module itself with that packet is yet another story...

A good strategy to help reduce flickering during screen updates is to only update the zones of the screen that need to be refreshed. That will reduce the amount of data that needs to be processed each time.

I hope this helps.

Cheers,
-Fabien.



#39347 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 14 November 2012 - 05:09 PM in Netduino Go

Hi Nicky, No worries :) About your questions: a. Yes, it can be replaced with the same touchscreen model. If you look at the display carefully, it's held in a metal cradle from which it can be extracted to swap a new one. It's also possible to replace the touchscreen with a regular display (same model but no touchscreen) b. Yes, it's normal for two reasons: there's SPI latency between the Netduino Go and the Touch Display module, then the set of commands sent to the display is interpreted and bit-banged onto the IC display driver bus (the STM32F205 does not have an FSMC peripheral, so bit-banging is the only option). This results in some flickering when refreshing the screen. I hope this makes sense :) Cheers, -Fabien.



#39278 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 13 November 2012 - 08:45 PM in Netduino Go

Hi Nicky.

The VirtualCanvas class interfacing with the Touch Display hardware abstracts away the communication details, which is a good thing. However, the communication is still taking place over shared hardware resources: in this case, an SPI channel and an interrupt port for signaling readiness / command completion. If multiple execution threads need to access the shared hardware resources, they must be synchronized and serialized. Various methods can be used to synchronize threads on the .Net MF such as the lock(object) {} statement, event objects such as ManualResetEvent() and implementing a work queue to serialize hardware access requests. To simplify the design, improve application performance and reliability, I'd recommend dedicating a single thread to the management of the display and handling touch events.

What I'm describing here is true of any shared resource and in the context of a microcontroller, where there's no OS to queue I/O requests of behalf of application threads, it's up to the developer to orchestrate the show.

I hope this helps clarifying things a bit.

Cheers,
-Fabien.



#39204 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 12 November 2012 - 08:04 PM in Netduino Go

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.

Attached Thumbnails

  • 4.2.1-SPI-speed-bug-5mhz.jpg

Attached Files




#39124 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 12 November 2012 - 05:25 AM in Netduino Go

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.



#39094 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 12 November 2012 - 01:36 AM in Netduino Go

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.



#39087 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 12 November 2012 - 01:02 AM in Netduino Go

Chris,

So, first steps first: From what you posted, the blocking point in the current driver appears to be during enumeration. If you copy and paste the sample enumeration code from the RGB LED module driver into the [nwazet Touch Display driver, does that fix the issue?


As a first step, I'd prefer installing the 4.2.1 firmware on a stock Netduino Go and compare what I see on the wire against a 4.2.0 trace, without changing anything else.

A few questions:
Can the 4.2.0 SDK live side-by-side with the 4.2.1 SDK?
Is it possible to deploy and run existing 4.2.0 assemblies / code to a Netduino Go running the 4.2.1 firmware and expect things to work or is "recompiling the World" first a requirement?

-Fabien.



#39086 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 12 November 2012 - 12:52 AM in Netduino Go

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.



#39065 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 11 November 2012 - 11:13 PM in Netduino Go

Chris,

A straight up SPI transaction, which has always worked, as you know


Ah, that could cause troubles. Please grab a copy of the RGB LED, Potentiometer, or Piezo Buzzer module source code from the Wiki for an example of the standard enumeration method for GoBus. We'll be happy to help you update your driver if you'd like.



Can you please clarify how a straight up SPI transaction is suddenly an issue in a system that is purely SPI-based?

What has changed between 4.2.0 and 4.2.1 that affects SPI in the context of the Go?

Why are GoBus 1.5 changes allowed to break GoBus 1.0 devices, when the claim was made that a side-by-side experience will remain functional?

If 4.2.1 was designed to introduce a fundamental breaking change, which should not be the case for a minor release such as this, why were we not given the courtesy of a warning well in advance to prevent any customer impact?

-Fabien.



#39052 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 11 November 2012 - 10:29 PM in Netduino Go

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.



#39051 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 11 November 2012 - 10:17 PM in Netduino Go

Chris,


Really quickly, before I dig into the touch display module, we'll want to make sure to not use the GoSocket class in public function calls outside of your constructor. The standard GoBus constructor auto-detects the GoBus module if no GoSocket is provided to the constructor, and allows the user to specify a GoSocket reference if they want to use a module on a specific gobus port (including on a hub, with GoBus 1.5+ modules).



Please keep in mind that you released the GoBus 1.5 spec mid-September, long after the launch of existing, GoBus 1.0 compliant modules. You also claim on the "Introducing GoBus 1.5" page that:


GoBus 1.5 modules will work side-by-side on your Netduino Go with GoBus 1.0 modules.



Yet, here we are with a regression.

What method are you using to find a module UUID?




A straight up SPI transaction, which has always worked, as you know:

public void Execute(Synchronicity sync = Synchronicity.Synchronous) {
SetSynchronicity(sync);
int contentSize;
var spiTxBuffer = SendContext.GetBuffer(out contentSize);
if (contentSize >= MaxSpiTxBufferSize) {
throw new ApplicationException("contentSize");
}
GoBusIrqEvent.Reset();
Spi.WriteRead(spiTxBuffer, 0, MaxSpiTxBufferSize, _spiRxBuffer, 0, MaxSpiRxBufferSize, 0);
if (sync == Synchronicity.Synchronous) {
WaitUntilGoBusIrqIsAsserted();
}
}



As far as auto-discovery on the bus: the concept breaks down the moment you have more than one of the same device on the GoBus. It is a nice to have feature which should not be allowed to impact the existing ecosystem.


-Fabien.



#39044 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 11 November 2012 - 09:39 PM in Netduino Go

Quoting Troll:

Just in case you hadn't heard what the problem is. I am getting it to hang on the Initialize call on both the DAQ and Touch Screen. If I flash it back to 4.2.0 it works, 4.2.1 doesn't. Same issue was seen by Gut when he tested. it.



There's no exception being thrown: the code just hangs on the Initialize() call trying to ID the module:


        public static void Main() {
            var canvas = new VirtualCanvas(TouchEventHandler, WidgetClickedHandler);
            canvas.Initialize(GoSockets.Socket5);


or


namespace DAQmodule {
    public class Program {
        public static NwazetDAQ daq = new NwazetDAQ();
        public static void Main() {
            daq.Initialize(GoSockets.Socket5);

	<...>


Initialize() attempts to retrieve an SPI packet containing a valid module ID, matching the driver (per the GoBus 1.0 spec). All of our modules have worked this way from day one.


        public void WaitUntilModuleIsInitialized() {
            while (!_moduleReady) {
                Execute(Synchronicity.Asynchronous);
                if (_spiRxBuffer[0] == 0x80 && 
                    _spiRxBuffer[1] == '[' && 
                    _spiRxBuffer[2] == 'n' && 
                    _spiRxBuffer[3] == 'w' && 
                    _spiRxBuffer[4] == 'a' && 
                    _spiRxBuffer[5] == 'z' &&
                    _spiRxBuffer[6] == 'e' &&
                    _spiRxBuffer[7] == 't' &&
                    _spiRxBuffer[8] == '.' &&
                    _spiRxBuffer[9] == 'd' &&
                    _spiRxBuffer[10] == 'i' &&
                    _spiRxBuffer[11] == 's' &&
                    _spiRxBuffer[12] == 'p') {
                    if (_spiRxBuffer[17] != _identifier8bitCrc) throw new ApplicationException("SPI data corruption");
                    _moduleReady = true;
                    return;
                }
                Thread.Sleep(200);
            }
        }


This is a basic SPI exchange which doesn't rely on any other .Net MF feature (i.e. InterruptPort).

-Fabien.



#39036 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 11 November 2012 - 09:04 PM in Netduino Go

Chris,


We do have a DAQ module, but it's currently undergoing GoBus compliance testing so I can't pull it until that's done.


I have no idea what that means, unfortunately. Can you please clarify?

So we weren't able to do any testing with those two modules.


This is unfortunate for Netduino Go users at large. Such breaking changes should not be introduced.

We are here to assist module manufacturers with their driver code where possible. Whether you want to send us hardware to help diagnose the issue or if you want to send us info on the issue you're experiencing in the module driver, we're happy to help.


As I stated it earlier, our modules worked just fine until this release broke either SPI or interrupt ports or something else in the Netduino Go firmware that we have no control over. Regression testing with existing Netduino Go modules should be a best practice put in place as part of the Netduino Go firmware release process, for the sake of our mutual customers.


-Fabien.



#39033 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 11 November 2012 - 08:43 PM in Netduino Go

Troll, All Nwazet modules, by design, work at the lowest level of the .Net MF, only requiring a dedicated SPI port and an interrupt port. In other words, we're 100% GoBus 1.0 compliant. This enables our modules to be used across all Netduino SKUs, (Netduino, Netduino+(2), Netduino Mini, Netduino Go) starting with firmware revision 4.1.1. If a breaking change affecting SPI and/or interrupt ports is introduced with a Netduino Go firmware update, we have no control over it. Obviously, a breaking change of that nature will potentially impact any type of device using a straight SPI / interrupt port. Chris, Have you actually tested firmware 4.2.1 with the Nwazet Touch Display and the Nwazet DAQ modules before releasing this firmware? -Fabien.



#39026 4.2.1 with Nwazet DAQ and Touch Screen

Posted by Fabien Royer on 11 November 2012 - 07:55 PM in Netduino Go

Chris, Do you do regression testing on existing Go modules before releasing Netduino Go firmware updates? -Fabien.




home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.