Mario Vernari's Content - Netduino Forums
   
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.

Mario Vernari's Content

There have been 49 items by Mario Vernari (Search limited from 29-March 23)


By content type

See this member's


Sort by                Order  

#61279 Introducing Netduino.IP, the shiny new TCP/IP stack for NETMF

Posted by Mario Vernari on 15 January 2015 - 06:41 AM in Netduino.IP Technical Preview

I may put my modest contribution to the project, although I'd have a couple of questions...

  1. coding the stack as managed code, would offer a decent performance yet reliability? From the experience I've collected with N+/N+2, the low-level layer are the most critical section, and coding them as managed unfortunately yields to a mediocre result.
  2. is there anything "interesting" at the horizon, like...for instance...ability to compile a C# app natively?

Chris, I know that you won't disclose anything, even under heavy torture...but could you justify a bit more this decision of porting the stack on C# (apart the bugs)?

Cheers




#63471 Introducing Llilum, the native-compiled (NETMF) proof of concept

Posted by Mario Vernari on 13 July 2015 - 04:25 AM in General Discussion

This would support dynamic loading and also component evolution in a very clean and neat way, with relatively little overhead. But on the other hand, if a static system is accepted, still a lot of overhead can be shifted to build time, thereby allowing to reach much smaller microcontrollers than the one of a Netduino - and this approach would create less confusion regarding the positioning of NETMF versus the IoT version of Windows.

 

A COM-based evolution of NETMF was actually considered for the future of NETMF. But the focus for Llilum is to reach smaller microcontrollers. It should also allow for a high degree of hackability, without the need to combine different languages.

 

Of course a static binding would be simpler, but...bah...I don't know pros/cons...maybe it's me having an obsessive eye toward the pluggability.

What do you mean about "less confusion" between NETMF and Win-IoT?

 

Really was considered a COM interface for MF?

 

Finally, I agree on the "high-degree of hackability", but whenever you need some hires capture/reproduce signal, the GC makes all that unreliable. IMHO, it should be designed some "sandboxed" section dedicated to the RT drivers: a very specific extension with RT capabilities.

Whether the code is interpreted or compiled, should not matter: the sandboxed code has to behave always the same.

 

Cheers




#63460 Introducing Llilum, the native-compiled (NETMF) proof of concept

Posted by Mario Vernari on 12 July 2015 - 10:50 AM in General Discussion

Hey Paolo,

With a native-compiled proof of concept like Llilum, you still have real-world issues like garbage collectors to deal with. There is a possibility that a GC-less application could be built, and there is a possibility that a GC which honors determinism around interrupts is possible. But to be clear none of these are announced features--or necessarily on the roadmap. It's all very early still, and we're just super-excited for the new bits.

Chris

 

I think none would need (strictly-speaking) a Real-Time-Netduino, otherwise you'd opt for a different beast, and -yes- maybe programming in some native language.

Instead, I believe the typical req' of the Netduino user is the ability to interface with some I/O: that is, bit-banging, hi-res capture, etc.

 

So, all the Netduino would need is some hacky-ability to plug a native-coded section. Let's say the "Go" idea, but full-software solved.

I remember an user of this forum, who was very smart, and created kinda "hook" so that the regular C#-managed code ran together with machine-language bits of program.

I always thought that was the right direction although his own solution was actually too cumbersome to use.

 

Just think to an Arduino-sketch (better: template) against a bunch of Netduino APIs, and the result should be linked to the main app. Although a static linking would require way less resources, I'd rather look in the dynamic one: paying more, but the benefits are satisfying.

Maybe a tiny-tiny Windows COM interface or so...

 

My two cents...




#61448 raspberry pi 2

Posted by Mario Vernari on 02 February 2015 - 01:11 PM in General Discussion

RPi is a proven device, also available in an embedded format (compute board).  They probably sold more today in 11 seconds than all others combined forever. It's barely second all time to Arduino, which IS a prototype platform like the Netduino.   If the hype to open source .Net to linux et al ever happens, it's just 1 more thing on a successful product regardless, but certainly not a dependency.

 

