Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Programming Education Hardware Hacking Build

Parallel Programming For the Arduino 140

Posted by Soulskill
from the head-patting-and-tummy-rubbing-support dept.
blackbearnh writes "As more non-traditional programmers start playing around with embedded platforms like the Arduino, the limitations and complications of interrupt-driven event handling can become an annoying barrier to entry. Now a group of academics have ported the parallel-processing language Occam to the Arduino. In an interview on O'Reilly Answers, Matt Jadud of Allegheny College describes how Occam helps artists using the Arduino in their installations, and how the advent of low-cost computing platforms is changing the educational experience for proto-makers in school. 'Basically, an artist or a tinkerer or a hacker has a goal. They don't really care about learning Occam. They don't care about how this language is different from C. They just want to make a cat door that keeps their cat out when the cat comes back with a mouse. Or they want to make some kind of installation piece. Trying to focus as much on the user and the possible goals they might have is what's motivating our work right now.'"
This discussion has been archived. No new comments can be posted.

Parallel Programming For the Arduino

Comments Filter:
  • by Anonymous Coward on Wednesday June 16, 2010 @12:14PM (#32592052)

    "They don't really care about learning Occam. They don't care about how this language is different from C. They just want to make a cat door that keeps their cat out when the cat comes back with a mouse. Or they want to make some kind of installation piece. Trying to focus as much on the user and the possible goals they might have is what's motivating our work right now."

    Isn't this kind of thinking that lead us to why we have the security holes, shoddy programming, and bloat-ware today? People just want to code and not to learn the ins and outs required to craft a well-heeled, tuned, and functioning program or application?

    • Re: (Score:2, Insightful)

      by skelterjohn (1389343)

      Arduinos are allowed to have security holes.

      • I've been playing with the Arduino and ran into these examples last night. The objective of the macro below is to set (1) or reset (0) a single bit in an 8-bit register. Register PORTH is mapped to 8 pins I/O pins on the Arduino and we want to control one of them: pin 12. This is the code I found. It's very helpful in that it shows register-to-pin mapping. (Pin 12 has previously been set as an output pin.)

        #define SET_PIN12(z) ((z)>0)? PORTH |= (1 << 3) : PORTH &= (0
        • Actually, the example I mentioned above does not apply to an Arduino itself, but to an add-on piece of hardware that uses a similar processor. The Arduino language has its own I/O pin functions.
        • by mirix (1649853)

          You can just use this struct and some preprocessor magic, and then you can define pins if you won't want to bitmask port reads and writes.

          typedef struct
          {
          unsigned int bit0:1;
          unsigned int bit1:1;
          unsigned int bit2:1;
          unsigned int bit3:1;
          unsigned int bit4:1;
          unsigned int bit5:1;
          unsigned int bit6:1;
          unsigned int bit7:1;
          } _io_reg;

          #define REGISTER_BIT(rg,bt) ((volatile _io_reg*)&rg)->bit##bt
          #

    • by Trepidity (597) <delirium-slashdotNO@SPAMhackish.org> on Wednesday June 16, 2010 @12:22PM (#32592150)

      Next up I suppose you're going to complain about how Legos don't force you to learn proper civil engineering before building things?

      • by Bigjeff5 (1143585) on Wednesday June 16, 2010 @12:27PM (#32592222)

        I've been pushing for that for years! All children should have a proper engineering degree before playing with legos! I mean, have you seen what some kids come up with? Totally unworkable.

        • Re: (Score:3, Interesting)

          by jd (1658)

          I was thinking more that all Engineering degrees require a combined combined LEGO/Mecchano device as a final-year project (to demonstrate interoperability), with internship at LEGOLand.

        • I loved this fitting comic:
          http://ahoipolloi.blogger.de/stories/1531403/ [blogger.de]
          Unfortunately it’s in German, so I’ll translate:

          [Pic 1]
          Headline: New trend: Physical incorrectness!
          Builder: There’s no law against building that!

          [Pic 2]
          Headline: The pseudo-informed dogmatic laws of nature disagree.
          *Smack!*
          Builder: Oww!

      • by djd20 (1835080)
        Actually - you can run occam on Lego as well http://transterpreter.org/platforms/rcx/ [transterpreter.org] A port for the NXT is underway. (I was one of the developers of the transterpreter virtual machine which occam runs on when used embedded)
      • by ultranova (717540)

        Next up I suppose you're going to complain about how Legos don't force you to learn proper civil engineering before building things?

        Actually, they do. You either learn to build strong, light structures, or they are going to keep breaking a lot. Nothing like having a hollow plastic block be the strongest part to really drive home the principles of structural stress and why you should care about it.

    • by bb5ch39t (786551) on Wednesday June 16, 2010 @12:32PM (#32592306)
      I agree with you. In the extreme, it might lead to gas pedals sticking in computer controlled cars. Oh, wait, that's already been done.
      • by jd (1658)

        Admit it! At least the gas pedals didn't stick to the gas tank, causing the tank to rupture horribly over the over-heated engine, thus eliminating any possibility of an official complaint.
        .
        .
        Oh.
        .
        .
        Just been told that's next year's model.

    • by John Whitley (6067) on Wednesday June 16, 2010 @12:39PM (#32592406) Homepage

      Isn't this kind of thinking that lead us to why we have the security holes, shoddy programming, and bloat-ware today? People just want to code and not to learn the ins and outs required to craft a well-heeled, tuned, and functioning program or application?

      Repeat after me: programming languages and frameworks do not make developers dumber. It's this kind of thinking that forces every developer-user of a complicated system to be continually faced with issues outside of their domain of expertise, or even just the current problem focus. *That's* what causes these problems.

      For example, when doing embedded programming some years back, I noted that team members working on codec optimization were starting to crank out bad, broken ad-hoc synchronization logic to take advantage of some unique parallel hardware. Their specialties ran into numerical analysis and implementing low-level numerical optimizations, not into synchronization algorithms. I could take these folks and run them through an OS class, and walk them through the inevitable sea of mistakes...

      Or I could do what I did: I created a framework that abstracted away all of the platform synchronization concerns. They did their jobs neatly and cleanly by writing a class that contained some shared state and implementing just two virtual methods that embodied the parallel work. They were much happier, and the whole team was much happier because there was now *one* place to look for synchronization bugs. This was quickly hammered out into a very stable foundation for the other teams' work.

      Allowing our programming languages, libraries, and frameworks to do the heavy lifting so we humans can focus on the real problems we want to solve pretty much describes the history of real progress in software development.

      • Allowing our programming languages, libraries, and frameworks to do the heavy lifting so we humans can focus on the real problems we want to solve pretty much describes the history of real progress in software development.

        If you can find a way to shorten that, just a bit, to 140 characters, that will be the best tweet ever made.

      • by forkazoo (138186)

        Repeat after me: programming languages and frameworks do not make developers dumber. It's this kind of thinking that forces every developer-user of a complicated system to be continually faced with issues outside of their domain of expertise, or even just the current problem focus. *That's* what causes these problems.

        I disagree. I just think that fancy tools like Python, Qt, and Visual Studio Intellisense, all make me dumber in ways that I find acceptable. I'm usually willing to trade being slightly stupi

      • Re: (Score:3, Insightful)

        by ultranova (717540)

        Repeat after me: programming languages and frameworks do not make developers dumber.

        But they do make promises that they cannot keep. The abstractions they offer leak, so when a developer works with these abstractions, the code develops weird bugs and slowdowns.

        It's this kind of thinking that forces every developer-user of a complicated system to be continually faced with issues outside of their domain of expertise, or even just the current problem focus. *That's* what causes these problems.

        No, what forces

        • You are making the assumption that you are alone working on a project. Abstractions do leak, and frameworks have bugs. But this does not mean that it's necessary your problem to go around or fix the issue.

          While it does offer a great advantage to know the layers of abstraction beneath your code it's not always necessary. In bigger teams you can simply go to whoever made that layer of abstraction and say: "I'm having this problem with $foo, it's breaking when $description."

          In a well oiled team people will wor

    • by ajlitt (19055)

      Isn't this kind of thinking that lead us to why we have the security holes...

      I thought the Arduinos are supposed to be RoHS [wikipedia.org] compliant?

  • This just a race condition, which was taught when I was a sophomore in college(and I knew about in high school).
    • by Bigjeff5 (1143585) on Wednesday June 16, 2010 @12:31PM (#32592290)

      A race condition between two processes is easy. A race condition between three is several times harder. Race conditions between a half dozen processes? Forget about it, at least for the hobbyist.

      Race conditions can be notoriously difficult to program around. You can go from 20 lines of code to 200 in a heartbeat with just one or two of them. Get five or six, and your 20 line program needs a thousand lines to deal with it all. That's pretty ridiculous, especially for hobbyists.

      If you've got a tool to eliminate the problem completely, why would you poopoo it?

      • by wurp (51446)

        People address race conditions by adding more code? Yuck. The solution to a bug is rarely to add (significantly) more code.

        (Your first problem was using threads to solve something more suited to state engines feeding one another via queues, but that's pervasive.)

        • by Chirs (87576)

          Threads and state engines are not orthogonal.

          Generally it doesn't matter, but if ultimate optimization is key threads can give better performance than processes because the TLB doesn't need to be flushed when switching between threads.

          The cost of course is the added risk/complexity of sharing the memory map between all your threads.

          • by wurp (51446)

            Threads and state engines are not orthogonal.

            Sure, but the state engines and the thread mindset (share data and use mutexes/semaphores to control access) are.

    • This just a race condition, which was taught when I was a sophomore in college(and I knew about in high school).

      Probably because a lot of people who play with the Arudino (including me) are not professional programmers. They're largely self-taught amateurs--typically garage inventors and a surprisingly large number of artists who have probably never even heard of race condition and don't really care, either.

      • Given that it will probably take at least a few hours to get that thing working, it would take about 5 minutes to read the wiki on race conditions. That 5 minutes might save the amateur several hours.
        So please read it!

        http://en.wikipedia.org/wiki/Race_condition [wikipedia.org]

        This is actually over complicated, so consider the following example: ( It's hard to do with text, I'd like to draw a pic...nevertheless )

        Guy C takes apples every 5 seconds from Guy A and Guy B. If you give Guy A 8 apples and Guy B 1
    • Re: (Score:3, Funny)

      by Haxamanish (1564673)

      This just a race condition, which was taught when I was a sophomore in college(and I knew about in high school).

      Are you sure you were not a semaphore?

  • Or try PyMite a.k.a. Python-on-a-chip or p14p [google.com] if you really must... Also features threads and is a little more mainstream than Occam. And people do actually care about the amount of mental capacity goes to their tools while making the cat door open and close.

    • by tibman (623933)

      I think that would be too much for an arduino. Some PyMite requirements: 40 KB program memory; Initializes in 3KB RAM; print "hello world" needs 4KB; 8KB is the minimum recommended RAM.

      Arduino hardware: Flash Memory 16 KB (ATmega168) or 32 KB (ATmega328) of which 2 KB used by bootloader
      SRAM 1 KB (ATmega168) or 2 KB (ATmega328).

  • occam (Score:4, Funny)

    by Anonymous Coward on Wednesday June 16, 2010 @12:23PM (#32592160)

    occam iits sh like all lel lanparalguages.

  • XMOS (http://xmos.com/ [xmos.com]) has developed a mostly-C language with a few Occam-like extensions, which might also be worth considering. It's called XC (http://www.xmos.com/system/files/xcuser_en.pdf/ [xmos.com]).
  • by TwineLogic (1679802) on Wednesday June 16, 2010 @12:30PM (#32592274)

    There is no limit to the functionality of Interrupt Service Routines (ISR) and the interrupt-driven "event model," as the OP put it.

    Programming an ISR may be difficult, but even the topic of this post, a parallel environment running on the Arduino, will be based upon ISR routines. The user-level programs will not interact with ISRs, but the Ocaml implementation will abstract them.

    Fundamentally, the hardware will continue to use interrupts to signal the availability of data from human input devices. Therefore, the fastest and most direct way to access this data is to write an assembly language ISR. The difficulty is that embedded systems programming such as this requires specialized technical knowledge on the part of the programmer.

    Clearly the Ocaml solution posted will ease the burden on the coder, and that is a good thing. But the way it works is not that it no longer uses ISRs. It almost certainly implements its own ISRs and polling routines. In this way, it will be like a library. The beneficial result is that individual programmers do not have to reimplement the ISRs. But there is no benefit in, and no possibility of, eliminating the very needed ISR itself.

    Personally, I question whether the MCUs selected for the Arduino are appropriate for the "cute tech" market that the Arduino-series-PCB-module (a.k.a. "shield") manufacturers seem to be going for. Possibly the availability of Ocaml will bring the platform more in line with, e.g., the BasicStamp or similar. Overall, I see an impedence mismatch between what people would like to do (make costumes) and what they get (asking their friends to write code for them).

    The fundamental first step will be describing to the Ocaml environment how it is that the peripherals have been wired to the chip. Then the Ocaml environment can, presumably, service these interfaces either through ISRs or polling. We'll see what transpires in simplifying the Arduino software landscape.... ;)

  • by BasilBrush (643681) on Wednesday June 16, 2010 @12:33PM (#32592328)

    The best option for people who want to learn about parallel programming on an embedded processor is the Parallax Propeller. Genuine 8 core system on a chip, programmed to the bare metal. And so much fun.

    http://en.wikipedia.org/wiki/Parallax_Propeller [wikipedia.org]

    • by vlm (69642)

      I'm somewhat familiar with the Propeller. Parallelizes quite well up to eight simultaneous tasks. Nineth? Well, turn back around and back to hell.

      Its about on the level of saying, I've got eight tasks for my arduino, so since they're cheap enough, how about soldering in eight arduino chips. Laughable as this sounds on the surface, in an era of pic microcontroller that are cheaper than a can of soda, its not all that bad of an idea.

      On the other hand, if you wanted to run K or M of threads, perhaps the wo

      • Re: (Score:3, Interesting)

        by BasilBrush (643681)

        I'm somewhat familiar with the Propeller. Parallelizes quite well up to eight simultaneous tasks. Nineth? Well, turn back around and back to hell.

        Very true. I've done 2 games with the Propeller, and hit the 8 core ceiling both times. So a lot of people are now doing projects with 2 (or more) propellers.

        Maybe not a great choice for production electronics. But great fun for tinkering and one off projects.

      • Re: (Score:3, Interesting)

        by Jerrry (43027)

        "I'm somewhat familiar with the Propeller. Parallelizes quite well up to eight simultaneous tasks. Nineth? Well, turn back around and back to hell."

        In that case take a look at the XMOS chips. Each core supports eight hardware threads and there are 1, 2, and 4 core versions available. Each core runs at 400 MHz. With the 4-core chip, you have 32 hardware threads to work with. Need more? No problem, just add more chips and connect them using the built-in Links hardware. XMOS sells a development board that has

        • by vlm (69642)

          Thats some mighty cool hardware. But I don't think you get my point. Its possible to write software where there is a clearly defined ultra hard permanent fixed limit to the number of threads and no fancy concurrent stuff is necessary between the thread. In that case hardware multi-cores like the propeller and the xmos look beautiful. For example my camcorder has one thread pulling bits off he CCD and stuffing them on the SD card, another thread updating the real time clock, and another thread running th

          • If it's a microcontroller I'd say it's in an appliance of some sort. Appliances don't run just any application; they just do a few jobs that are decided in advance. So if your ATM, for example, needs more than 8 hardware threads wouldn't you kludge some in software?

            I'm not sure the Civ analogy really works here; if you were recreating Civ on a camcorder, knowing what chip you had to work with, you wouldn't write it in such a way that it would fail as you suggest. Or perhaps you wouldn't write it at all... y

            • by ultranova (717540)

              Having 8 threads is fine and dandy but I'll bet you're more likely to see them controlling a robot with 8 limbs rather than 8 settlers.

              6 limbs. You need a thread for overall control and body coordination, and could really use another to keep a look at environment.

              Actually, you could easily use hundreds of threads, doing basic processing with senses, integrating data, predicting how the world around you evolves, planning, etc. But certainly need more than "one thread per limb", or the damn thing can't even

              • Why would you need one thread per limb? Walking or manipulating an object is probably going to be a coordinated activity between limbs. Probably better to have one thread controlling them all. Likewise, there's no reason not to have one thread dealing with multiple sensors.

              • You missed the point of the entire post, which was that microcontrollers like this are far more likely to be used in industrial automation than in playing games.
          • because the hardware devices usually have little to no support for the hard parts of concurrency like mutex and race condition things, so they blow up.

            The Propellor has locks, so mutexes are no problem. Race conditions are a bug that could happen in any concurrent system if a programmer makes a mistake. There's nothing particular about the propellor that would make it more likely.

            As to the larger point about it not being scalable to arbitrary numbers of processes, absolutely. But with embedded stuff you ver

        • by Jerrry (43027)

          Oh, I forgot to mention that David May, the creator of the XMOS chip, is also the creator of Occam, the language mentioned in TFA.

  • Just curious. When I was an undergrad they had a parallel programming course and the language we used was C*. Basically it was C with this add on called a shape. Really it was just an array (Could be multi-dimentional) of virtual processors and associated data. (Basically a short, long, etc.) Then you'd just do a where statement on this array of processors. So in the where statement you'd just list the instructions you wanted done and each virtual processor would each run those instructions themselves. (Bee
  • by Animats (122034) on Wednesday June 16, 2010 @12:37PM (#32592360) Homepage

    Good idea. I'm impressed that they were able to cram Occam into an Atmel ATMega. Occam syntax is rather clunky by modern standards, but it gets the job done. It has a sane concurrency model and is safer than C.

    Next, Ada?

    • by augustw (785088)

      Occam, "clunky"? You mean it doesn't use braces? Or that is uses semantic whitespace, like Python? It's very terse, and has little syntactic sugar. I'd love to see what you'd do to make it less "clunky".

  • Another option is to use the Parallax Propeller [parallax.com] microcontroller. It's got 8 cores, 80Mhz clock speed, and 32k of ram, and you can either program in its higher-level Spin language or get right down into assembler. The Arduino is fun to learn on and accessible to people who don't have a strong programming background, but working with the Propeller is like advancing to the varsity squad.
    • by vlm (69642)

      It's got 8 cores

      How well does it handle the 9th thread? How well does the assembly code handle mutexs and race conditions?

      working with the Propeller is like advancing to the varsity squad.

      Hand the "Varsity eight person rowing team" a ninth oar, sit back and watch the fun?

      • Sure, 8 cores. That'll handle a few servos, audio input/output, light sensor, and video processing, all done natively. After all, it's a microcontroller, good for gadgets and robots. It's not like you're running MapReduce on it.
        • Re: (Score:3, Informative)

          by vlm (69642)

          After all, it's a microcontroller

          You italicized the wrong syllables. Should have said microcontroller as it can only parallelize separate hardware threads. You can't, for example, do more than eight software threads.

          Here's a mixed model fail for an four person soccer video game:

          one cog runs the video out (hardware, OK)
          one cog runs the sound out (hardware, OK)
          one cog each for each human player, reading each joystick or bluetoothed wiimote or whatever (hardware-ish, OK)
          one cog each for each computer controlled AI player (software, danger!

          • by fatboy (6851)

            Why don't you just shift the HID devices into one cog? I am pretty sure that @ 20 MIPS you can read a lot of joystick information and copy it into hub RAM. Same with your AI players.

            I wrote a 16 channel DMX light dimmer that uses only 3 cogs. I could squeeze that into 2 cogs if I weren't so lazy. Doing away with interrupts made this a relatively easy project.

  • In general, one should try to avoid interrupts whenever possible. I thought years of VB programming and the therac 25 taught people the pitfalls of event driven software. Think about polling, fixed time steps, and state machines. Now we're talking embedded systems and video games. To be fair, interrupts are unavoidable for some things - just try to minimize that and keep the interface between IRQ and non IRQ code minimal too.
    • I can honestly say in my 20+ years in the industry (including 10 years in embedded systems) I've never heard anyone claim that polling is superior to servicing interrupts.

      Now, if you can use a interrupt-driven real-time OS that allows you a lot of flexibility in waking up tasks, that's even better.

      • by vlm (69642)

        I've never heard anyone claim that polling is superior to servicing interrupts.

        I can make a tight polling loop in single digit clock cycles. Some processors have extraordinarily long interrupt operations. The type that smacks the entire kitchen sink onto the stack before it'll look up the ISR address and jump to it, latencies at least an order of magnitude longer than the polling loop.

        This doesn't just bite midrange procs trying to do ultra fast stuff like video overlay, it also bites ultra low power / ultra low speed procs. At 60 KHZ clock, you might be hard pressed to handle more

        • Well, as you illustrate, context makes all the difference.

          In practice, it seems that long interrupt response is usually associated with processors and supporting hardware that includes pre-fetching, caching and other non-deterministic characteristics that render software loop timing unpredictable. Of course, sometimes that doesn't matter.

        • by blair1q (305137)

          polling has great latency response

          Only in situations where, as per your example, you can cram a couple thousand actions per second into a chip executing 60 thousand instructions per second; i.e., everything you do takes a couple dozen instructions or less. Pumping the brakes on an ABS might fit that sort of model, but guiding a car to parallel-park itself will not.

          Once your requirements get more complex, and involve a mix of long and short tasks at varying priorities (especially those where the long tasks

    • by KenSeymour (81018)

      If it is a life-safety issue, it shouldn't be on a computer at all, unless it is a safety rated device,
      like a safety rated PLC.

      Physical or electro-mechanical interlocks are the order of the day. The therac didn't have a safety interlocking
      outside of the computer. The code had a race condition which killed people occasionally if the operator typed too fast.

      If you have an automated saw, are you going to put a computer between the emergency stop button and the motor
      power circuit? I wouldn't, whether it used

  • Where is it? I can't find the port. There is a link to: http://www.transterpreter.org/development_download [transterpreter.org]

    But that link is for a Mac-only tool chain of some sort. Does this mean the arduino IDE will be replaced with this Transterpreter thing? If they have a library or something drop-in for the arduino IDE (written in java), i would think it would work for any platform.

    • by Egelmex (1835008)
      As it says in the article there is only a Mac version at the moment, with windows and linux versions coming out for OSCON. If you are using Linux building it yourself is quite trivial. We know the naming is confusing, and I agree a plugin for the arduino IDE would be nice.
  • by walterbyrd (182728) on Wednesday June 16, 2010 @01:39PM (#32593068)

    What does the Arduino diddly do?

  • by Simonetta (207550) on Wednesday June 16, 2010 @01:55PM (#32593290)

    I'm an AVR programmer. I prefer to work with assembler, because I come from an electronics background and assembler is closer to the electrons. I can, and occasionally do, work in C on the AVR and Visual BASIC on the PC.

        Let me say, this stuff is hard. It's hard for programmers and electronic technicians. It's really hard for hobbyists and people who have little technical background. Artists are not going to be programming AVRs to make cool performance art projects with Arduinos. OK, maybe one or two, but not many.

        Even rock-bottom beginning simple stuff like blinking an LED or making a beep when a button is pressed can be challenging on a microcontroller. It's not hard to know what to do; it's hard to actually do it and make it work 100% all the time.

        Your average guy or performance artist is NOT going to be making a cat door that won't let the cat in the house with a mouse. Let's see, the cat pushes on the door with its nose. This flips a sensor that activates a camera that relays an image of the cat's face to a microcontroller. The MCU parses the pixels to determine that the image sector of the mouth of the cat is significantly different from the analysis of previous images of the cat's face. The door won't open.

        Now if you're reading this, then yes, you can program something that might be able to do this. You're a Slashdaughter, for Christ's sake, you can do anything technical, and you know it.
    But you wouldn't be able to do it on a $1.59 microcontroller. And you sure wouldn't be able to do it if you didn't have thousands of hours of programming experience and technical training.

        It doesn't matter what language or integrated development environment that you use, it's just not going to happen.

        And frankly, most of the cool projects that performance artists want to do with computers would require a real gigahertz/gigabyte/advanced_OS PC to do, not an 8-bit microcontroller with 1K of RAM that can just barely run a microwave oven, let alone a telephone.

        Performance artists want professional-level programming ability and talent at bargain-basement artists prices. But if you're not a beautiful woman into performance art who has the ability to hook up her beautiful friends to nerdy techno-geeks who actually do the programming, it's unlikely to happen.

    • by djd20 (1835080)
      I know for a fact that artists with litte or no programming experience have been able to pick occam up on the arduino or RCX. Its challenging when you have to write assembly, not when you have a library designed for that microcontroller and all you need to do is write 5-10 lines of code to start doing 'cool stuff'.
    • by Zerth (26112)

      I think even an artsy type can plug a camera shield, motor shield, and SD card shield into an Arduino and download an image comparison library.

      Somebody probably has a walkthrough on Instructables or arduino.cc so they can do it C&P voodoo style.

      An arduino won't be doing video recognition, but it can compare a still picture to an outline of a cat's head once a second, if it has somewhere to store the data.

      • Actually, I use mine to deconvolve a spherically distorted JPEG into a panorama. It does this very well. It stored data to an SD chip.

  • Interesting, (Score:3, Interesting)

    by inhuman_4 (1294516) on Wednesday June 16, 2010 @04:15PM (#32595294)

    This is interesting and I hope that it helps bring in new people to the embedded field. Having easy tools to introduce people to a system can make a big difference in the learning curve. Once they get hooked they can start to learn how to do things manually.

    For things like the ARM, Blackfin, etc. having multitasking is a huge benefit. But on lower end systems like PIC, AVR, etc. it's really just for show and tell.

    I have a fair bit of experience programing these low end devices and the golden rule is ISRs (Interrupt Service Routines) for everything. Everything should be done via ISRs, and when not running an ISR the chip should be in low power mode. A lot of embedded systems are battery powered and they simply don't have the power to waste on things like polling. If you have no choice but to poll (and there are very, very few cases for this) then use a timer ISR. Additionally ISRs give you interrupt priority and hard-realtime responses, something that many applications (especially safety) require.

    Putting occam on Arduinos should help people get started on these devices, but I seriously doubt it will see any use in the professional world.

  • Half the battle is accessibility. Arduino does that well. It accomplishes what many want it to do without fuss and esotericisms of "good" code. I'd rather have a set of tools I can work with for a one-off task. It beats waiting for an uppity code jockey who insists that it will take 4 weeks, $14k in developer tools,$2k in class fees, etc., to accomplish what a lot of sixth graders eagerly do in a few evenings from scratch. I've seen it happen- right where I work, and it is frustrating.

The tree of research must from time to time be refreshed with the blood of bean counters. -- Alan Kay

Working...