I just completed the investigation of the issue and here's what I have observed and my recommendations to move forward.
Congrats on your findings, and thank you for taking the time to write it all up and sharing it.
- Ulrik
4.2.1 with Nwazet DAQ and Touch Screen
Started by theTroll, Nov 11 2012 05:56 PM
63 replies to this topic
#41
Lunddahl
-
- Members
-
- 152 posts
Advanced Member
- LocationEurope, Denmark
Posted 12 November 2012 - 11:05 AM
Congrats on your findings, and thank you for taking the time to write it all up and sharing it.
- Ulrik
- Fabien Royer likes this
#42
theTroll
-
- Members
-
- 54 posts
Advanced Member
Posted 12 November 2012 - 04:12 PM
Tested the 10MHz fix for the DAQ and Touch Pad. They work great now. Quick find Fabian, thanks. Thanks for everyone working to find the problems. Now I am going to see if I can make my thermometer work.
tt.
- Fabien Royer likes this
#43
Chris Walker
-
- Moderators
-
- 7767 posts
Secret Labs Staff
- LocationNew York, NY
Posted 12 November 2012 - 05:21 PM
Hi Lunddahl,
Good questions. First, here's a link to the latest GoBus 1.5 spec:
http://forums.netdui...ucing-gobus-15/
With GoBus SPI transport, the initial frame size is 18 bytes and CRC8. This allows a frame size up to 63 bytes. If you switch to CRC16, you can have a frame size of up to 16383 bytes.
The hubs can handle SPI transport at up to 18 mbps. This is the maximum SPI speed of the STM32F0 microcontrollers. Normal communication will probably happen around 10mbps, which is still really fast, but we can tune this.
from page 2 of the spec:
"No data stream interruptions: Up to 15 simultaneous outstanding frames per device, ACKs included with every frame"
Frames as switched. Up to 15 frames can be sent to a device before the mainboard puts further frames to the device on hold. In most circumstances the mainboard will have received an ACK for the first frame long before then. But if your module is a few hubs down, for instance, you could bump up against this 15 frame limit.
The 15 frames are also awesome for asynchronous which have some latency.
GoBus modules use their /INT (/IRQ) pin to let the mainboard (or the hub they're plugged into, which sends the alert upstream) know that they have data to send.
Chris
Are their any hints as to how the GoBus 1.5 will handle frames, how long can they be, how fast can SPI signal to the hub, will there be a buffer so multiply frames can be sent without an ack from the modules.
Good questions. First, here's a link to the latest GoBus 1.5 spec:
http://forums.netdui...ucing-gobus-15/
With GoBus SPI transport, the initial frame size is 18 bytes and CRC8. This allows a frame size up to 63 bytes. If you switch to CRC16, you can have a frame size of up to 16383 bytes.
The hubs can handle SPI transport at up to 18 mbps. This is the maximum SPI speed of the STM32F0 microcontrollers. Normal communication will probably happen around 10mbps, which is still really fast, but we can tune this.
As I understand it GoBus is simplex, hosts send to the module in one SPI transfer, wait for it to interrupt then the host make another SPI transfer to receive, right?
Will those transfers be buffered in the hub, or cut-trough switched.
from page 2 of the spec:
"No data stream interruptions: Up to 15 simultaneous outstanding frames per device, ACKs included with every frame"
Frames as switched. Up to 15 frames can be sent to a device before the mainboard puts further frames to the device on hold. In most circumstances the mainboard will have received an ACK for the first frame long before then. But if your module is a few hubs down, for instance, you could bump up against this 15 frame limit.
The 15 frames are also awesome for asynchronous which have some latency.
GoBus modules use their /INT (/IRQ) pin to let the mainboard (or the hub they're plugged into, which sends the alert upstream) know that they have data to send.
Chris
#44
Chris Walker
-
- Moderators
-
- 7767 posts
Secret Labs Staff
- LocationNew York, NY
Posted 12 November 2012 - 05:23 PM
Hi neslekkim,
In the meantime, we post the latest source on the Downloads page. 4.1.1 should be up soon.
Chris
We have netduino.codeplex.com. There is a CodePlex bug which is prohibiting us from uploading the latest firmware. It will be fixed by switching the CodePlex site to Git. We're working on it.I really wish there was an public source repository where we could check what changes are happening to the netduino and the modules, this way, we could test against new version underways, possibly before it's released to see if we need to change stuff.
In the meantime, we post the latest source on the Downloads page. 4.1.1 should be up soon.
Chris
#45
neslekkim
-
- Members
-
- 350 posts
Advanced Member
- LocationOslo, Norway
Posted 12 November 2012 - 05:44 PM
ok, so that repo is actually alive?
"This CodePlex repository is being updated with .NET MF 4.2 beta sources. It will become an official repository a few weeks after the release of .NET Micro Framework v4.2 (expected in October 2011)."
The last commit also seems to be from august 2011?
I think I discarded it due to that, and due to no folder for Netduino Go.
But this will be very good if you start using it properly, that should be of good use for the rest of us. (is this supposed to be complete, or things to be merged with the official .netmf code?)
--
Asbjørn
#46
Chris Walker
-
- Moderators
-
- 7767 posts
Secret Labs Staff
- LocationNew York, NY
Posted 12 November 2012 - 05:47 PM
We've been trying to upload the full repo for about a year, but CodePlex (using Hg) crashes on large uploads. One of our community members (nakchak) has built a new repo using Git and it seems to work well. Once we get through any required bugfixes for the new 4.2.1 release we'll be coordinating with Microsoft to switch the repo over.But this will be very good if you start using it properly, that should be of good use for the rest of us. (is this supposed to be complete, or things to be merged with the official .netmf code?)
I'm really looking forward to it.
Chris
#47
neslekkim
-
- Members
-
- 350 posts
Advanced Member
- LocationOslo, Norway
Posted 12 November 2012 - 05:50 PM
Ah, but the plan is to actually use this repo actively also?, not something that is going to be updated like now an then?
Hm, I thought Hg was kinda good on big uploads?, I'm using Svn here, and svn doesnt like big uploads/downloads so much.
But Git is maybe better anyway, if people is not complaining about tooling 
--
Asbjørn
#48
Fabien Royer
-
- Members
-
- 406 posts
Advanced Member
- LocationRedmond, WA
Posted 12 November 2012 - 08:04 PM
Hi 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.
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 Files
-
4.2.1-SPI-speed-bug-logic-captures.zip 179.51KB
4 downloads
-
4.2.1-SPI-speed-bug-5mhz.jpg 138.87KB
53 downloads
#49
Nicky
-
- Members
-
- 78 posts
Advanced Member
- LocationDenmark
Posted 13 November 2012 - 03:54 PM
Since this is already a discussion about the nwazet products, and Fabien is active in this topic:
Does the nwazet display module, have some sort of response/idle timing between executing commands? It seems to me, that it often, doesn't do the Execute(), even through its told to do so, if two update cycles runs immediately after each other.
Currently it happends during the my initializing-phaze, where I want to show a progressbar showing the progress step by step.
It changes from load to load, even without any codechanges. But it seems to be having something to do with updating to frequently.
Note: It happends with both 4.2.0.* and 4.2.1.0 firmware. The SPI is running at 10 MHz.
ntools
TCP Listener (Beta) · FTP Server (Alpha)
Netduino Plus Go Module · Xml Parser
http://ntools.codeplex.com/
#50
theTroll
-
- Members
-
- 54 posts
Advanced Member
Posted 13 November 2012 - 04:58 PM
Currently it happends during the my initializing-phaze, where I want to show a progressbar showing the progress step by step.
I might be able to help, mainly because I broke stuff on mine. Are you doing any of this in multiple threads?
#51
Nicky
-
- Members
-
- 78 posts
Advanced Member
- LocationDenmark
Posted 13 November 2012 - 05:06 PM
I might be able to help, mainly because I broke stuff on mine. Are you doing any of this in multiple threads?
There's multiple threads running, and after it's completely initialized, worker threads can call Screen updates if needed. But at the initilization-process, only the main thread is calling the screen.
ntools
TCP Listener (Beta) · FTP Server (Alpha)
Netduino Plus Go Module · Xml Parser
http://ntools.codeplex.com/
#52
theTroll
-
- Members
-
- 54 posts
Advanced Member
Posted 13 November 2012 - 05:32 PM
There's multiple threads running, and after it's completely initialized, worker threads can call Screen updates if needed. But at the initilization-process, only the main thread is calling the screen.
What was causing my problem is that I had two threads trying to talk to the device at one time. Very bad. You might want to make sure that you are not somehow sending multiple commands to the hardware before the other command is finished.
Beside that I would have to see your code and test it.
#53
Nicky
-
- Members
-
- 78 posts
Advanced Member
- LocationDenmark
Posted 13 November 2012 - 05:55 PM
You might want to make sure that you are not somehow sending multiple commands to the hardware before the other command is finished.
Yeah, thats why I was wondering, if it had some responsetime or something. Couldn't find anything about it on the nwazet site.
Beside that I would have to see your code and test it.
Sure, I'll post some code when I get home. I don´t have it here at the moment.
ntools
TCP Listener (Beta) · FTP Server (Alpha)
Netduino Plus Go Module · Xml Parser
http://ntools.codeplex.com/
#54
Fabien Royer
-
- Members
-
- 406 posts
Advanced Member
- LocationRedmond, WA
Posted 13 November 2012 - 08:45 PM
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.
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.
#55
Nicky
-
- Members
-
- 78 posts
Advanced Member
- LocationDenmark
Posted 14 November 2012 - 04:50 PM
Thanks for the answer Fabien.
I have no excuse for my stupidity here - I've forgot to make the code threadsafe.
Two quick questions:
a. Can the nwazet screen be replaced?
b. Is it normal that the screen flickers when it updates?
ntools
TCP Listener (Beta) · FTP Server (Alpha)
Netduino Plus Go Module · Xml Parser
http://ntools.codeplex.com/
#56
Fabien Royer
-
- Members
-
- 406 posts
Advanced Member
- LocationRedmond, WA
Posted 14 November 2012 - 05:09 PM
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.
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.
#57
Nicky
-
- Members
-
- 78 posts
Advanced Member
- LocationDenmark
Posted 14 November 2012 - 05:19 PM
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)
Ah that wasn't exactly what I meant.. it's the yellow screen when it initializes i was referring to
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 send 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
Ah I see.. and this is the case for all Go Modules, right?
ntools
TCP Listener (Beta) · FTP Server (Alpha)
Netduino Plus Go Module · Xml Parser
http://ntools.codeplex.com/
#58
Fabien Royer
-
- Members
-
- 406 posts
Advanced Member
- LocationRedmond, WA
Posted 14 November 2012 - 05:46 PM
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 that wasn't exactly what I meant.. it's the yellow screen when it initializes i was referring to
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.
#59
Nicky
-
- Members
-
- 78 posts
Advanced Member
- LocationDenmark
Posted 14 November 2012 - 06:07 PM
Thank you for your answers. In this case, it would mean to the Netduino is rendering a bitmap, and then sends it to the module, which updates it immediately?
For research purpose only: If need, would it be possible to order a batch of screens with custom logos?
ntools
TCP Listener (Beta) · FTP Server (Alpha)
Netduino Plus Go Module · Xml Parser
http://ntools.codeplex.com/
#60
Fabien Royer
-
- Members
-
- 406 posts
Advanced Member
- LocationRedmond, WA
Posted 14 November 2012 - 06:17 PM
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.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