They sold thousands of boards for true, but the quantity does not make the hardware more reliable over another one.

Again, the board ships with *no* flash, so you must connect a SD. Would you rely on a SD connector durability (dust, oxidation, etc) along 1+ years in a normal city climate?

Have a look at some comparisons between the PI1 and the BBB:

http://makezine.com/...aglebone-black/

 

I can flash an app to a Netduino/Arduino and forget it for years (possibly avoiding the pins connection as well).

 

 

When you can get a PI for $35.00 why would you spend $60.00 on a Netduino 3. Especially since Windows 10 is going to run on Pi 2.

 

https://dev.windows....Program-for-IoT

 

Again, I'd wait for "singing in the rain" until some concrete signals are coming...

I've heard the Galileo and the Edison support, but nothing concrete. There's also a Compact porting for the BBB, but without much support.

 

By the way, the current Netduino and a "bigger bro" will have several differences, that you can't wipe off with a bunch of bucks less.

Here are some:

  • power consumption
  • power-up time
  • hardware support (I mean *how* to write your own driver, *how* to port your own board, etc)
  • NVRAM support
  • software stability (I mean porting support)
  • actual processing speed (the MF is way lighter and OS-less than a regular Windows)
  • licensing price?...this is unclear.

Somebody says it's free, but WEC 2013 is also "free" unless you use for commercial applications (i.e. not hobby/prototyping)...

 

I want to see some real-life app, both headless and UI, then I'll decide whether that's a good news or not.




#61434 raspberry pi 2

Posted by Mario Vernari on 02 February 2015 - 06:50 AM in General Discussion

I wouldn't open my Champagne bottle....yet.

R-Pi is much a muscle-toy than a reliable board: consider it has no flash on board. The Netduino has its own limits, but it's way more reliable than R-Pi. Whenever someone will talk about BeagleBone, that would be another story.

Anyone reminds the "revolutionary" Galileo and Edison? Anyone could point a decent support for them?

 

Honestly, I still haven't see anything "revolutionary" in the MS world. Maybe the most awaited thing they SHOULD publish is the ability to natively compile the C# code, and (for the MF world) the ability to create native drivers without recompile the whole framework.

 

In my drawer there are a BeagleBone and an Intel Edison still waiting, but on my breadboard there's a Netduino working.




#61449 raspberry pi 2

Posted by Mario Vernari on 02 February 2015 - 01:22 PM in General Discussion

...just forget...

MF does have sense...if MS will *SERIOUSLY* develop it...otherwise I totally agree that PI or whatever else board will replace it.




#64340 LCD-Boost library for Netduino

Posted by Mario Vernari on 20 October 2015 - 12:00 PM in Project Showcase

Sorry for being in late.

The boost library leverages its performance by a hardware trick: you must use it, otherwise the library not only won't help you, but even won't work at all.

The Stefan's library is more intuitive and maybe more straightforward to wire, but you can't get it faster because the interpreted framework. That's because I used a hardware solution as a workaround.

 

From your photo I realize that you already finalized the hardware. I believe there's no clues for pushing the speed greater...

Cheers




#61547 News from the MBN team

Posted by Mario Vernari on 07 February 2015 - 05:04 AM in General Discussion

Very nice, but you'd to file this post under the "Projects showcase" category for better visibility.

Thanks for sharing.




#64472 How to interface and measure a capacitive sensor?

Posted by Mario Vernari on 10 November 2015 - 08:11 AM in General Discussion

Fine!

Just a word about the oscillator...

The frequency of that circuit is something like: f=K/(R*C), where K is a constant.

The relevant thing is that a capacitance-delta is behaving in a hyperbolic way to the frequency. That is, even a small fluctuation of the capacitance (or resistance) will actually produce a huge shift of the expected frequency.

