I think the concern is more of a different perspective of approaching development with the ezb. Take the Honda asimo, for example - which uses a very similar approach. The processing speed and operating system benefits of a PC make it a superior platform for high level processing and decision making. Due to speed limitations between the PC and a controller, there is no solution for writing microcontroler-like code on a PC. This is because the PC is not a microcontroller and therefore should not have code written on it to perform microcontroller style loops or expect hardware interrupts, etc.. The solution is to treat the computer as a high level processor for doing things that micros just can't do very well or require a great deal of code. Examples of these functions are speech, speech recognition, vision (color/glyph/object/etc), graphical display, controller peripherals (joysticks/etc).

To perform lower level functions, such as monitoring trigger switches or interrupts, combine ARC.ezb with a microcontroller/arduino. If the ezb is in the way of interupt probing, consider connecting the arduino directly to ARC.via serial port - even though that still won't solve much because if checking for valid packet length is done while the packet is still transmitting will result in what tony refers to as an error. It's not an error, instead an expected behavior for packet transmission.

As in Tony's application, the controller can connect to a PC serial port instead of the ezb. This way ARC.is not blocking the communication protocol to the ezb while probing for serial data.

If there was an interupt handle built into ezb, it would be abused and flood the communication channel due to the programming model which is being discussed here - unless it was understood that it should be used with caution.

On that note, I will add an interrupt function on the next hardware update, which I will lightly introduce in this response.

Something that is overlooked in networking is latency vs speed. An example is to consider the speed of sound. Let's pretend that you're 1000ft away from me over a calm lake. You can yell words across the lake as fast as you want, but I will only start hearing them a second later. Sure, once i start hearing them I can begin executing your commands as fast as they come. Now, this is where it gets interesting... You're expecting me to respond before sending the next commands. Well, you now have to wait 2 seconds for the response. One second while I wait for your last word to hit me, and another second for my acknowledgement to reach you. This means I also have to wait 2 seconds while my response heads to you and your commands head to me.

So when you perform this method of communication over and over, the delays of waiting for commands due to latency creates significant challenges. I'm giving this example because many people say "well wifi is 10 mb per second!". Yes, it's XX mb/sec in constant throughput, but that's it. Keep in mind that a single byte of information contains many many Ack and Syn discussions. More information on that can be discovered researching the OSI model.

This is also one of the challenges when designing the ezrobot camera. Some say "I have a wifi camera and it has blah blah hd resolution". Well, what they don't have is super duper low latency compared to the ezrobot camera. Video is expected to be heavily compressed, buffeted, transmitted and buffered again, rinse repeat. This is because it doesn't quite matter if you television or movie starts playing a second or two after the realtime content. With robotics is very much matters! This is why it's a challenge.

The true way to overcome this challenge is to treat the ezb as what it is, NOT a microcontroller.

In the meantime, I can leave you with this bit of information. Jeremie is evaluating some new wifi modules at the moment, which are smaller and will provide an additional ARM processor on the top (communication) pcb of the ezb. If this works, we will be releasing an upgraded communication pcb which will allow custom code to be written on the second arm - and will use its own communication channel to ARC. This will be exciting for you all to code directly, and also give you first hand experience to the challenges of communication latency.