Kevin, For what it's worth, I was able to get ~2.5 MHz SPI transmissions on the STM8S but avoided interrupts to do so. The method I used was to put the STM8S into a 'wait for interrupts' mode, waiting for SPI NSS to be asserted, and then retrieved / sent the bytes in a loop using the SPI registers. While the GoBus 1.5 spec will go a long way in simulating asynchronous SPI, it is not designed for 'real-time' communication scenarios. -Fabien.

Hi Chris,

Over time we'll be moving it all to DMA (both the underlying SPI transport and the hardware CRC) so performance is really going to scream

For those of us already using DMA with SPI, I am very concerned about the transition path. One thing that I would like to see preserved is 100% backward compatibility with today's synchronous SPI, available side-by-side with GoBus 1.5 asynchronous methods.


-Fabien.

Great work Mark. -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.

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're happy to let you know that we're having a sale on all Nwazet Netduino Go modules:

 

 

Hi Chris, Have you tried flashing our Nwazet DAQ module as well? This is what Jason was looking for in this case. When I did, the flashing application just got stuck on the last page indefinitely. I have personally given up on trying to flash firmware from a Go! main board because it's unreliable: one module might work 5 times in a row and fail on the 6th attempt, or based binary size changes, it may or may not work. IMO, Go! users should not have to go through so much pain and frustration to get upgrades: it should be a smooth user experience, baked into the Netduino Go! firmware by design. -Fabien.

We all wish flashing modules through a Netduino Go! worked well w/o jumping through hoops, but it's just not the case. I am as bothered as you are that this situation has not yet been addressed for all Go! users in a way that is seamlessly integrated with the Go! platform and this is why I proposed an alternative and spent time making a video to show how it works. Yes, there is a bit of hardware needed, but it's common and cheap.

Chris, I didn't keep that flashing application because it didn't work but you can repro the failure yourself using the binaries from our source repository as discussed at the beginning of this thread. The length of the cable (5 or 10cm) does not affect the outcome. Btw, it might be good to split this thread at the point where it started straying from the topic. Thank you, -Fabien.

Hi Jason, The method that I recommend for flashing our ARM-based modules is this one: http://forums.netdui...r-demonstrator/ Thanks, -Fabien.

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.

Matt, Thanks for sharing this. I love what you put together for your drivers and that would be perfect. Steve, Thank you for your offer! That would be awesome and sincerely appreciated! -Fabien.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.