You should avoid coupling high R with small C: leave the oscillator running fast and count how many pulses it feeds in some "capture" input. Any cheap *duino is able to count MHz without any problem.

 

We don't use Davis' products. Our rain detector is basically a water flow meter. However, that's *not* a product of our labs: we just use it.

Cheers




#60803 Modbus-TCP library

Posted by Mario Vernari on 26 November 2014 - 12:32 PM in Project Showcase

Hi Mario

I set up a modbus TCP client, but I'd need to send registers in string format. Could it be done?

 

Thanks

Alessandro

 

Ciao Alessandro.

If you mean Modbus ASCII, then the answer is "no". However, you may create your own codec for such a standard. Have a look at the RTU codecs, and the design is easy enough.

Riciao




#64492 How to interface and measure a capacitive sensor?

Posted by Mario Vernari on 12 November 2015 - 07:56 AM in General Discussion

I never said the circuit is not working: I've said that's very critical. I mean that if you're going to create more-than-just-one circuit, you'll have to re-tune each one, because the inherent error, tolerance and whatever will lead to (even to) dramatic different results.

 

A typical resistor is given at 5%, but you might find at 1% as well. The capacitance of a comb plate is due to many factors: exposed surface area, dielectric, and distance. Thus, upon a temperature range of, let's say, 0 to 40°C, you'll have a very different C, despite the same rain fall.

 

Have a try, and you'll face the problem. However, if you're going to create a single one, okay, you can tune it perfectly, table its trans-characteristics on software and plot a real behavior upon rain and temperature.

 

I really didn't want to fire discussions: just to alert other readers that the problem isn't simple!

Cheers




#64465 How to interface and measure a capacitive sensor?

Posted by Mario Vernari on 09 November 2015 - 08:27 AM in General Discussion

I don't think you'll get decent (i.e. accurate) results with a simple oscillator: the capacitance is pretty small and also spans along a short range. Moreover, as you correctly pointed out, the Netduino itself won't be able to capture a so high frequency, although I believe you'd have hard time to read it with an Arduino-like board.

Such a sensor is surely cheap but much reliable: it's just a comb-shaped pair of plates, which offers a different electrostatic behavior upon the quantity of water on it...

Water? how this water is composed? what if the rain is mixed with sand, since often we experience red-rains due the African desert wind?

 

I don't know if that might help you, but we faced the generic "weather" station a while ago, for real cases, not just hobby/home purposes. We've a complete set of sensors for accurate telemetry, even without TCP/IP layer and for pretty long distances (up to some km).

Have a look  here, just for your information...

http://www.cet-elect...ti/sensors.html

 

Cheers




#61707 Serial ports and Bluetooth I/O and GPIO output

Posted by Mario Vernari on 24 February 2015 - 06:27 AM in Netduino 2 (and Netduino 1)

If the characters arrive with a relative "distance" (in terms of time) each other, the original snippet should be good. I wondering how could happen whenever a long stream of bytes arrive at once.

 

At this point, where's the problem on inserting the I/O control inside the loop?

 

BTW, I believe the Netduino could be a bit touchy: remove the "until the end of the Universe" comment, then re-run the program...that might yield a way better result.

 

Cheers




#61705 Serial ports and Bluetooth I/O and GPIO output

Posted by Mario Vernari on 24 February 2015 - 04:50 AM in Netduino 2 (and Netduino 1)

Hello Who.

Instead of using the event, fire a thread endlessly running which consumes the bytes incoming (basically the event handler content).

I think should be more reliable as timing, because the events are dispatched sequentially, but there's no guarantee of accuracy and you may experience a messy stream...

 

Anyway, I'm not sure to understand what you want to do.

Do you want the Netduino:

  1. receive a message from the serial, then
  2. process the message by de/activating one or more I/Os, then
  3. send an answer out on the same serial

Is that what you want?




#61763 12 water flow sensors 160ft away from N+2

