Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Instantiations when switching mode


  • Please log in to reply
13 replies to this topic

#1 andersborg

andersborg

    Advanced Member

  • Members
  • PipPipPip
  • 53 posts

Posted 08 September 2011 - 06:38 AM

I'm working on communicating with a DS18B20 temperature sensor, and part of the example code in Wiring I found in Practical Arduino looks like this: digitalWrite(Pin, LOW); pinMode(Pin, OUTPUT); delayMicroseconds(5); pinMode(Pin, INPUT); delayMicroseconds(60); If I understand correctly, when using the Netduino class library I need to re-instantiate for every new setting of pin mode. Am I right? If so, this is bad design, as generally instantiations for such a simple and very repetitive task should be avoided on a resource-constrained platform like Netduino (and in general). Doing so is extremely "expensive" compared to just switching mode via a static method implemented in Assembly. Has it been considered to not require instantiation when switching modes, including between analog and digital? Cheers, Anders

#2 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 08 September 2011 - 07:08 AM

I'm working on communicating with a DS18B20 temperature sensor, and part of the example code in Wiring I found in Practical Arduino looks like this:
...
Has it been considered to not require instantiation when switching modes, including between analog and digital?

The above code does not switch between analog and digital mode, it switches between input and output, there is TristatePort in .NET Micro Framework, which has Active property to switch between input and output, no re-instantiation necessary. However, 1-Wire communication protocol requires precise microsecond timing, which is not possible to achieve in managed (C#) code, you'd need either special OneWire firmware or wait for 4.2 release, which has 1-Wire support built-in (see CodePlex issue 1167).

#3 andersborg

andersborg

    Advanced Member

  • Members
  • PipPipPip
  • 53 posts

Posted 08 September 2011 - 07:36 AM

I didn't say it was switching between analog and digital, only that I wanted that ability _too_, apart from switching between digital input and output without instantiating. I understood from other posts what you say about the timing. Very nice with upcoming 1-Wire support in the system, and I'll check out the "alpha" version. Thanks.

#4 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 08 September 2011 - 08:02 AM

I didn't say it was switching between analog and digital, only that I wanted that ability _too_, apart from switching between digital input and output without instantiating.

I see. Unfortunately, the current object model does not allow switching between analog and digital without instantiating, the design of separate classes for Input/Output and Analog-to-Digital controller ports does not count with multiplexed pins. You may want to add a feature request on .NET Micro Framework CodePlex project or propose it on Microsoft forum.

#5 andersborg

andersborg

    Advanced Member

  • Members
  • PipPipPip
  • 53 posts

Posted 08 September 2011 - 08:59 AM

I'll post a feature request. Here's a classical case (Nintendo touch screen) where it becomes hairy (and inefficient). Without Dispose I can't re-use/configure the ports, etc. Maybe not all Dispose are needed, but I went for the RAD approach. analog1 = new AnalogInput(X2); analog2 = new AnalogInput(X1); digital1 = new OutputPort(Y1, false); digital2 = new OutputPort(Y2, true); int valueX = analog1.Read(); X = adapt(valueX); analog1.Dispose(); analog2.Dispose(); digital1.Dispose(); digital2.Dispose(); analog1 = new AnalogInput(Y1); analog2 = new AnalogInput(Y2); digital1 = new OutputPort(X2, false); digital2 = new OutputPort(X1, true); int valueY = analog2.Read(); Y = adapt((range - 1) - valueY); analog1.Dispose(); analog2.Dispose(); digital1.Dispose(); digital2.Dispose(); analog1 = null; analog2 = null; digital1 = null; digital2 = null;

#6 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 08 September 2011 - 10:03 AM

Here's a classical case (Nintendo touch screen) where it becomes hairy (and inefficient). Without Dispose I can't re-use/configure the ports, etc.

Well, I don't have the device to verify it, but if you can spare two additional pins, you may be able to use trick with TristatePort and two pins wired together, and you'd not need to dispose anything. Something like the following could work:

// Touchscreen    -> Netduino
// Pin 1 (top)    -> D0,
// Pin 2 (right)  -> D1,
// Pin 3 (bottom) -> D2 and Analog In 0 (wired together),
// Pin 4 (left)   -> D3 and Analog In 1 (wired together)

var top    = new TristatePort(Pins.GPIO_PIN_D0, true, false, ResistorModes.Disabled);
var right  = new TristatePort(Pins.GPIO_PIN_D1, true, false, ResistorModes.Disabled);
var bottom = new TristatePort(Pins.GPIO_PIN_D2, true, false, ResistorModes.Disabled);
var left   = new TristatePort(Pins.GPIO_PIN_D3, true, false, ResistorModes.Disabled);

var senseX = new AnalogInput(Pins.GPIO_PIN_A0);
var senseY = new AnalogInput(Pins.GPIO_PIN_A1);

// Sense X
right.Active = true;    // Switch to output
right.Write(false); 	// 0 V
left.Active = true; 	// Switch to output
left.Write(true);   	// Vcc
var x = senseX.Read();

// Sense Y
right.Active = false;   // Switch to input (floating)
left.Active = false;    // Switch to input (floating)
top.Active = true;      // Switch to output
top.Write(true);        // Vcc
bottom.Active = true;   // Switch to output
bottom.Write(false);    // 0 V
var y = senseY.Read();

top.Active = false; 	// Swith to input (floating)
bottom.Active = false;  // Swith to input (floating)


#7 andersborg

andersborg

    Advanced Member

  • Members
  • PipPipPip
  • 53 posts

Posted 08 September 2011 - 11:49 AM

Yes, that should work, and thanks for the example, but it's essentially compensating for a software design flaw with otherwise perfectly good hardware, which is the wrong way around. Instantiation could still set the initial mode. The only thing needed would be possibility to switch modes via methods afterwards. Analog vs digital is still an issue though, as those classes have different characteristics, but solvable if done as one Port class. My touch screen implementation works fine as it is, but as I've worked with writing hardware drivers I can see the heap getting filled, cleaned up, filled, cleaned up all the time in my mind. Ignorance would be bliss :).

