I’ve been using the arduino proto board with the bluesmirf on a robot build. One of the first things I realized when I put it together is that the bluesmirf’s rx and tx are connected to pins 2 and 3. Was there a reason for this?
The arduino’s rx and tx pins are hardwired to 1 and 0. With my smirf, that’s where I’d prefer its pins to point, as I’d like to use the Serial object in my code.
The only other way to talk to serial on pins other than 1 and 0 is to use the software serial functions, that run at limited baud rates (er… 1 baud rate… 9600… because the smirf won’t talk slower than that) and have limited functionality (no Serial.available())
seems to indicate that by taking up 2 and 3, you lose external interrupt capabilities, as those are hardwired to those pins.
Could we get a version of the protoshield where the smirf’s serial pins go to a header so we can choose where they point? or failing that, one that just points to 0 and 1? I’m thinking about cutting the traces on mine.
It’s all to avoid bus contention. The Arduino board has the ATmega UART wired to the FT232RL for programming/debugging. If we were to connect the BlueSMiRF to the UART as well, it would be bad - the FT232RL would try to control the RX line at the same time the BlueSMiRF was trying to control the RX line. Hence, bus contention. Ideally Arduino.cc would add a jumper feature on the main board so you could select where the ATmega UART is connected.
The BlueSMiRF header is wired to GPIO pins so that you can use software serial commands. As I am a very-limited-Arduino-user myself, could you recommend a better spot for the BlueSMiRF connections? We’d be happy to re-route it for you.
In the end, on my robot project I just bypassed the bluesmirf jack all together and wired the smirf to pins 0 and 1 (with a seperate power switch attached) so I switch off the smirf when uploading firmware etc.
I guess my suggestion would be to add a solderable jumper gap on the protoboard if you want to enable the connection to 2 and 3, (similar to the jumper found on the bluesmirf) but by default leave them disconnected. Users can then run jumper wires to where ever they want… 0,1… or 4,5. Or, run them to another header… That might be the most useful…
Before I finalized my wiring, I just ran 2 to 0 and 3 to 1 with jumpers, and made sure to pull the smirf out when I was programming it. I’ve got so much stuff crammed on this thing now though, that I need all the pins I can get, so I can’t afford to waste 2 and 3… and I’m thinking of tinkering with external interrupts, which are apparently hard wired there.
Using the “shield”, I scraped off the copper traces leading to the D2 and D3 pins so there is no connection. Then I connected pins D0 and D1 to the smirf header Rx andTx and the Bluetooth works fine. This is after wasting an inordinate amount of time trying to get serial comms to work. (I succeeded, but it was hardly worth it). The new LIB’s may help.
BTW, I don’t use flow control, so there is no conflict with the USB serial.