Have a look at the firmware source something like the spi code in the firmware shows how to expose c to netmf, another option is to use serial, spi, i2c etc. For comms and a separate mcu for the existing c libs, kinda like how the go is architected...

Have a look at eevblog.com Dave has just posted a couple of vids on voltage multipliers, might be a good start for getting the voltages youwant... Nak.

Rtc module/shield maybe?

Secret labs releasing a flux capacitor for hobbyists????

different image today, don't know about the top line, but 1332AD9 is 20130521 when converted from hex to decimal.... Coincidence that that's the same day ms is unveiling new Xbox.... Hmmmmmm Nak.

Personally I have always treated the netmf source as the documentation, but I fully agree more documentation would be a boon. I personally feel documentation is an issue across the whole netmf community not just netduino. That said there is a lot of info in the porting kits chm files. I often look to netmf for delivering applications and using as a controller, then implement in c or asm bespoke functionality as a separate (hardware) module, also makes ut easy to reuse the functionality with other platforms and also for evaluating new platforms... Nak.

Yes it will but you need to update the mdk scatter file, I found the rvds settings to be a good starting point, you may need to tweak the memory offsets though. Nak.

Everyone has to start somewhere

 

Glad its working now.

 

You can give your PC a static IP if you wish it to remain the same regardless of whether you are connected to your LAN or not.

have you tried not prefixing the address with http:// ?

Nicely done!

Try using the machine name you are trying to connect to rather than IP address, IntegratedSocket does a DNS lookup to get the host IP address.

 

https://netmftoolbox...l/latest#354407

 

Have a look at the connection method.

 

The following should work:

new HTTP_Client(new IntegratedSocket("http://your-pc-name", 80))

Also ensure that port 80 is open on the firewall.

 

If that still doesnt work for you, i would create a new class which inherits from SimpleSocket and simply copy over the implementation of IntegratedSocket and modify the connect method to not do a DNS lookup and instead use an IP.

 

Nak.

The way i have done this in the past was to use as compact a serialisation as possible for the data you send to and from the ND.

 

In theroy you could use json and write a (very) minimal parser to run on the ND, but i found csv or other character delimited string format the easiest (and most effcient as json parsing requires lots of spits etc.) to work with.

 

Personally i would create lots of api actions on the server for each feature you wish the ND to perform and simply post or even get the data to the server using one of the many samples available on this forum for http comms.  As for dealing with responses i would just return a string (text/plain mime type), then split on your delimiter and parse out nd function to run and value.

 

I tend to use the Netmf tool box http client for all things HTTP

 

http://netmftoolbox....ailable classes

 

Hopefully the sample there will be enough to get you started.

 

Nak.

Hello, i notices in the Netduino Plus 2 specs that the input voltage is now down to 7.5 - 9.0 VDC

.

I also checked the voltage regulator is a  MC33269DT-5.0G which can handle up to 20v as you mentioned earlier.

So i would like to know if the page http://netduino.com/...plus2/specs.htm is up to date ?

 

why is there a difference between the netduino plus and netduino plus 2 input voltage? is it on purpose?

Can i still plug a 12v power supply on the netduino plus 2?

 

My understanding is that the change of MCU (from an Atmel to a ST device) required a change in the psu characteristics, and a lower voltage will less stress the regulators etc.  as a stock ND does not have any heatsinks attached to the devices and instead relies upon the PCB to dissipate heat.

 

That said you could probably get away with 12v but you will probably find that the ND runs noticeably hotter than at the recommended voltage and potentially shorten the life of your ND, so i would say stick to powering your ND within the published spec, and if you decide to try a higher voltage you do so at your own risk of magic smoke escaping from the ND

 

Nak.

Do you really need DHCP for a (i assume) home network?

 

Personally i always keep at least 20 ip's out of the DHCP for static and/or multiple ip's etc. typically 192.168.1.234 - 192.168.1.254

Even if you dont take the IP out of the DHCP pool if you set your ND to have an IP of 192.168.1.253 its highly unlikely that your router would ever allocate that IP (unless you manage to get 252 other devices connected to your network) as SOHO routers tend to always allocate up the range i.e. lowest numbers first

Looking at the data sheet, it looks like you could monitor the RDY state by querying the status register.

 

