The Amp Hour Electronics Podcast

A weekly show about the trends in the electronic industry.

You are here: Home / Radio Show / #12 – Dave Is Back And Blogging!

#12 – Dave Is Back And Blogging!

Dave is back! And blogging from a hotel room, just like Chris did in episode 9 of the Amp Hour. He has lots of great videos he made at Renesas Dev Con and some good stories and experiences. On to the links!

Dave recording the show in the hotel room

Play

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | RSS

That’s it for this episode. Keep your eye on EEVblog or YouTube, no videos of Dave’s presentation yet but we’ll be watching to see if he remembered to mention The Amp Hour!

Note: We still see random 502 and timeout errors which we think are still server side. Please keep trying to download the episode if it doesn’t work the first time.

Comments

  1. Another great show. <- and thats all i was going to write until you brought up the Gadgeteer and .NET micro framework. Your comments make me feel vindicated about my own convictions about the platforms shortcomings.

    I'm not against the platform per se. I am against using it as a round peg in a square hole.

    .NET is not dead. Microsoft devs love it. In the uC/uP space there was a quiet period between the original SPOT concept and the larger ARM based .NET Micro Framework devices.

    The problem with .NET Micro Framework and sizes is that it does not run native code. It uses a CLR Interpreter (Common Language Runtime). So before you've put your blinking light app on there's already a bunch of stuff crammed in there. Because it's a CLR it's difficult to protect your code. However it does mean the code is highly portable. Classes and chunks of code can be reused in the PC flavor of .NET.

    Because your app is being interpreted at real time, the thing you want to have happen in real time don't happen at real time unless you want to write kernel mode drivers but then whats the point of a high level language right?

    Anecdote: a .net Micro Framework module had been chosen for a hardware against my better judgement but there wasn't much i could do about it. Long story short: the project required RS485 where the 9th bit gets used as address signalling. .NET could not flip the 9th from mark to space as required. (which confirms my belief that there's no longer anyone at Microsoft that understand serial). So what to do? The final iteration was to add a "real" microcontroller to do that work and then throw some softball comms to the .NET device. ugh!

    So, it's fine as long as you only want to do the things that Microsoft and the people that write the HAL (Hardware Adaption Layer) have include in the classes available. The thing is that for a lot of devs coming from a PC dev space they don't have to chage gears. In my world, the argument has been made for common collections of code that are portable between PC software and firmware for devices. It's hard to argue against that notion and it works where the square peg has a nice square hole to fit into.
    It does work if you have a short lead time, programmers that can program and like to program .NET and where the solution calls for high level functions. Depending on the vendor, you have USB host + device, ethernet + TCP/IP + web services, CAN, SQL, serial (sort of), video, SD and others a few include declarations and function calls away. And the software tools and class libraries are to a large extent free.

    It doesn't work where the device has to do what you want, when you want it but won't. It doesn't work where the silicon side of the solution costs more than you could sell the thing for. <- that argument only works if you can actually get away with it using a non .NET solution.

    I think the Gadgeteer will get just as much "meh" from uC/uP people and "cool!" from PC Software people as all the other .Net micro platforms that have come out over the last 5-6 years.

    .NET was developed after Microsoft settled a legal battle with Sun Microsystems to the tune of some $20 million dollars. The argument was over some silly buggers Microsoft were doing to Java. How do people feel about embedded JVM running JAVA. Is this better because it has at least in the recent past been more open?

    Finally, i should point out that as of November last year, the .NET micro framework has been open source.
    Also, I already have some .NET micro device from another vendor, but i'll probably buy a Netduino in the near future. Just for the blog cred right?

    Thankyou, I am now vented,

    JD

    • Ah yes, I forgot about how they open sourced the framework. They did mention it and I should have brought that up because I believe I remember referring to them as the big bad wolf of sorts. My goodness though, we really did hit a nerve with you, didn’t we John?

    • Thanks Napalm. I was reading more about it as I typed up the show notes and found the link you mention as well as the message board for the Open Hardware Definition (0.4) where Phil Torrone mentions that this may be become part of a future standard (possibly at 1.0). See above for the message board link.

  3. .NET open sourced = Novell’s Mono
    Silverlight open sourced = Novell’s Moonlight
    And as JD mentioned .NET micro is open sourced.
    Not that I’d recommend anyone using any of these. My old Sansa e250 MP3 player was developed with Mono. Now it uses Rockbox. 🙂

    JD, many introductory embedded platforms are interpreted, nothing wrong with that for many applications. The Arduino, Basic Stamp/Propeller are examples. .NET is just bloated and obviously not an ideal fit for bit-banging.

  4. Hey, thanks for the mention! Listened to the whole thing, it moved a little slow at times, but it was pretty fun! Can’t wait to see more episodes.

  5. I use .NET daily but and recently started playing around with uc’s but commenters do make good point. Now I haven’t used MF so IDK if it’s better but normal NET/C# is far from ideal to systems/HW programming. However, MS also has the Singularity research operating system. Source is freely available for research purposes. The language looks very much like C# and it talks directly to the PC hardware and the drivers/kernel are made in this “C#”. Not really practical but very interesting to look.

    I’m not registered on the eevblog forum but someone there asked about DIY high performance data acquisition. I don’t know anything about that but googling for some DIY projects I came across DIY PCI card on protoboard project! Pretty cool.

    http://elm-chan.org/works/pci/report_e.html

    I’m also interested in using proto/stripboards for one-off projects, because they can be had for less than $1 a piece.

    On the same page I found some really nice SMD *direct* on protoboard.. Woah! How did the dude solder those wires, pretty amazing.
    http://elm-chan.org/docs/wire/wcd.jpeg
    http://elm-chan.org/docs/wire/wiring_e.html

Trackbacks