#8 Inquisitor

Inquisitor

    Advanced Member

  • Members
  • PipPipPip
  • 91 posts
  • LocationAtlanta, Georgia, USA

Posted 08 September 2011 - 01:48 PM

Yes, that should work, and thanks for the example, but it's essentially compensating for a software design flaw with otherwise perfectly good hardware, which is the wrong way around.


It seems to me you are expecting a flat-bed truck (Netduino) which is very good at many things to also go race with a Formula 1 Ferrari (Arduino) that is excellent at only one thing. I wouldn’t give up multithreading to get real-time ability. But then, my garage can park a Ferrari right next to the Pickup truck.

Which brings up an interesting question...

Has anyone worked with connecting the Netduino with an Arduino... through serial, spi, digital/analog pins, mind-melding etc... B)

Might be some cool applications integrating this little $19 peripheral to a Netduino. Heck... putting only the right pins in, this might be a perfect shield/daughter card for our Netduino.
Doing my best to keep the smoke in the little black boxes.
If my message helped you... how 'bout giving me a Posted Image
www.MessingWithReality.com

#9 andersborg

andersborg

    Advanced Member

  • Members
  • PipPipPip
  • 53 posts

Posted 09 September 2011 - 10:10 PM

You can do multi-threading on Arduino too, yet not as user-friendly. I think the main benefit with Netduino/NETMF is the much better development environment, but in part that's compensated by a more extensive library of drivers, faster code execution, better commercial applicability etc in favor of Arduino. You gain some, you lose some. I'd like to see a model of Netduino with a touch display, making it more suitable as a controller, including in Gadgeteer setups. I2C or 1-Wire seem like good choices for communication between MCUs in general.

#10 andersborg

andersborg

    Advanced Member

  • Members
  • PipPipPip
  • 53 posts

Posted 09 September 2011 - 10:43 PM

If you want to go wireless, this is an inexpensive solution: http://www.sparkfun.com/products/10534 http://www.sparkfun.com/products/10532 I wanted to use this solution for making wireless MIDI, but sadly it's too slow (standard MIDI is 31.25 kbps). I haven't checked whether this can be pushed up somehow. The bearer frequency indicates the information bit rate could be much higher than 4800 bps. But for many other uses it should be fine.

#11 Inquisitor

Inquisitor

    Advanced Member

  • Members
  • PipPipPip
  • 91 posts
  • LocationAtlanta, Georgia, USA

Posted 10 September 2011 - 12:17 AM

If you want to go wireless, this is an inexpensive solution:
http://www.sparkfun.com/products/10534
http://www.sparkfun.com/products/10532

I wanted to use this solution for making wireless MIDI, but sadly it's too slow (standard MIDI is 31.25 kbps). I haven't checked whether this can be pushed up somehow. The bearer frequency indicates the information bit rate could be much higher than 4800 bps.

But for many other uses it should be fine.


I've been hoping someone knowledgeable about wireless options might do a comparison and contrast. And would still welcome it. In the meantime, I stumbled across this one Wireless Comparison