The serial interface can operate in 3-wire mode by tying

CS

low.

In this case, the SCLK, DIN, and DOUT/

RDY

lines are used to

communicate with the AD7788/AD7789. The end of conversion

can be monitored using the

RDY

bit in the status register. This

scheme is suitable for interfacing to microcontrollers. If

CS

is

required as a decoding signal, it can be generated from a port

pin. For microcontroller interfaces, it is recommended that

SCLK idles high between data transfers.

 

The gist of this (if i am understanding the data sheet properly) is that you could connect the device as a standard SPI device, and then just read out from the status register the state of RDY.  Another option for the device would be to put the device into continuous read mode (power on default i belive) then it will just clock out the value of the ADC when you apply SCLK to the device...

 

Hope that helps

 

Nak.

You would definitely want to use an external PSU for that number of LED's.

Personally i would build the regulator circuit using a reference design for a 7805 or 7812 (depending on required voltage) regulator, then use that to power the displays and associated logic.

The only connections i would have to the ND would be to the data pins to set the right addresses on the multiplexer and display driver IC's.

I would also consider using some Opto isolators to protect the ND's data pins in case of short or something like that...

 

Hope those pointers help

 

Nak.

oops.

i can see that i was too fast in my post.

 

i was directing that to: mtylerjr

and was quoting his post to you.

 

sorry for the confusion.

 

mtylerjr - do you think you can answer the question?

 

thanks.

 

You would need to create a RS485 interface to the ND first, i think Maxim make some SPI controllable chips that do that, once that's working you would need to get the specs of the readers protocol and program the ND to communicate with the reader. 

 

Reading shouldn't be a problem, but you may find that writing is not possible as the vendor may well have keys set up on the cards to prevent unauthorized writing.

 

If you can teardown a reader and see if its a commercial reader rebadged by the vendor, most access systems i have dealt with (used to work in the cashless vending/access control business) have used off the shelf modules rebadged so going to the module makers site has often given me the full data sheet for the device.

 

Nak.

I used to work with serial RFID devices on a daily basis and actually had all the main (MiFare, Prox, legic etc.) RS232 based readers working fine with a ND.

 

First of all can you connect the reader to a serial port on your PC and read the tags serial number into hyper terminal/putty?

That will help in determining if the reader has been set up correctly.

 

Once that is proven working the hex conversion is pretty straightforward (i will post some example code when i get home from the office).

You will often find that if the device returns text to hyper terminal i.e. you present the tag and the serial number is displayed then the hex you can see in the received comms is actually ascii codes.

 

i would recommend using the Netmf Toolbox on codeplex and the Chars2Bytes & Bytes2Chars functions which will take care of the conversion for you, i.e. if you have your serial comms set up right on your ND feeding the response into Bytes2Chars should give youa a char array of the ascii values returned.

 

Nak.

Have you tried a full rebuild before deployment?

 

I.e. Build Menu --> Build Solution (Or Ctrl + Shift + B if you like keyboard short cuts) 

 

Also have you tried disconnecting your ND from your computer and reattaching it?

 

Sometimes just restarting VS/Closing and reloadingyour solution can make this problem disappear.  Also check that your AV software excludes your build directories as not only will it give you a considerable build speed increase but can stop some problems with builds in general (this applies to all VS development, not just NETMF stuff).

 

Nak.

http://www.hanselman...IISExpress.aspx You have to jump through some hoops to get iis express to serve on port 80, (and 443) but its quite easy once done, also look out for things like skype or WebDeployment service locking port 80 and preventing other services from registering against it. As for MVC4 based REST web services have made a few for commercial projects. just keep the responses as terse as possible to conserve resources on the ND.

There is a lot of personal preference when it comes to these sort of things, the day job dictates that i have quite a rigid coding standard to work to, and readability for me is the #1 consideration. As for proof of concept vs production standard i learnt the hard way a long time ago that its better to treat everything as production as you would be amazed of the number of QDF's (Quick Dirty Fixes) that become production systems and then become a nightmare to maintain... (you can only refactor bad design so much/apply lipstick to a pig). Obviously i am somewhat biased to my way of thinking, but i would like to stress this is not a case of good vs bad, or right and wrong, all ways described so far have their pro's and cons. For me readability is vital as i dont want to spend hours 6 months down the line trying to remember how something works... Nak.