Posted by Mario Vernari on 03 March 2015 - 05:37 AM in Netduino Plus 2 (and Netduino Plus 1)

Not clear the cable length...supposed a midway N, each yellow wire could span around 60m?...or 60m is the total cable length to reach *all* the sensors?

 

In general, it's difficult to grant a reliable connection (both in terms of supply and sensor signal) over a so long cable length, especially when there are *many* "branches".

  • If I had to create something similar for my condo, I'd follow those guidelines:
  • The wiring should be "chained" and not "starred", unless the branches are driven independently. That's because the length of the cable can produce standing waves, which scramble the signal (or cancel it at all). Of course, a chained connection might be unpractical, thus the hardware by the N gets more complex.
  • Since the cable length is pretty relevant, the voltage supply should be higher than required. That's for both voltage drop along the cable and noise injected. For instance, using a normal 12V DC (or AC) PS, then a small regulator by each sensor (e.g. 78L05): http://www.ti.com/li...ink/lm78l05.pdf
  • The cable should be (read as: must be) shielded. For simplicity, a two-cored (signal+power) and the shield as ground.
  • Supposing the water sensor as a simple on/off switch, feeding this signal as-is isn't reliable, because any spurious noise injected can toggle the N input easily. A more reliable way to "send" the on/off is using the current loop, but is a little more complex than a simple connection.

 

HOWEVER, In general, over a long cable, especially with branches/intermediate nodes, the power supply isn't carried (unless special "power" circuitry) and the signals are modulated over a carrier, so that the bandwidth is narrow and pretty immune to external noise injection.

 

My suggestion is to dramatically change the way to connect the sensors as follows:

  • Search in the Internet a decent RF transmitter (lo power, due legal restrictions), possibly one with some encoding logic so that you can "recognize" each one, when it sends a message. There are some with a small MCU Arduino-like, which is easy to program by yourself. Also favor the ones which offer kinda "idle" state (microamps current when doing nothing). You'll have to buy as many transmitters as the sensors are.
  • Grab ONE related receiver to place close to the N.
  • Place the N+receiver in a smart position so that the signals of all the sensors reach the receiver without criticity.
  • Consider to power each sensor+transmitter with a battery (suggested) or a PS.

 

You don't need a real-time monitoring, and the sensor MCU could collect the signal then send the result sometimes only (e.g. once a day). Tricks like this one can last the battery very long yielding the sensor hardware relatively simple.

 

Hope it helps.




#61435 Things we can learn from GHI

Posted by Mario Vernari on 02 February 2015 - 07:04 AM in General Discussion

I'm not going to lie, GHI has a much better community. Why?

  1. Trained experts supporting new comers VERY well.
  2. A very reliable Gadgeteer production.
  3. Many members can show their custom made parts.
  4. Their "Codeshare" is a brillient place for Drivers.
  5. Though not as open source, good structure and gameplan.

I hope we can all learn from this.

 

What should we learn?

It seems to me that, especially on the "hot" Netduino era, this forum was plenty of enthusiast people. Also many of them were experiencing the Netduino forum as a "big family", full of warmful users.

 

Gadgeteer, in my mind, is a flop. Nothing more than a flop.

My philosophy endorses the KISS principle: http://en.wikipedia..../KISS_principle

The Arduino board boomed because its simplicity, as the same was for Netduino...

 

Many projects created on Netduino are still alive and used even on other platforms: why do you say the users "didn't show their parts"?

If you mean about hardware, I may agree, but it's not because the forum, but because the users. Honestly speaking I often see users refusing to learn a bit of electronics...what else?

 

The problem isn't Netduino, but MS which almost dropped the MF project. That's a big blame, at least in my opinion.




#61441 Things we can learn from GHI

Posted by Mario Vernari on 02 February 2015 - 08:44 AM in General Discussion

Also an over enthusiastic admin who deletes posts and has an interesting marketing perspective....

 

Uh? Could you explain?




#61828 12 water flow sensors 160ft away from N+2

