3
\$\begingroup\$

I was wondering if it is possible to change the software library for writing INO arduino sketches so that it would expect arduino shield under different set of pins. For example I want to use theese shields together: RedFly Wifi Shield:

http://shieldlist.org/watterott/redfly

and Arduino motor Shield rev3:

http://arduino.cc/en/Main/ArduinoMotorShieldR3

I see that I cannot stack them together because they share pin D3 but if I connect RedFly shield not by stacking but with separate wires I can connect the Red Fly shield to any 4 pins I want, for example to D20-D23 of my arduino mega board. I expect that the software library for using Red Fly won't work then. The question is: Are those libraries configurable, so they could be changed to use other set of pins? I mean is it possible without rewriting the while code? Specifically I would like to know if it is possible to any of above shields. I hadn't bought any of theese yet, and I don't know what the software libraries look like.

UPDATE: Thaks for your answers, but I couldn't found the source code of the RedFly.h library for using RedFly WiFi shield, so I don't know if it can be rewritten to use other pins. The usage examples ( http://www.watterott.net/forum/attachment/936 ) suggests that it does not takes pin configurarion in neat way (as arduino LCD library does). Anybody work with RedlFl WiFi shield? Is the library source code available on the web?

\$\endgroup\$
1
\$\begingroup\$

The most common reason that Arduino shields "conflict" is because the Chip Select pin for an SPI on the shield is hardwired on the shield. Sometimes this is manifest in an accompanying software library for the shield that assumes the shield's wiring. A forgiving reason things end up this way is a tradeoff between elegance of the software and ease of use for the end user.

If you are optimizing flexibility, you will design your software to have the (potentially conflicting) pin assignments abstracted into a constructor or setter function, and make the default constructor make default assumptions about your hardware. You would also need to provide a jumper on your shield that you can shunt for "default" behavior or wire wherever to any of the I/O pins with a "soft" wire.

If every shield followed that practice, then there would not be such thing as conflicting shields. The drawback of the flexibility is that the more interfaces are exposed to users the higher the barrier to entry for beginners. I don't think anyone would argue that beginners are the majority of Arduino users, and so ease of use wins the day - fewer options and simplicity are better in most cases for the Arduino community.

A good example of a library and a shield that do it the "elegant" way are the LiquidCrystal library that comes standard with Arduino. There are five pins on the LCD interface that are software definable. I made a Basic LCD shield and had to make these kinds of choices in the design. I decided to favor flexibility because (1) the library already supported it, and (2) LCDs themselves are not consistent in their pinout. So I provided a whole bank of jumpers effectively "abstracting" the LCD from the shield in hardware. Maybe that wasn't the right choice in retrospect, but the spirit of my decision was to support whatever LCD you might want to use and whichever Arduino pins you might want to use.

If I had hard wired for certain Arduino pins and a particular LCD pinout, I could have saved users a few minutes of soldering, at the expense of flexibility and interoperability with other shields. In my case though, I saw the LCD shield as something that might be at "the top" of a shield stack, so maybe the flexibility was meritted in this case. There simply isn't a one-size fits all answer I'm afraid.

\$\endgroup\$
1
\$\begingroup\$

Some libraries are written to accept pin numbers as arguments to the constructor (Adafruit's library for their MAX6675 thermocouple amplifier, f/ex), but since a shield is normally expected to be connected mechanically (and therefore, to a known pin configuration), there wouldn't be much point.

You have access to the library source so you can make a version with your custom pin assignments. For a little more flexibility such as you're asking about, pass the pin assignments to the constructor as parameters.

\$\endgroup\$
  • 1
    \$\begingroup\$ Most of the clean code I have seen abstracts the physical pin from the software. This is a concept that was even taught in my intro to computer science class that we taken by many different majors. If people aren't doing this, then I wouldn't care to use their code at all. The only reason this wouldn't be done is if the hardware had something specific about a pin that would make it impossible to ever move off of that pin. But even then its nice to keep it separate for if you switch to a different IC with that specific feature on a different pin. \$\endgroup\$ – Kellenjb Feb 9 '12 at 14:58
  • \$\begingroup\$ No question that is "best practice"; alas, it's not a universal one... :( But there's little point in not using the code that works, even if you only take it as a guide to re-writing it your own standards (assuming you have the luxury of time and skill), because, hey - it works! \$\endgroup\$ – JRobert Feb 9 '12 at 15:15
1
\$\begingroup\$

There is a shield sold by sparkfun that's designed to sit between 2 shields and allows you to reassign pins.

http://www.sparkfun.com/products/11002

\$\endgroup\$
  • 2
    \$\begingroup\$ With all those shields it becomes an Arduino Battleship! \$\endgroup\$ – clabacchio Feb 24 '12 at 15:13
0
\$\begingroup\$

The RedFly software library can be found on this site.

The pin configuration can be changed in the file

/your-arduino-path/libraries/RedFly/RedFly.cpp

The Rx and Tx pin can not be changed, because the hardware serial port is used for the communication.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.