Why wouldn't you want to define 14 variables?

I havnt looked very closely at the garbabge collector code in netmf, but i suspect that you would get better performance from 14 static readonly objects rather than an array or other collection. If nothing else your code would be more readable and easier to debug. Especially if you start getting out of memory errors as you will probably find that the index of the array changes each time you encounter such an error, also you have to take into account the overhead of a static array, index variables and 14 outputport objects, (which are not static) vs 14 static objects.

Personally i would just declare all 14 as follows:

using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoPlus;

namespace NetduinoPlusApplication2 {
	public class Program {

    	private const bool InitialState = false;
    	private static readonly OutputPort Output01 = new OutputPort(Pins.GPIO_PIN_D0, InitialState);
    	private static readonly OutputPort Output02 = new OutputPort(Pins.GPIO_PIN_D1, InitialState);
    	private static readonly OutputPort Output03 = new OutputPort(Pins.GPIO_PIN_D2, InitialState);
    	private static readonly OutputPort Output04 = new OutputPort(Pins.GPIO_PIN_D3, InitialState);
    	private static readonly OutputPort Output05 = new OutputPort(Pins.GPIO_PIN_D4, InitialState);
    	private static readonly OutputPort Output06 = new OutputPort(Pins.GPIO_PIN_D5, InitialState);
    	private static readonly OutputPort Output07 = new OutputPort(Pins.GPIO_PIN_D6, InitialState);
    	private static readonly OutputPort Output08 = new OutputPort(Pins.GPIO_PIN_D7, InitialState);
    	private static readonly OutputPort Output09 = new OutputPort(Pins.GPIO_PIN_D8, InitialState);
    	private static readonly OutputPort Output10 = new OutputPort(Pins.GPIO_PIN_D9, InitialState);
    	private static readonly OutputPort Output11 = new OutputPort(Pins.GPIO_PIN_D10, InitialState);
    	private static readonly OutputPort Output12 = new OutputPort(Pins.GPIO_PIN_D11, InitialState);
    	private static readonly OutputPort Output13 = new OutputPort(Pins.GPIO_PIN_D12, InitialState);
    	private static readonly OutputPort Output14 = new OutputPort(Pins.GPIO_PIN_D13, InitialState);

    	public static void Main() {
        	Output01.Write(true);
    	}

	}
}

Nak.

As Dave suggested scan the registry more info here: http://blogs.msdn.co...tudio-2010.aspx although its targeting visual studio 2010 its a virtually identical process for prior versions Depending on how robust a check you want to do you could also check the file system, although the registry should suffice. Nak.

Look what I stumbled across and thought of you lot. Just pretend to be interested in Fluke Thermal Imaging and they'll send you a 2GB card full of info about it. It might be EU only judging by the URL.
http://eupromo.fluke...uken&product=sd

Nice find, now waiting for my fluke branded micro to SD adaptor to arrive (the 2gb card will be useful as well, just a sucker for branded generic adaptors)...

I agree... I have had a hard time finding 2gig cards. I am sure I can probably find them online, but if I want to produce my ND+ based product and sell it without the SD and allow the customer to buy their own SD Card, it needs to support larger than 2gig. It really is embarrassing for the ND+ to not support anything larger. My video camera, trap camera, voice recorders and many other tools I use for Paranormal Investigation all support large cards (I even have 32gb in some).

How hard is it to get this problem resolved once an for all. This has been one of my holdups on continuing with my project as I might need to reconsider the use of the ND+ in my product and go with another type of board simply for the SD support.

I believe the crux of the problem is to do with licensing, high capacity SD cards requires a patent to be licensed, which would then cause problems for the open source aspect of the ND. Even if the appropriate licenses were obtained then the firmware couldn't be open sourced, and the cost of the license would also be passed on to all purchasers of an ND. Which IMHO wouldn't be worth while due to the loss of aspects of open source, and the easy availability of 2gb micro sd cards, Amazon carry hundreds, as do most large component suppliers, also i suspect the licensing costs and thus the rise in price of an ND would be considerably more than the cost of a 2gb micro sd with shipping included.

Nak.