CW2's Content

#58172 Understanding the Netduino 2 schematics - LMV7271MF and NTR4101PT1G

Posted by CW2 on 16 May 2014 - 12:48 PM in Netduino 2 (and Netduino 1)

The basic operation of the circuit is to switch the USB power on, when voltage from power jack drops below a certain threshold.

The LMV7271 operational amplifier (op-amp) is used as a comparator, which produces output voltage V_O = "1" if V₊ > V_-, and V_O = "0" if V₊ < V_-. Thus, when VIN_PROTECTED < VIN_REF (*), the op-amp output switches the MOSFET on (**), which connects the USB power to +5V rail. Otherwise, USB power is disconnected and +5V rail voltage comes from 5V linear regulator U1 (MC33269).

(*) The exact voltage levels being compared are determined by resistor dividers:

VIN_COMP = VIN_PROTECTED*R28/(R8 + R28) = VIN_PROTECTED/2.4,

VIN_REF = 5*R27/(R27 + R31) = 5/2 = 2.5V

so the comparator output voltage V_O = (VIN_PROTECTED/2.4) > 2.5V ? "1" : "0", which means the USB power is switched on when the power jack voltage drops below 2.5*2.4 = 6V. This is because the MC33269 regulator has 1.0V dropout voltage (its input voltage must be higher than output voltage, to ensure proper function).

(**) It is a P-channel MOSFET, which has inverted switching logic - it is "on" when the gate is "low".

#58251 Understanding the Netduino 2 schematics - LMV7271MF and NTR4101PT1G

Posted by CW2 on 19 May 2014 - 11:11 AM in Netduino 2 (and Netduino 1)

Now when you mention LiPo battery - do you plan to have charging functionality on board? Because there are Li-Ion/Li-Po battery charge controlers with automatic power source selection. For example, Microchip Application Note 1149 shows a design with MCP73837 in which "The input power should supply the system load and charge the battery when a battery is present in the system. When the input power source is removed, the system is supported by the battery. When the system load and the battery draw more energy than the supply can offer, the system load takes priority over the battery charger."

So, you can for example power Netduino Mini always from the battery and let the MCP automatically handle the power source selection and battery charging. You'd probably need to select a little bit different battery setup (a separate cell for Netduino Mini?) or choose multi-cell charging IC (MCP73837 is only for a single cell, 4.2 - 4.5V).

#59602 Slow I2C Sensor Reads, is this normal?

Posted by CW2 on 07 August 2014 - 09:14 PM in Netduino Plus 2 (and Netduino Plus 1)

Ok, Spiked just beat me to it.

#59601 Slow I2C Sensor Reads, is this normal?

Posted by CW2 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.

#59607 Slow I2C Sensor Reads, is this normal?

Posted by CW2 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.

#59613 Slow I2C Sensor Reads, is this normal?

Posted by CW2 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).

#60313 wait on interrupt

Posted by CW2 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.

#60304 wait on interrupt

Posted by CW2 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 ~~logic~~ input circuitry for edge detection is just a few logic gates (of course in real microcontroller it is a little bit more complex) and the interrupts are handled in a specialized unit (for ARM it is named Nested Vectored Interrupt Controller, NVIC) - only after validation, prioritization etc. NVIC notifies CPU, which then loads an interrupt handler address from vector table and starts executing the instructions. If you are interested in more details, have a look for example at the following document.

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.

#60298 wait on interrupt

Posted by CW2 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.

#58904 .NET MF v4.Next

Posted by CW2 on 26 June 2014 - 10:00 AM in General Discussion

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.

https://www.ghielect...age=6#msg158833

#58911 .NET MF v4.Next

Posted by CW2 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

#58774 .NET MF v4.Next

Posted by CW2 on 19 June 2014 - 06:19 AM in General Discussion