Posted by Mario Vernari on 10 March 2015 - 05:18 AM in Netduino Plus 2 (and Netduino Plus 1)

Emilio, just got in touch with you on FB....

 

The Baxter suggestion is valuable, and follows the first one I gave you (scroll to the top). I don't know these ESP boards, so if I were in you I'd grab a couple in order to put my hands on. The price is almost irrelevant, and even in the worst case you may use them for another project.

The only problem is that the N has not a wifi shield, and you must add an external router, as Baxter pointed out.

That in case the wireless solution is acceptable.

 

If you want to pursue the wired solution, you'd need just ONE Arduino for all the apts.

All the 12 cables head to an OC, each one. The Arduino will face all the 12 OCs, then it exchanges data (e.g. via UART) with the N. Most likely, will be the N querying data to the Arduino, and not vice versa...that's for sake of simplicity.

 

Emilio, I believe it's up to you evaluate what's better for your condo.

Again, if I were in you, before starting with a very well defined solution, I'd make more than experiment. That without purchasing too much (useless) material.

 

Good luck!




#61774 12 water flow sensors 160ft away from N+2

Posted by Mario Vernari on 04 March 2015 - 05:40 AM in Netduino Plus 2 (and Netduino Plus 1)

First off, your dog looks awesome!

 

Secondly...OK, I didn't read about the sensor and its specs.

If you want to stay stuck with cables and a cheap solution, I'd suggest to walk the project step-by-step, together with tests and measurements. In general, a long-cabled solution requires relatively complex approaches. In your case, you may follow a custom-made yet -tailored solution, which hopefully will yield decent results.

 

Here is how I'd do...

  • As you wish, the topology will be the N somewhere in the middle, then a "starred" cabling from the N to each sensor, possibly optimizing the cable length (also due its cost), but also avoiding to run it close to appliances which may create noise (pumps, electric cabins, etc)
  • The cable will be a twin-cored shielded cable. An audio (600 Ohms impedance) cable should fit fine, but there are also cables designed for alarm systems: they're multi-cored and shielded, but they might be cheaper than the audio one. Consider the robustness, endurance and even the flexibility. Although you may smile, often we consider the "taste" because mice and other rodents seem liking to eat cables...no dogs so far, though!
  • The cable, by the sensor side, should be connected to the sensor itself and nowhere else. I mean the shield won't be connected to any ground, than the black wire of the sensor. On the N side, instead, the shield (together with the N ground) will be grounded as well as possible.
  • Consider to enclose the N in a waterproof (plastic) box. Its resistence to the water/dust/etc should be the better the worse is its final position. If you'll place in a protected room, that will be better, of course. Take care if you must wire mains in a very wet position, instead. In such a cases, PLEASE ask an electrician or someone certified!
  • Since the sensors are able to accept up to 24VDC, I'll take advantage to use a higher voltage than 5V. A good 24VDC PS should be fine, but maybe keeping a bit far from the max level would be even safer. Are able to find a 18-20VDC PS? The required current is below 1A for sure, so its price shouldn't be a problem. FAVOR an "old-style" PS, than a switching one because the noise it produces. An old PS "wastes" a bit more of energy, but in your case I believe is better.
  • Of course you can't connect the yellow wire directly to an input, because the too high voltage. The voltage adapter could be solved with a simple diode (for each input), but I STRONGLY suggest to create a more sophisticated interface. The reason is right to the N safety: without some kind of robust "shield", an hazard (even electrostatic or a lightning falling in the nearby) may enter up to the MCU and blow it. In my opinion, despite the bit more hardware required, it's worthwhile...and way cheaper than a brand new N.

 

Let me some time to draw you a small sketch to interface the sensors by the N side.

Let me know what you think, in the meantime...




#61778 12 water flow sensors 160ft away from N+2

Posted by Mario Vernari on 05 March 2015 - 05:50 AM in Netduino Plus 2 (and Netduino Plus 1)

