 |
||||||||||||||
|
|
|
||||||||||||
CW2's ContentThere have been 148 items by CW2 (Search limited from 24-May 23) #57132 Accessing the Timer/Counter block
Well, there are no classes for direct timer access in the current version of .NET Micro Framework, mainly due to the fact that the managed (C#) code is interpreted and running considerably slowly than native (C++) code. IIRC simple pin toggling loop on Netduino gen. 1 can achieve ~10 kHz. Even if you were able to access the timers, you would not have much time to run managed code in the interrupt handler (if at all).
What do you want to do? #60173 Where are the COM ports located on the board?
You'd need Cadence Allegro Viewer to view the brd file, it has different format and is not supported by Eagle. You can view the pin assignment in the schematics (pdf). #59897 LLVM Based Optimizer for MSIL
There is one very interesting comment (the first one) for channel9 Visual Studio Team Interview Fun with the Interns: Santiago Fernandez on LLVM Based Optimizer for MSIL, which mentions SharpLang - a .NET (MSIL) compiler front-end for LLVM. Has anyone had a chance to play with it already? Any thoughts? #59561 Help with I2C
If I understand it correctly, the RTC works fine, but the LCD does not? You said the RTC has I2C pull-ups - do you use external pull-ups when the LCD is connected alone?
Have you checked the LCD module IC PCF8574 datasheet to verify the communication protocol is implemented correctly?
What is the LCD module supply voltage? In case of 5V, do you use level shifter to ensure proper logic levels from Netduino 3.3V outputs? PCF8574 logic high minimum voltage when powered by 5V supply is 0.7*VDD = 0.7*5V = 3.5V, so 3.3V is not enough (Arduino is 5V, so that would explain why it works).
It is not unusual to get a reply after a few days, especially when asked during a holiday season; and the probability gets lower for special hardware setups, too general and hard to troubleshoot issues ("it does not work"), without providing at least circuit schematic (photo of the actual wiring even better), the code etc. It's not the community does not want to help you, but there are just too many unknowns... #58403 Mythical "Golden Reset Pad"
The erase pad is available only on the first gen Netduinos - it is connected to the [AT91SAM7] microcontroller ERASE pin, which enables you to perform full flash memory erase. Netduino gen 2 [STM32F] microcontrollers do not have this feature, you have to erase the flash memory via software (DFU utility or using a programmer). #60299 Max Power of Vdc Rails
5V
All Netduino-s use MC33269DT-5.0G (datasheet pdf) linear regulator (LDO), which has "Output Current in Excess of 800 mA".
3.3V
Netduino gen 1 use 3.3V variant of the same LDO (MC33269DT-3.3G), which means max 800 mA, but it is connected to 5V LDO, so the effective max current will be smaller, due to losses.
Netduino gen 2 use DC/DC converter based on ST1S12GR (datasheet pdf), which has output current 700 mA (again connected to 5V LDO, so the effective max current will be smaller due to losses).
The 125 mA limit applies to microcontroller pins, not power rails. You have to subtract current consumed by Netduino onboard circuitry (30 ~ 100 mA) from the regulator output. #56639 ND1 - Input is always TRUE
Quiz question: What return value do you expect from an unconnected input pin?
The thing is that you created input pin with ResistorMode.PullUp, which means the pin is in logic high (returns true), unless it is connected to other logic level (logic low, ground). Thus, if you want your input pin Read() method to return false, you have to wire the pin to GND.
If you use a port in output mode, its Read() method basically just returns the current state - i.e. the initial state passed via constructor parameter or what was set in the last call of Write() method. #56666 ND1 - Input is always TRUE
#59675 Powering the Netduino model 1
#59431 Visual Studio 2013 official support yet?
I think the most recent is comment by Sal Ramirez on the official .NET Micro Framework blog (posted on 7/11/2014):
#56283 PT100
Short answer: the PT100 is a resistive sensor, so you cannot connect it directly to an analog input. Long answer: You'd have to use at least a voltage divider circuit, so you can measure the voltage drop over the sensor and make sure to use low current - usually up to [only] 1 mA, to prevent sensor damage and also reduce self-heating. PT100 is a precision sensor and getting accurate measurements require non-trivial circuits - for example, PT100 has about 20 ? difference in temperature range 0 - 50°C, which at 1 mA translates to 20 mV; also the parameters of microcontroller's ADC has to be considered. I'd recommend you to do some more research and have a look at articles like PT100 sensor - help a beginner? or Can't get a precise reading with PT100 temperature sensor. You might end up with the bridge configuration plus op-amps, or a specialized IC... #58172 Understanding the Netduino 2 schematics - LMV7271MF and NTR4101PT1G
The basic operation of the circuit is to switch the USB power on, when voltage from power jack drops below a certain threshold.
(*) 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 VO = (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
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). #61573 How to compile the firmware without networking support (plus 2)
Alternatively, you could simply build and flash Netduino 2 firmware on your Netduino Plus 2 board. #59591 Convert PIC code to run on Netduino
If the main project objective is NOT building a motor controller, I would consider one of the many motor controller modules or specialized driver ICs... just for inspiration Pololu controllers... #59589 Convert PIC code to run on Netduino
Why not use the PIC?
There are some issues with the current .NET Micro Framework implementation that limit its usage in such scenarios. I don't know exactly how the PIC drives the H-Bridge, but I can think of
1) Bit-banging - it depends on the frequency. Netduino's managed code is interpreted, i.e. slow. IIRC it can produce signal at 10 kHz range - I am not sure how fast you need to drive those power MOSFETs. Also, the code can be disturbed at any time, for example by garbage collector or interrupt handler, so the motor control will be stuck for relatively long time in certain state, which is not something you'd want. There are some techniques to minimize such events, but no guarantees.
2) Timers or PWM - there is missing the key feature: synchronized channels. The signals for left and right part of the H-Bridge must have precise relationship, they cannot overlap at certain moments etc. - usually, you configure two channels with opposite polarity, dead time and then start them at the same time. This would require firmware modification (the microcontroler has these features, but they are not accessible from managed code).
Personally, I would go with the PIC(s) - you've already got proven working (?) design, it is much better for real-time control, and also significantly cheaper. You can use Netduino to control them, if you must... #59528 Using Netduino to prototype & program a chip...
If I understand it correctly you want a custom board running Netduino firmware? Of course that is possible, as long as it is hardware compatible (e.g. clock frequency, inputs/outputs etc.). However, you'd need to have very good component source deals to make it cheaper (the microcontroller itself in single quantity costs significant part of the retail Netduino price, plus the other parts, PCB, assembly, testing etc.). #59417 IE support with this forum software - copy and paste doesn't work
Internet Explorer 11 - Copy Paste issue #56625 Source Control for Porting Kit and netduino
There are certainly more ways how to do it, based on personal preferences and development workflow, but you'd probably need to set up a few branches - I usually use something like this:
master O-- ... --[My 1.0]...
\ ^
netmf \--[NETMF4.3]--[NETMF4.3QFE1] ... [NETMF vNext] /
\ \ (merge) /
netduino \--[SL 4.3.1] ... [SL vNext]... /
\ /
my-netduino-changes \[Change #1]--[Change #2]... /
This allows me to have complete reference of the official .NET Micro Framework codebase (it would be easier if the Microsoft team decided to use git on CodePlex) and also vendor firmware releases. Every new release is simply added to the appropriate branch, then you can decide what changes will be merged where, if at all. Similarly, development of modifications (features, bug fixes, whatever) happens in a dedicated branch and the finished work will be merged where needed - although it might sound a little bit complicated at first, it is actually very easy to do, especially in git.
#57051 Analog Output
In addition to what Nevyn said, you could use PWM with low-pass RC filter as cheap D/A converter. #56778 Native Code in C++
Well, it depends on what exactly do you mean by "MiniJTAG"?
You'd need in-circuit debugger/programmer to deploy and debug the code, popular choices are for example ST-LINK/V2 or Segger J-Link. There are many others, but you should check VisualGDB support; they have tutorials for ST-Link and J-Link, so these two should work. They have standard 20 pin 0.1" pitch JTAG connector, so you'd need also an adapter for 10 pin 0.05" pitch mini JTAG, which looks like this or this, and if your Netduino does not come with the pin header, you'd need it too (FCI part at Digikey, or similar).
Tip: You can make el cheapo mini JTAG header from a copper wire: cut 10 pieces about 10 mm long from solid core copper wire that fits into Netduino board holes, insert them all into the female header so they stay in place and have proper length, stick through the board, solder and carefully cut the excess #56765 Native Code in C++
Unfortunately, Visual Studio does not support deployment over JTAG and I am not sure its ARM compiler can generate code for Cortex-M series. Probably the closest thing is VisualGDB. #59233 Multiple InterruptPorts being fired?
I guess the output of toggling switch UP is affected by DisableInterrupt() and EnableInterrupt() calls in the event handler - it most likely causes the other interrupts to be ignored/missed.
I would recommend you to remove those Disable/EnableInterrupt() calls; and also change the interrupt trigger to InterruptEdgeHigh, so the button release event is not generated (you can add it back again later, if you need it). Also, apparently the switch bounces, so you'd need to implement either hardware or software debouncing (or both).
You can make the circuit a little bit simpler by switching to pull-up resistors, because you can enable the built-in ones (in the InterruptPort constructor); then you'd need to use InterruptEdgeLow instead. #60025 AT91_GPIO.cpp
Not really. There are four parts:
AT91_GPIO.cpp is in 1. and 2. - these two parts you need to build the Netuino firmware. Install the .NET MF Porting Kit, download Netduino Firmware source zip and extract it over Porting Kit, overwriting the files.
.NET MF SDK (3.) must be installed to have .NET MF project support in Visual Studio and you also need Secret Labs SDK (4.) to have assemblies (.dll) and project templates for Netduino.
C/C++ source file is compiled into OBJ file, which is then linked with the rest of OBJ files and libraries into final executable, in this particular case (microcontroller) the 'executable' is in ELF format, which is then transformed into HEX (resp. SREC) or BIN suitable for flashing.
Try searching the forum and wiki for 'building firmware' or such, it has been discussed numerous times. You'd need the source code, an ARM Toolchain and a lot of patience - 4.1 is rather old... #60020 AT91_GPIO.cpp
It is in DeviceCode\Targets\Native\AT91\DeviceCode\AT91_GPIO folder. There are two versions: the original included in .NET Micro Framework Porting Kit and the one with Secret Labs modifications in the Netduino firmware source archive.
Well, it depends on the change. It is possible to change a C++ source file in a way that it does not affect the generated .obj file (e.g. adding a comment).
Open the .cpp file in your favorite text editor...
But I guess there is something else - what exactly do you want to achieve? Does it involve building the firmware? | ||||||||||||||
|
||||||||||||||
|
|
|
||||||||||||
|
This webpage is licensed under a Creative Commons Attribution-ShareAlike License. | |
||||||||||||
|
||||||||||||||
Posted by
