63 replies to this topic

[theTroll]

I was wondering if there was any word about what is going on with the update?

[Chris Walker]

Hi theTroll,

I was wondering if there was any word about what is going on with the update?

Our [nwazet touchscreen is damaged from taking it to so many tradeshows, so I'm not quite sure what the issue is. Have you contacted Fabien or Bertrand from [nwazet? They're usually pretty responsive.

If you don't hear anything, we can try to buy another one and debug the NETMF side here.

Chris

[Fabien Royer]

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

[theTroll]

Chris,

Do you do regression testing on existing Go modules before releasing Netduino Go firmware updates?

-Fabien.

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.

[Chris Walker]

Hi Fabien,

Do you do regression testing on existing Go modules before releasing Netduino Go firmware updates?

Yes, we do testing with the GoBus modules we have on hand.

Chris

[Fabien Royer]

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.

[Chris Walker]

Have you actually tested firmware 4.2.1 with the Nwazet Touch Display and the Nwazet DAQ modules before releasing this firmware?

We have worn out the Touch Display by taking it to so many events, I'm afraid. We do have a DAQ module, but it's currently undergoing GoBus compliance testing (for gobus trademark licensing) so I can't pull it until that's done. So we weren't able to do any testing with those two modules. We did test all of the other modules, and they worked without modification.

There shouldn't be any code compatibility issues with the 4.2.1 update, but there are some bugfixes to NETMF which may be bubbling up issues in the display module driver.

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. We want to make sure that all GoBus modules and Netduino accessories work well for users.

Chris

[theTroll]

It is not really a problem for me, I am just going to reflash 4.2.0. I just wanted to let people know so they could work on it.

[Fabien Royer]

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.

[Chris Walker]

Hi Fabien,

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?

GoBus and the GoBus logo are registered trademarks. We license these royalty-free to module manufacturers who create modules which are interoperable with the GoBus specification. We did this with the [nwazet Touch Display and Relay modules, for instance.

With the DAQ module, we didn't know about the module until it shipped. So we picked one up to do compliance testing so we can get you approval to use the GoBus interoperability logo on the product and market it as GoBus compliant. We're working on a click-through agreement so that module manufacturers won't have to submit them for approval in the future. But it's still really critical to ensure GoBus compliance, as to protect GoBus users we do have to ensure that products are compliant with the spec.

More details on GoBus trademark licensing can be found in the legal section of the GoBus Spec.

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.

I'm not aware of any breaking changes. Let's see what line of code is causing an exception in the module driver...and I can help provide guidance on why a user might be seeing that exception.

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.

Can you please provide me a bit more info on what broke in the firmware? If there's a bug which has been introduced we would like to fix it ASAP.

We will continue doing testing with GoBus modules to help ensure that new firmware releases work well for customers with all of their modules. I will make sure we pick up another Touch Display so that we can put it into our test mix. If you'd like to send us a DAQ, we can look at that too.

Please note that the sheer number of Netduino-compatible accessories prohibits us from testing those. But the number of GoBus modules is much more manageable, so we will do our best to make sure that those continue to work with GoBus-compliant mainboards. Backwards compatibility and simple use of GoBus modules is a major concern for us.

Chris

[Fabien Royer]

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.

[Chris Walker]

Hi Fabien,

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

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

	<...>

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).

More details on this can be found on page 22 of the GoBus Spec. It's really important to use the standard constructor format for at least two reasons: (1) it provides a consistent user experience; (2) code-generation applications will need to use a consistent initialization method.

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.
...
This is a basic SPI exchange which doesn't rely on any other .Net MF feature (i.e. InterruptPort).

What method are you using to find a module UUID? Are you using the GoBus classes to find the module, or are you trying to search manually on the SPI bus? It's very important to use the standard GoBus classes, as they provide compatibility across GoBus-compliant mainboards and firmware revisions.

BTW, I'm happy to help tweak the drivers to help out here. I just need to understand what's going on in the driver code and I need hardware to test against. We're here for you and your customers.

Chris

[Lunddahl]

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.

Both the Netduino Go and your modules is part of an electronic prototyping system, and we are even lucky enough to have a very strict versioning system in place. Please don't drag this down to "consumer ready" level.

I see no reason why your products should hold back a release of any firmware, even for a single minute, either you adapt afterwards or to please your customers you seek influence so that you have access in the development cycle in a time frame so it's possible for you to adapt before the release.

If there is no access to beta bits in the development cycle, you just have to adapt afterwards. There is no reason your modules should delay other solutions that are not dependent on them.

As you can see in this thread, one of your customers have no issues figuring out that your modules is not ready for the new firmware yet, and i'm sure they will be soonish, as i can see your are offered all kinds of help on this issue, but i fail completely to see why other projects should wait.

- Ulrik

[Fabien Royer]

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.

[Fabien Royer]

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.

[Chris Walker]

Hi Fabien,

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.

We've never actually tested the [nwazet touch display or relay modules for GoBus 1.0 compliance. Since [nwazet was in the early development program, we only validated that the code samples worked and that the modules didn't interfere with other devices.

In our internal system, the [nwazet modules are logged as "Netduino Go compatible accessories" similar to the Komodex GoBus Breakout board. We should probably dig in and do an official compliance test so we can reclassify them internally as GoBus 1.0 modules instead. If you'd like us to do so, just let me know and we'll get a hardware sample and help ensure that you don't have to worry about code breaking on different GoBus-compliant boards or with future firmware releases.

The enumeration and electrical specs of GoBus 1.5 are identical to the GoBus 1.0 specs, which is why modules like Shield Base have been upgraded to GoBus 1.5 without any hardware or user code changes. It should be a seamless software-only transition for [nwazet as well, one which should be really good because it'll allow compatibility with any GoBus-compliant mainboards along with the upcoming hubs.

What method are you using to find a module UUID?

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.

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.

It should actually work great with multiple devices, as we can support searching based on serial number as well. Auto-discovery is a critical feature baked into GoBus from day one, and it will become more and more powerful over time. By using the standard GoBus enumeration pattern, your module benefits from all of that too.

In any case, auto-discovery is in the standard constructor pattern so it shouldn't negatively impact the existing ecosystem.

Chris

[Chris Walker]

Moderator note: Just a quick request to make sure we all keep things civil here. The Netduino community is a happy (and even family friendly) place where people come to enjoy their passion and belong to a community of fellow enthusiasts. I know that everyone means well...but we don't want Ulrik or others to feel insulted or alienated. Let's keep this thread limited to helping ensure that [nwazet Touch Display users get updated drivers (or a firmware update if there's a bug in the NETMF firmware) so they can continue enjoying the use of their [nwazet product. If we get too far off topic or insults start hurtling, one of the moderators will close the post. We hardly ever have to moderate that way, but we need users to feel safe and know that they're appreciated here. Chris

[ErikN]

As you can see in this thread, one of your customers have no issues figuring out that your modules is not ready for the new firmware yet, and i'm sure they will be soonish, as i can see your are offered all kinds of help on this issue, but i fail completely to see why other projects should wait.

I picked up on that as well. I wanted to escort her out of the thread and thank her for her bug report!

New software usually has some known errata upon release. Most of the times things are found after. This looks like one of those times. I think this might have escalated a bit beyond reason here - though I agree a minor build should not introduce any contract changes, it's hardly damaging at this point. I think, given the report and the reproducibility maybe it would be good to put a notice on the product page(s) saying there is a known issue with this firmware release and that it's not recommended for people using those modules.


In the mean time it seems Chris is offerring resources to help correct the problem. It looks like he's already pointed out some suggestions as to possible issues or at least some best practices. I'd love to see these tidbits incorporated into the Module Builders guide (whatever the actual title or form it might take) but in the mean time I'd say take a step back for the moment. It doesn't really seem like a big deal. If people are using these modules successfully, they wouldn't upgrade to the newest firmware just for giggles. If they did, I'd say they'd have the capability to downgrade back to the last working version just as easily. If this isn't the case, it doesn't seem like they'd be affected at all during the grace period where this is worked out.

This is precisely why corporations don't jump on new OS releases the day they come out. There are always things that will need to be found. It's not really the OS makers' job to ensure compatibility with all software installs available but they should do a reasonable job at documenting any changes and collecting error reports so 3rd parties can issues patches and become compatible. In this case it sounds like Chris is doing a lot to ensure compatibility with a wide variety of modules but as the ecosystem grows it's going to be harder and harder for them to do this - which is why I think it's great there is a community offering support and even Secret Labs resources to help work this out.

Bottom line - yes, it might be an annoyance to users but that's all it is. It's growing pains. On the upside it's not a hardware change - it's just a software release that will likely need to be undertaken. Again, this is not unexpected in a pure software world, mixing it with hardware doesn't exempt us from this situation.

I think this is a good point to thank theTroll for the bug report and close the thread. Further discussions of how to resolve this particular issue would be better suited on a builders board, not the community board. Any resolution from that discussion, if it seems applicable to other module builders, should of course be shared. There is nothing to hide but to many this is just noise and if they found this thread because they hit the problem, they had their answer many, many replies ago.

-Erik

[carb]

I see no reason why your products should hold back a release of any firmware, even for a single minute, either you adapt afterwards or to please your customers you seek influence so that you have access in the development cycle in a time frame so it's possible for you to adapt before the release.

Ulrik,

This one I agree with you 100%. I wanted to write something when I saw the earlier post but couldn't find the right words.

Thanks,
Chuck

[Chris Walker]

I think this is a good point to thank theTroll for the bug report

Oh yes. Let me second that. Thank you theTroll! *

Chris

* There are many others to thank for other things, but let's give theTroll some love here