Also some details about Visual Studio 2013 support (issue #2516):

Support for VS2013 is under development. We'll have some more details and a test build shortly. The general goal is to not require firmware updates (which makes things tricky due to how the current build does version numbering for everything on mass) Furthermore, the current setup is designed to support only one version of VS at a time. While this was mostly acceptable when VS relased on a cadence on the order of ~3years, now that they are on an apparently annual cadence that's not going to fly. So we are seperating out the core reference libraries, build infrastructure etc... from the VS integration. For the VS integration we'll be going to VSX extensions in the gallery (Same for samples). Thus, the experience becomes much more consistent with other platforms that VS targets. While enabling VS2012 AND VS2013 support. (ditto for VS14 CTP and beyond)

#58795 .NET MF v4.Next

Posted by CW2 on 20 June 2014 - 06:30 AM in General Discussion

For me, the most interesting is the separation of Visual Studio integration component, which is probably the only thing anyone else will not be able to do (only Microsoft signed extensions allowed in Express SKUs). If they do it right, say it allows to completely replace the core assemblies, I will be very happy...

#58769 .NET MF v4.Next

Posted by CW2 on 18 June 2014 - 09:31 PM in General Discussion

Something is happening on netmf.codeplex.com...

ACCESS PERMISSIONS UPDATE:
2014 Jun 16
In preparation for the longer term future of .NET MF we are in the process of some changes to the use of CodePlex. (Including switching to a GIT repository model to make things easier for a true OSS development process). As part of this transition everyone's permissions were reset to "editor" status, thus denying check-in permissions on the TFS tree. Fear not! This isn't a permanent change. We'll have more details on the results of the changes and the process for contributing into the official repositories in the very near future so stay tuned.

-Steve Maillet
Senior Architect .NET Micro Framework

Planned release .NET MF v4.Next

Now only if anyone know what "very near future" means - is it sooner or later than [the usual] "soon"

#59774 Netduino Plus 1 and Pins class

Posted by CW2 on 18 August 2014 - 08:44 PM in Netduino Plus 2 (and Netduino Plus 1)

So you can see Pins class in a new tab, and you can see this code!

Ok, thanks for the information. Well, the explanation is the code you see is not the actual source, but generated by Visual Studio via reflection - and obviously it is not quite correct, as the [mandatory] cast is missing. It could even be a 'feature', to make the definition easier to read by removing the obvious cast.

#59765 Netduino Plus 1 and Pins class

Posted by CW2 on 18 August 2014 - 07:01 PM in Netduino Plus 2 (and Netduino Plus 1)

public const Cpu.Pin ONBOARD_LED = 55;

Where exactly do you see this code? I cannot find it anywhere in the source. Are you inspecting the assembly (.dll) with some tool like .NET Reflector?

#61163 Non-Voliatile Storage - NVRAM

Posted by CW2 on 05 January 2015 - 03:36 PM in Netduino Plus 2 (and Netduino Plus 1)

I want to see anyone build the firmware without a $6000 tool chain. Be sure to take notes and share.

Well, it is possible to build the firmware with GCC, I have been doing that for years, and so were others. The only challenge is Netduino Plus firmware, due to the size of default C runtime libraries (newlib) - it now can be solved with newlib-nano from GCC Tools For ARM Embedded Processors - yes, it requires rebuilding the toolchain, to enable support for 64-bit integers, but it is trivial change in the configuration script and only a few hours wait...

#61164 Non-Voliatile Storage - NVRAM

Posted by CW2 on 05 January 2015 - 03:43 PM in Netduino Plus 2 (and Netduino Plus 1)

I am betting you need something like the DDK for doing this or hack this. I find it hard to believe that it does not exist already as an assembly or namespace

You just need to call one function to update the flash memory contents (it requires a few steps to initialize certain registers and properly aligned and timed access, a little bit different than direct peek/poke). The NETMF itself uses that, e.g. during deployment, no need to implement anything but a simple wrapper to expose it. There is already such functionality implemented in Valkyrie-MT's settings feature, see his repo.

#61168 Non-Voliatile Storage - NVRAM

Posted by CW2 on 05 January 2015 - 06:54 PM in Netduino Plus 2 (and Netduino Plus 1)

Well, building NETMF firmware requires some effort - it is certainly not on the same comfort level as F7/Ctrl+B in Visual Studio, but I can ensure you it is still a piece of cake in comparison to other [embedded] projects I've had a chance to work with. And the real fun comes much later, when you need to F10 in native code

Still waiting on detailed notes .......

Please have a look at Netduino 2 Firmware v4.3.1 with GCC support. There are similar topics and wiki articles (by other community members) for basically all Netduino firmware variants.

Regarding Netduino Plus, technically it was possible to build the firmware with GCC, but due to the size of its C Runtime libraries and flash memory consumed by networking code, either some of the features had to be removed or the flash region dedicated to user application had to be significantly reduced. After release of newlib-nano - an optimized C Runtime, a part of GNU Tools for ARM Embedded Processors - in December 2012, the code produced by GCC is on par with Keil MDK (formerly ARM RVDS) output, in fact I was able to get even smaller output in certain cases (optimized compiler and linker switches for Cortex-M Thumb code generation).

The other issue with GCC was that after introduction of Cortex-M port, there were wrong build settings and interrupt-related code that did not work correctly for Thumb instruction set - this was fixed and published in 2012 (unfortunately, the repository has been deleted, but the code is included in newer releases).

Hope this helps.

#57930 Can't build STM32Stamp from PK 4.3 RTM QFE1

Posted by CW2 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).

I have not verified that, so there could be something missing. Also, it is likely the USB feature will require some additional flash space, so you'd probably need to adjust the memory layout in the scatterfile and blockrange configuration (g_STM32_BlockRange in STM32_BlConfig.cpp).

#57944 Can't build STM32Stamp from PK 4.3 RTM QFE1

Posted by CW2 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?

#57983 Can't build STM32Stamp from PK 4.3 RTM QFE1

Posted by CW2 on 07 May 2014 - 06:23 AM in General Discussion

Congratulations!

#57919 Can't build STM32Stamp from PK 4.3 RTM QFE1

Posted by CW2 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.

#57950 Can't build STM32Stamp from PK 4.3 RTM QFE1

Posted by CW2 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...

#57961 Can't build STM32Stamp from PK 4.3 RTM QFE1

Posted by CW2 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...

By content type

See this member's