I would like to provide a little more history of a project that has been taking up a lot of our time. This project has been on the drawing board for some while and originally started under the label ‘Armadillo’. In it’s initial guise it would have become an Arm based Arduino, one that offered a little more processing power among other things. Armadillo however rapidly became fused with another project to improve Arduino’s expansion and openess (OpenSource and open as in processor agnostic). The idea was that of an OpenSource bus with standard peripherals as well as custom and customised peripherals complying to some basic but flexible guidelines.
To differentiate the new version from Armadillo we conjured up The label ‘Armduillo’ this also helped disambiguate from discussions on the Arduino forum by others using a similar term.
Armed with the new Folknology lab plans for the Armduillo I decided it was time to out it to the community which spawned it – Open Hardware Hackers (#OHH) London chapter. The meetup was a quiter one than usual which was fortunate because we had lots of time to talk about particular projects including Armduillo. The initial design followed the Arduino physically by providing shield backward compatibility, this quickly became an obvious flaw in the design. Many of the issues we are trying to solve are actually hampered by the original physical layout. We talked about a number of its other features and the possible future development of the idea to its logical conclusion. The meetup provided excellent feedback, especially when dealing with the nitty gritty of Paul‘s ongoing project in which we intend putting it to good use. Peter as usual provided some fantastic insight from his own experience of using and supporting the Arduino at TinkerIt including the daily burdens of such support.
As a result I decided to sit down and redesign the layout of the board subtlety taking into account the feedback from the meetup. Thus I would like to show the revised layout so that similar discussion can take place before we move the first batch of prototypes. The initial batch will probably be 4 or 5 units (we might consider a few more) to enables us to help finish the software and fix any early issues with the design. If you would like in on the first batch let us know ASAP as we might be able to stretch to a few more.
At the same time we have renamed the project to ‘Amino‘ to better reflect where it is heading and to remove some of the previous associations. For example although we are looking at providing levels of compatibility with Arduino, we are not letting that hold the project back from its longer term goals. For example we are not providing physical compatibility with Arduino shields on the basic board although we may provide a shield adapter for this purpose if there is demand for it. This is largely because of the design flaws of the shields themselves, confined by the Arduino connector scheme. Of course these sorts of design decision carry risk but sometimes tough choices have to be made, we would certainly be open to alternate view points on this prior to the initial prototypes, just make yourself heard.
So I wanted to put up the layout of the board to enable some further discussions to take place around the new design, take a look below at the highlighted board layout :
The board dimensions are Approximately 55 x 45 mm subject to change even though the PCB is 90% done a little power routing, via optimisation and ground plane is needed and hence may change things slightly.
Heres a quick once over of the board connectors
I will start with the Bus ports (the original ebus concept) A to C coloured yellow, blue and green. These are comprised of 2 dual row 8 pin 0.1 inch female connectors carrying the power and digital parts of the bus and a single dual 2 pin analogue 0.1 female connector. Each digital bus is composed of power plus a bus addressable SPI interface and an 8 bit GPIO port. The analog section contains 2 analog input channels, a single AREF along with an analogue ground pin. The bus cards fitted with dual 0.1 inch right angled pins slot vertically into the appropriate bus port. The cards may or may not include the analogue pins, but should include the power and digital pins (it is actually possible to exclude some of these).
Thus the expansion capabilities of the bus ports offer 24 bits of GPIO, 3 SPI channels (individually addresable) and some control signals. To complement the digital, each port has 2 analogue inputs and a common reference voltage with an separate ground.
In addition to the bus ports there are expansion and support connectors, all of these with the exception of the JTAG port are horizontal expansions and will be populated with right angled dual row 0.1 inch female sockets. These allow sideways expansion of up to 16 bits of GPIO, 6 analogue channels (repeat of ports A to C in this case) and addressable SPI ports (2 additional addressable spi channels from those on the bus ports). Also hidden within these connections are board to board/Peripheral/PC interface with USB currently heading the candidates.
The Micro itself is an STM32 series micro-controller the details of which are not fixed in concrete as the board can accommodate various members of this family. It is likely to operate at 72Mhz and contain at least 128K Flash and 20K Ram, in fact it may be available in different configurations offered by its distributed open production.
One of the key design changes that have taken place is the expansion ports which are now presented in a grouped horizontal fashion at the north of the board. This design achieves a number of advantages vs the earlier shield based layout.
- It is not confined to the Arduino pinout and limited connections, yet it provides signals to enable a shield adapter to be created.
- It maximises the number of expansion possibilities by exposing all of the unused pins.
- It enables the expansion to solve the common production cabling issues such as those discussed at #OHH (I hope to provide an example of this shortly as part of the initial prototype design).
- It provides enough flexibility to handle common case flat peripherals such as displays, communication as well as general inline I/O perhaps terminated with board mounted connectors (D-types, usb, terminals etc…).
Anyhow we wanted to get the new layout up early in order to get some more feedback, I’m sure their are lots of other questions so please ask away and let us know your thoughts.