The soft serial interrupt will run (and exit quickly) any time any of the pins in the same block change. You might try putting all the servo pins on a different port if you can rewire it and see if that helps. If you need the PWM pins, try putting the serial on one of the analog pins.

How is it that the Windows version of the compiler doesn't have the register problem? I thought they were both on the same version and based on the same code, no?

Hah. I actually wrote a version that uses Timer1 and Timer2 to do that, when I was having some problems with NewSoftSerial. Turns out those were all interrupt related, so I didn't do anything with it. It has some problems at higher baud rates, but I've run it at 19200 with no problems. You're welcome to take a look if you like: http://idisk.mac.com/jinschoi-Public?view=web

The code is based on an earlier version of NewSoftSerial, version 2 or 3. It also contains code for RTS/CTS flow control, which I found I needed for my project.

Is it fairly easy to update the compiler for arduino-0013? Do you have to build it, or is there a binary distribution you can just untar in the right place?

I've been playing around with NewSoftSerial and it's been working pretty well for me, with only a few difficulties so far. Thanks for your great work packaging up a bunch of different ideas, mikalhart.

A few notes:

• I've experienced some problems doing the same sort of serial pass-through, where you just echo characters between the softserial pins and the UART. If the device I'm speaking to on the softserial port is set to echo, no matter how slowly I type I am liable to get garbage characters interspersed with what I'm typing. Turning off echo and having everything run half duplex gives pretty good results. Could this be because pins 2 and 3 (used very often in the soft serial examples I've seen) share an interrupt with the UART on pins 0 and 1? Unfortunately, my device requires a specially designed shield so I can't move pin assignments around easily, but if someone who is having interrupt problems could try using, say, pins 8 and 9 for the soft serial and see if they continue to have problems, that would be an interesting experiment.
• Another problem I've had is when I get a whole slew of characters sent back from the serial device, it quickly fills the buffer and I lose the rest of the data, even when I'm not doing hardly anything else in the main loop other than trying to handle the input. I'm looking into adding proper RTS/CTS handling as an option to NewSoftSerial to see if that helps. There's an attempt at CTS handling in the AF_XPort code, but it doesn't seem to work properly for me.

I'm trying to get reliable high-precision timing data of two separate (ideally, three or more) digital pulses on the rising edge. I tried doing this using external interrupts and capturing the time using a high precision routine found elsewhere on this forum that captures Timer0 ticks. The smallest difference between pulses arriving simultaneously appears to be 26 ticks, or 104 us. Is this because of the overhead of handling the ISR itself? If I need more precision, what's a better way of doing this? I was hoping to avoid having to use a high frequency timer interrupt so as to give some CPU time to the main loop, but I may have to go that route.

I'm mainly interested in the iWifi unit because wifi shields you can buy are ludicrously expensive, and I'm interested in using custom iPhone apps to interface to Arduino projects to offload some of the processing and make use of its nice screen. The iPhone can only be interfaced to through wifi.

I'm working on a shield to interface to the ConnectOne Secure Socket iWifi ($60). I will report when it's ready.

http://www.mouser.com/Search/ProductDetail.aspx?qs=y%2f2LRhZeS3Gyt4nJwwXnlQ%3d%3d

That blackwidow looks pretty good, and the cost is less than an Arduino+iWifi board, even leaving out costs for any interface hardware. So yeah, I'd definitely consider that if I were doing it again.

Yes, I did make the wifi board, and successfully used it to interface to a Kestrel wind and environment meter, implementing a pseudo-HTTP interface which would respond with the data at any request from a web browser. Works great. However, I never wrote up my project since nobody expressed interest.

I still have the EAGLE files for the shield and the code for the project, it should be easy to adapt for other projects. The Wifi module costs $60 from Digikey and the shield can be etched at home, or costs about $20 from batchpcb. If you are really intent on buliding one, I'd be happy to document it.

The bluetooth stack on the iPhone only implements the handsfree or headset profile. And there are serial lines on the dock output, but you can't get to them from the API. I think for now wifi (or GPRS/3G) is the only way to officially connect.

I've also considered doing an acoustic modem through the microphone input, which could work but would require a lot more software and hassle.

I'm working on a wifi shield that should be somewhat less expensive than the existing wifi shields out there. With the shield, you should be able to make a direct local wireless connection to the iPhone and use custom apps as a display for Arduino applications.

I have a working prototype of a shield for the ConnectOne iWifi. Similar to MatchPort and WiFly modules, it does WEP, WPA, SMTP, HTTP, DHCP, etc. etc. Has a small web server on board, and a "SerialNET" mode which just forwards serial data to TCP. $60 from Mouser, but you'd have to make the shield yourself from an Eagle file and several SMD components.

I got mine from Mouser when they had them.

I was using it to interface to a Kestrel wind/weather meter. I configured it into listening mode, then read a line and output a valid HTTP response with the information I was interested in. Thus I could use a regular web browser to access the data, although the actual content of the request was entirely ignored so it would always return the data.

Some notes:
You can only service one request at a time, and there's a limit to how quickly you can service requests. The wifi board has to reset itself after every request and that takes a second or two.
Make sure you output a "Connection: close" header or the browser will hold open the connection. You can also define a close connection character (AT+iDSTR) and output that at the end of the data to force a connection close.

Here are the parameters I used:
# No echo
AT+iE0

# No flow control
AT+iFLW=0

# SerialNET config
AT+iSNSI="5,8,N,1,0"

# Listen port
AT+iLPRT=80

# Close connection character
AT+iDSTR=\x7f

# Flush character
AT+iFCHR=\x0a

# DHCP pool size
AT+iDPSZ=1

# Default IP address
AT+iDIP=192.168.0.1

# SSID
AT+iWLSI=!kestrel

# Default channel, required for initiating ad hoc
AT+iWLCH=6

I was using the other board, not the Nano. I have a couple of Nano boards now and was thinking of making an interface board with the Arduino Nano for a really small wifi arduino setup without the need for much level shifting, but I haven't really done anything on it.

I've only used the ConnectOne tools to update the firmware, which is actually fairly hard to do unless you are using their evaluation board. I had to hack up a USB/Serial cable interface on a protoboard before I could get it to work. The ConnectOne firmware is pretty decent, and takes care of a lot of protocol stuff for you.

I was going to write up all the work I did a while ago with interfacing Arduino to the connectone boards, but I just haven't had the time.