Emilio, my suggestions come for a price: you must take a picture of Nina and post somewhere, so that I can admire her. I'll post a picture of my cat as well (if you've a Facebook account, we might get in touch and the photos are already visible).

 

I forgot the very most important thing to the list of tasks: create a prototype with 1-2 sensors in order to refine, adjust and possibly change something not working fine. This is, IMHO, a mandatory step for any decent project, but many people don't like it and prefer to go straight to the final stage. Although we may think and think again, there's no better way than make a reduced test and see what's going on...

So, please, grab a small breadboard like this one, and follow the prototyping approach first.

https://www.sparkfun.com/products/112

 

NOTE: I'll show you Sparkfun links just because it's a worldwide commonly known shop, but of course you may search for something equivalent/better. I mean that I have no reason to sponsor this or that Company.

 

Well, I though a little more about the wiring and how to reliably interface and it came in my mind a pretty simple, safe yet cheap way to connect them all: optocouplers.

I'd pick a couple of those for a test, just to understand pros and cons:

https://www.sparkfun.com/products/9118

You could also grab this one, which is quad and cheaper, but comes without PCB. If you aren't scared to put your hands on resistors and so, favor this one!

https://www.sparkfun.com/products/784

 

The optocoupler is kinda Columbus' egg: it allows to use a normal PS for the sensor side, but completely insulate the N side. Even in case of an hazard or so, the N will be safe. The cable is also a simpler choice: a RG59 is too much. Just search for a decent alarm cable (I don't know the price), because you need THREE wires: ground (the shield), +V and output.

An example: http://img.diytrade....Alarm_cable.jpg

 

At this point, the PS could be a normal +12VDC (rated for 1-3 Amps) or, if you like, you may also grab an old laptop PS, which should be a 19VDC 3A or so. Don't get crazy for searching something more complex.

Upon the chosen PS, the optocoupler's resistor will be calculated accordingly, otherwise the embedded LED will fry.

 

Once you have an optocoupler (=OC) as insulator, the N side is a walk in the park.

The OC output is just a transistor which "shorts" upon the paired LED will light. You could wire the OC's emitter to the ground, and the collector directly to any N input. Bear in mind that you need a pull-up resistor, otherwise there would be no activity.

 

Here is the trickiest part...

The sensor's specs say that it toggles the output at a rate of up 60Hz (i.e. about 17ms). The problem is that you'll have 12 sensors, which asynchronically feed pulses tot he same N. Now, although 60Hz is perhaps an exaggerated value, you should consider a pessimistic context: let's say ALL the sensors at 20-30Hz. I found that a normal shower takes 15-20 liters/min. Think 8AM, when almost all the apts are taking showers.

So, the N will face an equivalent pulse rate of 200-300Hz, that is an interrupt every 3-5ms. And probably it has to manage other things...

 

That's because I though there would be a "software" problem more important than the hardware one.

My suggestion (just brainstorming, as I were doing that for my condo) is using an "Arduino" pre-stage for the dirty work. In other words, the Arduino (any flavor you like) should be the real board facing the OCs, so counting all the pulses. Since its native elaboration, it won't have any problem on reliably counting all the pulses. Then, supposed the N for doing something smarter (such a web or so), the N could pull the data out the A via UART for example, which is trivial.

A bonus coming for free in this scenario is the relative reliability of the system in case of power failure. Of course there are no more pulses incoming, but it would be a dumb project if the counter values were lost due no-persistent storage. So, you might: back-up just the A with a small battery, or (easier IMHO) simply write the counter values in the EEPROM of the A. In the latter option, you should avoid to write the EE often, but it's no hard to add a small "voltage level detector" so that you'll write the data upon the power supply is dropping.

 

I'd say that it's possible that you need some small capacitor as well, but that's part of the prototyping.

 
Let me know what you think...



#61480 Help me out with SPI Please.

Posted by Mario Vernari on 03 February 2015 - 06:31 AM in Netduino 2 (and Netduino 1)

