The .Net Micro Framework and IoT session got cancelled because a personal emergency from the speaker. But, we'll record it and add it to the recorded sessions in the NETConf site. It is a very interesting topic.
CW2's Content
There have been 148 items by CW2 (Search limited from 28-September 23)
#58904 .NET MF v4.Next
Posted by
on 26 June 2014 - 10:00 AM
in
General Discussion
#58911 .NET MF v4.Next
Posted by
on 26 June 2014 - 02:23 PM
in
General Discussion
After watching dotnetConf 2014 session .NET Native Deep Dive by Andrew Pardoe about .NET Native, it seems Microsoft is working hard on AOT compiler for Windows Store apps, something that would be really nice to have for .NET MF. Interestingly, there is a comment on the FAQ page mentioning .NET Micro Framework:
Will .NET Native replace the .NET Micro Framework and will C#/.NET be made fully available for small devices?
.NET Native is currently focused on Windows Store apps. The Micro Framework is delivered by the Windows Embedded team, and the .NET team is working with them on how best to serve customers.
I guess it's time to start sending emails to dotnetnative@microsoft.com 
#59482 LCD panel from old 8.5" Philips TV (a085fw01 v7)
Posted by
on 31 July 2014 - 06:36 AM
in
General Discussion
IMVHO it will be rather hard - as you can see in the datasheet, the LCD requires complex driving signals with precise timing (e.g. tCPH is 99 .. 107 ns) and multiple voltages (for an overview how to drive LCD with a microcontroller have a look for example at AN658). You'd also need some serious tools for troubleshooting, like oscilloscope and/or logic analyzer.
There are microcontrollers with dedicated (hardware) LCD drivers, e.g. STM32F427/37, which makes it a little bit easier, but still it is going to be a lot of work...
Much easier is to use the existing driver board from the TV and hope it has some usable interface. Almost certainly undocumented, so you'd need to decode the protocol...
#60201 .NET Micro Framework V4.3 SDK-R2-Beta
Posted by
on 24 September 2014 - 06:15 AM
in
General Discussion
Visual Studio 2013 extensions
#60200 .NET Micro Framework V4.3 SDK-R2-Beta
Posted by
on 24 September 2014 - 06:10 AM
in
General Discussion
http://netmf.codeple...ses/view/133285
This is an SDK only updated release (e.g. porting kit and firmware don't change). The major highlights are:
- Updated SDK to support use with Visual Studio 2013 (and experimental support for Visual Studio "14")
- Split SDK installer from Visual Studio support. The SDK MSI now installs only the tools, and reference assemblies (like the desktop versions). A separate VSIX package installs to each supported version of Visual Studio to complete the installation. VSIX packages are available here, as well as from the Visual Studio Extensions Gallery accessible directly from VS.
- Since VS integration is on a per version basis, this new model also supports simultaneous installations of multiple VS versions.
#59769 Visual Studio 2014
Posted by
on 18 August 2014 - 07:25 PM
in
Visual Studio
I have not tried it myself (*), but it should be possible to compile .NET MF SDK for Visual Studio 2014 with appropriate modifications as described in Jan Ku?era's article (for 2013); although it might need a fix or two for Visual Studio SDK assembly references (due to some versioning issues).
(*) I decided to postpone my playing with certain .NET MF areas after Microsoft announced they were working on Visual Studio 2013 integration and that it will be released as VSX extension (the last post). I hope such extension will be [Visual Studio] version-independent.
Sal Ramirez said earlier today:
NETMF is still alive. As far as the Visual Studio integration, the team hit a couple of issues with code signing and the build environment. As soon as we resolve those issues we will post an update.
Thanks,
Sal
#57930 Can't build STM32Stamp from PK 4.3 RTM QFE1
Posted by
on 04 May 2014 - 11:11 AM
in
General Discussion
You can compare those two solutions to see what needs to be done:
- Change the serial transport to USB in platform_selector.h - replace COM1 with USB1 in #define statements,
- In TinyCLR.proj replace USB config library stub with the actual one, i.e. replace
<RequiredProjects Include="$(SPOCLIENT)\DeviceCode\Drivers\Stubs\USB_Config\dotNetMF.proj"/> <DriverLibs Include="usb_pal_config_stub.$(LIB_EXT)"/>
with<RequiredProjects Include="$(SPOCLIENT)\Solutions\MCBSTM32E\DeviceCode\USB\dotNetMF.proj"/> <DriverLibs Include="usb_pal_config_MCBSTM32E.$(LIB_EXT)"/>
or path of your library copy, - Change USB VID and PID identifiers in usb_config.cpp to valid values, preferably something with already working .NET MF USB driver; otherwise you'd have to create new WinUSB driver installation (custom .inf).
#57876 Can't build STM32Stamp from PK 4.3 RTM QFE1
Posted by
on 01 May 2014 - 04:45 PM
in
General Discussion
Attached is a zip archive with BitConverter source for 4.3 QFE1, which compiles fine in recent Keil MDK versions (5.x).
Attached Files
-
corlib_native_System_BitConverter.zip 1.84KB
13 downloads
#57919 Can't build STM32Stamp from PK 4.3 RTM QFE1
Posted by
on 03 May 2014 - 06:15 PM
in
General Discussion
Board still not recognized in Windows (Can't configure USB).
Have you switched/configured USB transport in your solution? Because STM32Stamp solution uses serial (COM1) by default, it will not be recognized as a USB device.
#57944 Can't build STM32Stamp from PK 4.3 RTM QFE1
Posted by
on 05 May 2014 - 06:25 AM
in
General Discussion
Does this mean MCU interrupts are not initialized properly?
It's hard to say, but probably not - interrupts are used rather often, so it probably would not work at all if they were not initialized properly. I would focus on USB, maybe there is a problem during initialization. Personally, I would firstly verify the firmware actually works with the serial (COM1) transport, I am a little bit skeptical that these old solutions were tested with .NET MF 4.3+. Then, I would try to determine why the device does not enumerate, most likely using a USB protocol analyzer... Also, you said you had a custom board?
#57961 Can't build STM32Stamp from PK 4.3 RTM QFE1
Posted by
on 06 May 2014 - 09:03 AM
in
General Discussion
Check - [Target-Options] [Output] [Browse Information]"
Do I need debug (/p:flavor=debug) version? Is ST-LINK v1 enough or I need ST-LINK v2?
"Browse Information" checkbox works only when you generate the output from within Keil µVision IDE, it has no effect when you build the .axf file externally (i.e. .NET MF msbuild system). Also, I am not sure it is necessary, it should be enough to add debugging information to the .axf - it is done automatically in the 'debug' configuration, and I think debugging information is not present for 'release'.
Update:
Yes, adjusted scatter file (added more RAM) and rebuilt debug version of TinyBooter.
Now I can see both Symbols and Source and can step into the code. Now I just need to understand STM32 initialization code, because it's different from examples that Keil provide and STM32CubeMX codegen create.
Any useful code nav tricks here? Where can be most possible point of failure?
Although there are some differences, the initialization code in basically always the same: start at reset vector, init stack, perform C runtime init (zi, .bss), jump to entry point function, initialize hardware (clock, interrupts, peripherals etc.). I would have a look at USB initialization, perhaps also reading the config sector...
#57983 Can't build STM32Stamp from PK 4.3 RTM QFE1
Posted by
on 07 May 2014 - 06:23 AM
in
General Discussion
Congratulations!
#57950 Can't build STM32Stamp from PK 4.3 RTM QFE1
Posted by
on 05 May 2014 - 03:46 PM
in
General Discussion
How to do this (check debug initialization)? Keil doesn't let me step into the code, only into assembly.
How are you using Keil debugger? You can create an empty project, set its output name to tinyclr, build output path to ...BuildOutput\...\bin (where tinyclr.axf is located) and the IDE should load debugging symbols automagically, letting you step through the code and place breakpoints...
If you are talking about software USB protocol analyzer, could you recommend one?
I use USBlyzer occasionally.
If DeviceCode\Targets\Native\STM32 code is not changed, why shouldn't it work in NET MF 4.3? Do you think I should try first with PK 4.2.0, 4.2.1 or 4.2.2?
Well, I don't know - I am not sure in what .NET MF version STM32Stamp solution was introduced, but there have been various changes in the .NET MF core code since then. But if you can get pass the initialization, then the problem is most likely in the USB, or memory layout (config sector could not be found?)... Really hard to say...
#60743 Custom building a smaller Netduino 2
Posted by
on 18 November 2014 - 02:45 PM
in
Project Showcase
Very nice board !
Although, on the photo it seems that there are parts and traces very close to the mounting holes, maybe so close that the screw head could touch them or even cause some damage (?)
#60298 wait on interrupt
Posted by
on 30 September 2014 - 06:38 AM
in
Netduino Plus 2 (and Netduino Plus 1)
...it's not really an interrupt but a flag to the low level code to poll the pin and post an event at level change
Nope, there is no low level polling, but real hardware interrupts - when an interrupt condition is detected by pin logic a native interrupt handler is called, which creates event with timestamp and posts it into internal queue for the CLR to execute managed callbacks (event handlers).
@Grant: Have a look at InterruptPort class and its OnInterrupt event, you can re-use one event for multiple pins and then differentiate using its first parameter.
#60304 wait on interrupt
Posted by
on 30 September 2014 - 12:19 PM
in
Netduino Plus 2 (and Netduino Plus 1)
I didn't know that CW2. Somewhere I read the timing could be off by 4us
Well, it certainly takes some time for the native interrupt handler to execute, but I don't have any numbers
I guess it also depends on what you consider low level code, as pin logic certainly could be considered really low level code
I guess in principle yes, but there is no code executed in the similar way like CPU executes its instructions. The pin
Is there any reason to re-use an event handler other than to save memory, and we are talking about a very tiny routine as discussed.
Personally, I sometimes re-use event handler when I need to handle multiple buttons, like this
...
InterruptPort button1 = new InterruptPort(Pins.GPIO_PIN_D0, ...);
InterruptPort button2 = new InterruptPort(Pins.GPIO_PIN_D1, ...);
InterruptPort button3 = new InterruptPort(Pins.GPIO_PIN_D2, ...);
...
button1.OnInterrupt += button_Interrupt;
button2.OnInterrupt += button_Interrupt;
button3.OnInterrupt += button_Interrupt;
...
void button_Interrupt(uint data1, uint state, DateTime time)
{
var pin = (Cpu.Pin)data1;
var on = (state != 0);
switch(pin)
{
case Pins.GPIO_PIN_D0:
...
break;
case Pins.GPIO_PIN_D1:
...
break;
...
}
// Or use data1 as array index, collection key etc.
}
It also makes diagnostic/troubleshooting easier in certain cases.
#60313 wait on interrupt
Posted by
on 01 October 2014 - 09:26 AM
in
Netduino Plus 2 (and Netduino Plus 1)
I have to re-read the original post to understand what you are trying to do, but a few notes regarding the code:
- You should specify pull-up resistor in the interrupt constructor, to prevent spurious events (use pull-up for low/falling edge, pull-down for high/rising edge),
- If you really must disable interrupts, it is easier to set InterruptMode to InterruptNone. Disposing is rather costly and events can be missed (no event handler when disposed). Alternatively, you can use boolean variable checked in the interrupt handler
static bool buttonsDisabled = false;
static void DisableButtons()
{
buttonsDisabled = true;
}
static void SW_OnInterrupt(uint data1, uint data2, DateTime time)
{
if(buttonsDisabled)
return;
...
}
Also, I would recommend you not to use threads initially - perhaps create a new project just to play with the button interrupts, experiment with different scenarios. Once you understand how it works, continue adding the functionality, implement threads only when really necessary/beneficial. In many cases, it is enough to use "Super-Loop" - the core/processing code is wrapped in while(true) loop implemented in Main() method, occasionally checking various state variables set by interrupt handlers.
#60572 74hc595 Shift Register and PWM
Posted by
on 29 October 2014 - 05:30 PM
in
Netduino 2 (and Netduino 1)
You have to toggle the individual shift register outputs on and off periodically. In a trivial example, consider the following pseudocode:
while(true)
{ // Output state
shiftRegister.Write(0x03); // #0 = on, #1 = on
shiftRegister.Write(0x02); // #0 = off, #1 = on
shiftRegister.Write(0x00); // #0 = off, #1 = off
shiftRegister.Write(0x00); // #0 = off, #1 = off,
}
The output #0 (least significant bit) is on for 1/4 of the cycle (loop), which translates to 25% PWM. The output #1 is on for 1/2 cycle -> 50% PWM. The other outputs are zero during the whole cycle -> 0% PWM.
The cycle (period) is divided into four parts, which allows only very coarse control (0 - 25 - 50 - 75 - 100%).
So, to produce PWM signal through shift register, you have to select a specific period, divide it into certain number of parts (finer division means finer PWM, e.g. 256 levels), and then toggle the outputs to produce pulses of a desired width. There are various ways how to implement it, a particularly clever one is called Binary Code Modulation.
#57316 .NET MF 4.3 QFE1 RTM
Posted by
on 03 April 2014 - 06:46 AM
in
General Discussion
The SDK and Porting Kit Documentation link was fixed today 
#59602 Slow I2C Sensor Reads, is this normal?
Posted by
on 07 August 2014 - 09:14 PM
in
Netduino Plus 2 (and Netduino Plus 1)
Ok, Spiked just beat me to it. 
#59613 Slow I2C Sensor Reads, is this normal?
Posted by
on 08 August 2014 - 07:07 PM
in
Netduino Plus 2 (and Netduino Plus 1)
Well, from the above the duration of I2C.Execute() method call is about 40 ms. Thus, even if you were able to consolidate the setup sequence into one I2C Execute() call, you'd still need at least three: setup, status check, data readout and that would be at least 3*40 = 120 ms, which is still 4× slower than Arduino.
IMHO the only way to get required speedup is to modify the firmware, i.e. create a native method that does all the I2C transactions to read data from the device.
Technical note: The .NET Micro Framework code is so slow in comparison to Arduino not only because it is interpreted, but also because there are several layers of abstraction - in this particular case, I2C methods take hundreds of instructions to execute parameter checking and marshalling, initializing internal structures, moving data forward and backward, mimicking asynchronous behavior using queues and completions etc. I can imagine writing a simple specialized I2C function that will not do anything but direct I2C calls, basically the same what Arduino code does - then it will be at least as fast, more likely faster (limited by I2C communication speed).
#59607 Slow I2C Sensor Reads, is this normal?
Posted by
on 08 August 2014 - 02:45 PM
in
Netduino Plus 2 (and Netduino Plus 1)
Well, I guess you could save a few ticks by retrieving all the X/Y/Z data in one transation - the datasheet says "Multiple data bytes can be written or read to numerically sequential registers without the need of another START condition", so it should be possible to use
...
var data = new byte[6];
getReadings = new I2CDevice.I2CTransaction[]
{
I2CDevice.CreateWriteTransaction(new byte[] { 0x00 }), // Start at 0x00
I2CDevice.CreateReadTransaction(data) // Read 6 bytes
};
...
You could then have three class member arrays and copy each result at once (Array.Copy()), instead of 6 individual byte assignments. There are other minor optimizations that come in mind, but I am afraid there will not be major improvement - you'd probably need to measure how long each part of the code takes (e.g. duration of the Execution() method calls) to see, where is possible chance of improvement. You can use for example Stopwatch class, but keep in mind the resolution of system timer (~21 µs Netduino gen 1; 1 µs Netduino gen 2). Unfortunately, the interpreter has major performance impact.
#59601 Slow I2C Sensor Reads, is this normal?
Posted by
on 07 August 2014 - 09:11 PM
in
Netduino Plus 2 (and Netduino Plus 1)
Unfortunately, there are certain areas in the .NET Micro Framework that should have been redesigned, e.g. to support multiple devices...
While it is not possible to create second instance of I2CDevice unless you Dispose() the first one, it is possible to have several I2CDevice.Configuration instances and switch among them:
// Warning: Code written from head
private I2CDevice.Configuration[] configs = new [] {
new I2CDevice.Configuration(0x30, 400),
new I2CDevice.Configuration(0x31, 400),
new I2CDevice.Configuration(0x32, 400)
};
// Initialize with a dummy configuration, or use any of the above
private I2CDevice mag = new I2CDevice(new I2CDevice.Configuration(0, 0));
...
for(var i = 0; i < configs.Length; i++)
{
mag.Config = configs[i]; // Select actual device
runSensor(mag, i);
}
I think there is even a class/library somewhere in the forums... ...I2CBus and probably several other 'multi' I2C implementations.
#60635 Controlling 2WD Chassis using Motor Driver 1A Dual TB6612FNG
Posted by
on 05 November 2014 - 12:24 PM
in
Netduino Plus 2 (and Netduino Plus 1)
There is no power supply for the motors - VM is not connected (?)
#60637 Controlling 2WD Chassis using Motor Driver 1A Dual TB6612FNG
Posted by
on 05 November 2014 - 12:57 PM
in
Netduino Plus 2 (and Netduino Plus 1)
The motor driver IC has separate power supply for motors (VM) and logic (VCC). You can use the batteries to power both Netduino and motors (if it is a standard AA battery holder, you should be able to insert a wire between battery and the positive contact lead and solder it to motor board VM input).