Also andersborg,

For a little more (actually cheaper than your suggestion if you needed to do duplex) you could go with this one which has a data rate of 115 Kbps, with buffering, duplex and plenty of other features for $7

And for a little bit more you can get this multi frequency unit which has even more features… why, I don’t know, but it has extra 8 bit ADC, temperature sensor and RX and TX FIFO, and low battery detection for $12.
Doing my best to keep the smoke in the little black boxes.
If my message helped you... how 'bout giving me a Posted Image
www.MessingWithReality.com

#12 andersborg

andersborg

    Advanced Member

  • Members
  • PipPipPip
  • 53 posts

Posted 13 September 2011 - 08:30 PM

I've been hoping someone knowledgeable about wireless options might do a comparison and contrast. And would still welcome it. In the meantime, I stumbled across this one Wireless Comparison


My opinions, seeing it from an overall perspective:

These 433 MHz modules are in my opinion the lowest you can go (price and functionality) in terms of getting any wireless communication at all (except home-brewed solutions). They have a lot of drawbacks except for pure "wireless serial" applications though.

The more expensive 802.15.4 modules work fine too, but are considerably more expensive and are still not directly compatible with everyday equipment like broadband routers, PCs, mobiles etc.

Wi-Fi is the best overall local wireless solution in my opinion, when you consider that it provides Internet access (via an access point), smartphone access (think the phone as a control panel / remote, potentially using custom apps) and potentially also MCU-to-MCU communication (but see above for that). What is not so good is the cost. Power consumption might also be a problem.

Both 802.15.4 and Wi-Fi handle many wireless devices in the same network gracefully, but Wi-Fi is much more contemporary from a network topology and usage perspective in that you simply open IP sockets to communicate with anything, including sites across the world (Pachube anyone?).

If you want a solution that works long distances and potentially globally when talking point-to-point you need GSM/3G. There are a few shields available for that. I haven't seen any CDMA modules so far. On the other hand, point-to-point communication is not so important if the device is static, as it can communicate via the Internet. GSM still beats Wi-Fi if the device is moved around, for instance by being placed in a truck, bus, boat or similar and needs to communicate independently of other equipment, possibly combined with GPS and other means for locating/tracking vehicles.

For a little more (actually cheaper than your suggestion if you needed to do duplex) you could go with this one which has a data rate of 115 Kbps, with buffering, duplex and plenty of other features for $7

And for a little bit more you can get this multi frequency unit which has even more features… why, I don’t know, but it has extra 8 bit ADC, temperature sensor and RX and TX FIFO, and low battery detection for $12.


"Pins spaced by 2 mm." Oh heck!

"Look for a breakout board coming soon!" Someone should make a shield.

In any case both these are probably much better than the solution I bought, for a similar price.

This is how my modules look like: http://twitizer.com/q6y7M (sorry for the flickery photo)
No doubt very easy to connect to a Netduino or Arduino, so I'll still try them first. Maybe I can scare them up to 31.25 kbps somehow. The problem is that it needs to be sustainable speed, so buffering won't help polishing off the peaks.

Thanks for the hint.

#13 andersborg

andersborg

    Advanced Member

  • Members
  • PipPipPip
  • 53 posts

Posted 13 September 2011 - 08:37 PM

The breakout board variant is needed for easy use, yet Netduino + proto shield + breakout board with RF module seems like a long and unnecessarily costly way to RF Nirvana. Oh well... http://www.sparkfun.com/products/10154

#14 andersborg

andersborg

    Advanced Member

  • Members
  • PipPipPip
  • 53 posts

Posted 13 September 2011 - 09:07 PM

I forgot to mention Bluetooth. That's also a viable choice as all mobile phones and many laptops have integrated Bluetooth. It of course also works for point-to-point MCU communication, but as such is rather costly, like 802.15.4. Internet communication is not straight-forward when compared to Wi-Fi. You can use a mobile phone as a GSM modem via Bluetooth, but then that phone needs to be on and in proximity all the time, hence dedicated to the task. Certainly not ideal. For that a GSM shield would be better. If you have a phone/sub you can spare, you could also connect the phone via a USB Host shield for the same effect. There's code for that to Arduino, but to my knowledge not yet to Netduino. I'm actually checking out the USB Host approach for a telematics solution. I don't know if a Netduino with Bluetooth could act a Web server to a phone or a PC, and that way provide an integrated user experience. At least you should be able to use the Bluetooth HID profile, but some research and coding might be required for that. The cost is also a relative hindrance. Example: http://www.sparkfun.com/products/582




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.