The Netduino 2 Plus had some issues related to the SPI, and should have been fixed with the latest firmware.

That was sure for the Netduino Plus 2: not sure about the simpler Netduino 2.

 

Those issues were mostly related to the worse SPI hardware logic in the ST chip, than the older Atmel.




#61140 Just discover Netduino!

Posted by Mario Vernari on 04 January 2015 - 07:47 AM in Netduino Plus 2 (and Netduino Plus 1)

Here is my (modest) contribution...

 

I believe that iced98lx answered mostly fine, although I never liked Go! nor Gadgeteer.

Netduino Plus 2 is a very nice board, which *never* leave you disappointed, except when...you'll enjoy so much, that you wanna have more, and...there's NO more than a Netduino.

This is the biggest fault, IMHO.

 

Please, don't mind my signature comment, because derived from the huge blackout in NYC some year ago...keep it likely as a "too deep dependency of the humans from the energy"

 

BTW, I really endorse Spiked. Maybe he's very "direct", but...it's just what I've written above: the real problem is "behind" the Net MF project, and MS in general. Many, many, many announces, but nothing concrete. We use to say "lot of smoke and no roast".

I wouldn't bet a single cent on what will be the future, but it's also evident the dramatic change that MS shown after the Nadella leading.

 

Technically speaking, the Arduino board is not "much" different from the Netduino: they both have a microcontroller (MCU), they both have I/O ports, they both have their own features, limitations, etc.

What's *really* different is the firmware inside, or "what the programmer sees". Arduino offers a minimal 8-bits MCU, with few resources (RAM, flash, speed), thus there's *NO* alternative other than "the programmer must help the machine" (C language or so). Netduino leverages its super-powerful 32-bit ARM core to simplify *A LOT* the development, the debugging and many other things.

 

A frequent surprise is about the "port toggling frequency": whereas an Arduino can toggle an output in the MHz-order, the Netduino barely performs 100 times lower...and it's a 180MHz CPU!

The most straightful answer should be: write a complete HTTP app (for instance), then let's remake the "comparison".

 

They DO NOT compare: they're two different approaches, which also may interact.

The Go! idea was nice: use the C#+.NetMF power for the higher level "app", then leave the lowest "physical" level task to a small, inexpensive chip. That's the right way. What I don't like is the "plug-and-play" way of doing that: the hardware is maybe the hardest thing to standardize, and most of the times, as soon you do it, it's already legacy.

However, many users like this way of "glueing" hardware: don't follow my words much, I love hacking hardware.

 

I don't know much about R-Pi or Galileo, but I think they're different beasts.

 

Have a look at my blog, there are many examples of Netduino exchanging data with serial, TCP, and to the Azure cloud.

http://highfieldtales.wordpress.com/

 

Good luck.




#61931 Controlling Multiple I2C devices

Posted by Mario Vernari on 23 March 2015 - 08:05 AM in Netduino Plus 2 (and Netduino Plus 1)

Tim, I'm 100% with you, but abstraction comes at a cost and Micro Framework tries to solve high-level problems on (relatively) very poor hardware.

Swapping the config is surely cheap in term of computation, but of course leaks in term of abstraction. However, you might think the I2Device as the "I2C logic driver", and the various configs as "instances" of this driver. Such a viewpoint comes maybe a little closer to the abstract-hardware model.

Good luck!




#61917 Controlling Multiple I2C devices

Posted by Mario Vernari on 21 March 2015 - 05:16 AM in Netduino Plus 2 (and Netduino Plus 1)

I never tried I2C on Netduino, but it sounds like other ports, which have to be disposed to be reused. This is surely a elegant yet reliable solution, but -agree- not so efficient.

Did you try to swap the configuration instead of creating many instances of I2CDevice?




#60726 Azure Veneziano

Posted by Mario Vernari on 16 November 2014 - 04:11 PM in Project Showcase

Second part is on...(scroll to top)





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.