Why “Fishino” ?
The names comes to a joke made on April Fools’ Day (in Italian “Pesce d’Aprile“, and ‘Pesce‘, which sounds ‘pashe’ means Fish) made on an Arduino forum where we “presented” a new board named “Fishino Zero” which had revolutionary technical specs.
The symbol, placed on board’s picture with a graphical editor, was the small fish which became the actual logo.
The joke was quite successful, and the idea of building such a board soon appealed to us.
The ‘UNO‘ part was then added to symbolize the first board of a series and to mark the complete compatibility to Arduino UNO boards, both in term of connectivity and size.
Another Arduino clone?
Not exactly. With this board we aimed to combine the easy-of-use and the enormous amount of available libraries of Arduino with internet connectivity, an almost unlimited memory storage thanks to microSD card slot and, last but not least, an on-board RTC with battery backup, all that at a fraction of the price of an original Arduino with the equivalent set of shields, without increasing board’s sizes beside the tiny 7mm wifi antenna overhang.
The integration of aforementioned periferals, in our opinion a must in IOT era, allows the creation of an huge set of appliances which can both be controlled via Internet and upload recorded data to it.
Among the possibilities, all achievable without additional hardware are, for example:
The usage of a low-cost WiFi module but with customized software to get high performances, which can be used as a WiFi station, access point or both, permits control from a smartphone even in absence of a WiFi connection.
Future ability to upload sketches via WiFi (work in progress), already foreseen on hardware side, will permit to update the appliances with no need of a physical connection to a personal computer.
Fishino UNO, as Arduino UNO, can be powered via USB port or an external power connector.
Supply gets automatically switched from USB to external when latter voltage (or voltage at Vin pin) is enough for linear regulator IC5.
Let’s see it in depth.
Voltage coming from supply connector pass through Schottky diode D2 used as a reverse voltage proection. We chose a Schottky diode instead a bipolar one because of low voltage drop of former (around 0.3-0.4 volt max instead of about 0.75 of bipolar diodes); this, and the usage of a low-dropout linear regulator allows powering already from a 6.6 volt source (5 for the board + 0.4 on diode + 1.2 of regulator’s dropout). The maximum allowed supply voltage depends on regulator’s thermal dissipation; we suggest to not go over 12 Volts and, if possible, to stay below around 9 Volts. The regulators has anyways an internal thermal protection which disables it when heat becomes excessive.
Vin input voltage (after protection diode) goes also to op-amp IC1A used to switch supply from USB port.
When Vin is greater than 6.6 volt the non-inverting input of op-amp, used here as a comparator, halved by resistor divider made with R1 ed R2, overecome the 3.3 reverence voltage of inverting input makin output switch to positive (high) level, blocking so P-Channel mosfet T1.
A close look at mosfet shows an apparently weird connection : supply enters from Drain and comes out from source, treaversing at same time the interal clamping diode. Supply pass through the diode even if mosfet is turned off.
What’s then the purpose of mosfet ? Apparently a diode would be enough : if cathode voltage is greater than anode’s one (USBVCC) diode switches off disconnecting so the USB power.
The reason of the mosfet (and annexed circuits) is to avoid diode dropout, which would lower the power supply coming from USB port from 5 volt to abiut 4.2-4.6 volt. This dropout is avoided when mosfet switches on.
Last supply stage is made by linear low-dropout regulator IC3 which brings the 3.3 volts needed, among others, by SD card and WiFi module.
Unlike original Arduino (and most clones), which brings few tenths of mA on 3.3 volt line, Fishino is able to provide around 7-800 mA, depending on current absorbtion on 5 Volt line.
Unlike oroginal Arduino, USB interface has been built around a CH340G chip in replacement to the more common FTDI232 or other more or less complicated solutiones.
The choice came mostly from lower cost and circuit simplicity keeping same performances.
The chip needs few external components to operate : a 12 MHz crystal (Q1), due capacitors in oscilator pins (C2 e C3) and a decoupling capacitor for the internal 3.3V regulator (C4).
The chip can be indeed powered from a 3.3 volt supply (connecting V3 pin to Vcc) or from a 5 volt supply, adding the V3 pin decoupling capacitor.
The component brings all RS232 signals, which are the Receive and Trasmit ones (Rx and Tx) and all control signals (CTS, DSR, DXD, DTR e RTS),
In our circuit we only use data signals (Rx and Tx) and the DTR to generate the auto-reset pulse when serial port is opened, which allows sketch upload without need of a manual reset.
More on reset circuitry later on, as unlike original one it has been modified to allow remote uploading of sketches over WiFi.
The USB interface chip doesn’t provide 2 separate outputs for Tx and Rx leds (which shows activity on respective pins), so we put the leds on data signals directly, with a careful choice of resistance values to bring enough led lightning without eccessive power drawing.
The choice of resistances values has also been trimmed to avoid flashin of WiFi module’s firmware from on-board USB interface, without need of an external adapter.
This section is almost identical of original onee; same controller, only in SMD format because of board’s space constraints, with the usual 16 MHz crystal, the 2 capacitors around it, and some decoupling capacitors on supply pins.
A note about latters : in most schematics we can see some (often many) small capacitors in parallel between power supply line and ground. Some people asked why we can’t simply use a big capacitor in replacement of those.
Looking in depth at boards we can see that all these small capacitors are placed very close to IC’s supply pins.
The reason is quite simple : modern digital chips runs at high frequencies and with pulsed signals, which cause strong current absorption variation on supply pins.
Because of the high frequencies the pcb traces, normally quite thin and long, behave as inductors or, at those frequencies, as resistors, causing electrical noises on pins.
Capacitors placed very near to supply pins eliminate most of those noises.
About I/O connectors : as you can see from pictures, we added a small 10 pins connector in parallel to the standard one, but slightly shifted, to align it to 2.54 mm standard pitch. This allows to use a standard breadboard as a shield, overcoming the well known Arduino’s problem, without breaking compatibility with existing shields.
Almost all Fishino‘s circuits operates with a 5 volt supply and signals, but MicroSD cards and the WiFi module do on 3.3 volt e, worse, they’re not 5v-tolerant.
Non 5v-tolerant circuits can be damaged with signals from 5v ttl levels.
Well, for the WiFi module, from datasheet it seems that it’s indeed 5v-tolerant, but it’s not clear enough, so we behave as it is not, even if in all our tests we couldn’t damage it with 5v signals. This indeed doesn’t mean that it can’t be damaged in long term usage.
So, to follow technical specs we decided to insert some level-shifting circuits.
Those are built with simple resistor dividers, in 5V to 3.3V direction; in the opposite direction we trust on high 3.3v ttl level to be inside the high 5v ttl level range; this theoretically lowers noise-rejection capabilities, but in our and most circuits works flawlessly.
Doing so we’ve spared complicated solutions which, besides of increasing costs, would have taken precious board space. Better solutions needs indeed a mosfet plus a couple of resistors for each signal, or dedicated level shifter ICs.
The only “caveat” of used solution, if we want to be picky, is that resistor dividers have 2 opposites requirements :
Chosen values are a compromise between the 2 requirements above and allow perfect data transmission at highest speed available. The dividers are built around resostors pairs R13-R21, R12-R19 e R14-R17. A 5 Volt input value gets converted to:
Vo = 5 Volt · 3.3K / (1K + 3.3K) = 3.83 Volt
A value which is slightly greater than the theoretical 3.3 volt but it’s still acceptable from specs, which allows usually values up to 0.6 Volt greater than supply, so 3.3 + 0.6 = 3.9 Volt.
The interface is quite simple and is almost identical to SD shield or compatible ones, or to SD interface card bundled with WiFi / Ethernet shields; it uses SPI data lines which are MOSI (data from atmega to SD, Master Out Slave In), MISO (data from SD to atmega, Master In Slave Out) e SCK (clock). Atmega lines are, of course, adapted by level shifters described in previous paragraph.
Card selection is done by SDCS line, active low. On this line level shifting is a bit different, using a pullup resistor on 3.3 Volt supply (R18) and a diode which allows just negative signal coming fm atmega.
This kind of shifter allows the SD to be de-selected when SDCS signal (connected on Fishino‘s digital output 4) is in tree-state mode, for example after a reset.
The SD interface is fully compatible with similar shields, and it can use same existing libraries, as we will see in examples shown later.
If atmega controller can be regarded as Fishino‘s brain, the WiFi module is indeed it’s door to external world, and it’s the main reason of board’s development.
The idea arose, indeed, from the need of an Home Automation appliance which could be controlled from web.
This is not a new idea, of course, but before Fishino board we needed an Arduino with annexed WiFi or Ethernet shield and a separated RTC, with costs and sizes by far higher and, with Ethernet, a wired network connection.
WiFi module embedding in Fishino at reasonable price has been possible thanks to new WiFi modules with ESP8266 controller.
This modules, although very small in size, are built around a 32 bit processor, a big flash memory chip (from 1 to 4 MBit), around 90 KBytes of RAM, of which 32K available for user’s applications, a complete WiFi stack up to a PCB integrated antenna.
At first sight such a processing power (by far greater than atmega controller’s) would suggest the direct usage of WiFi module, programming it directly with producer’s SDK (Software Development Kit, quite complicated usage) or with a set of software tools which allows to code with Arduino IDE directly.
Where are the caveats ?
First, architectures are quite different; even if Arduino IDE has been patched to build and upload ESP code directly, compatibility is still too low to be usable.
Next, we’d loose the ability to use the enormous amount of existing Arduino’s shields and libraries.
Last but not least, ESP has a very limited amount of I/O digital pins and just one analog input, which is a big limitation to real world usage.
So we decided to embed the WiFi module in an Arduino compatible board , trying to minimize differences with existing WiFi / Ethernet shields on software side, thanks to a provided library which will be described later.
ESP module’s usage was difficult on the beginning, and source of many trial-and-error phases, mostly because of supplied producer’s firmware.
The latter works sharing data over a serial port and not, as Arduino’s shields, over SPI one.
Serial port’s advantages are obvious: simple usage (with just a serial terminal you can ‘speak’ whith module’s firmware) and the need of just 2 controller’s data lines.
Serial port has also some serious caveats :
So after many trials spent on developing an Arduino library using official firmware, we gave up and decided to develop an in-house one, allowing data transmission over SPI interface which is much faster than serial port and provides handshake.
In spite of a longer development process (ESP documentation is not very complete) the advantages arose immediately :
Developed firmware and annexed library allows to reach data transfer speeds (measured from SD card to browser in a tiny web server environment) of about 60-70 KBytes / Sec, so slightly faster than speed reached with cabled Ethernet shield (!!!) and quite faster (2-3-4 times) than original WiFi shield; the software has still some optimization margins which will be exploited in next releases.
Next firmware releases will also add new features, like usage of ESP hardware serial port as a second Arduino’s hardware serial port, the ability to upload sketches over WiFi and others.
Let’s go now to WiFi section schematics, which has some peculiarities dues mostly because of hardware problematics of ESP modules.
As you can see from module’s symbol, it has many connections named GPIOxx (General Purpose Input Output) which are, as name indicates, used for different tasks depending on firmware program and/or on module’s state.
All pins are indeed usable as the digital I/O (and an analog input) of Arduino, but most of them have also other functions, some of which are used on ESP module boot phase, with make their usage cumbersome.
Here a short pin description:
All those pins are (probably) NOT 5v-tolerant, so be careful on its usage.
Schematics peculiarities :
As you can see from schematics, we used same data lines as standard WiFi / Ethernet shields, which guarantees a 100% compatibility with additional shields and modules.
On this connector we put some of the free ESP GPIOs (to be used as digital ports) and prevision for some configuration jumpers.
In detail :
As mentioned above, RESET circuits are somehow different from Arduino’s original ones for following reasons :
We start from DTR signal coming from USB controller (IC2 / CH340G). This signal, as aforementioned, is set to a low level when serial port is opened on host PC. A negative pulse is formed by aid of C6 capacitor (1 uF ceramic, in replacement of the 100 nF found on Arduino, to have a wider reset pulse), passes through SMD jumper SJ1 (which can be cut to disable auto-reset feature) and reaches “external reset line”, which is connected to reset button and pin number 5 on ICSP connector.
As a difference from original circuit, in Fishino a diode (D6) separates atmega reset input from reset line. The purpose of this diode (and D3 diode, explained later) is the ability to reset the atmega alone without transmitting reset signal to ESP module.
With this ‘trick’ we gave WiFi module the ability to manage atmega reset pin and, along with SPI interface, to program it directly even without the presence of a bootloader on chip.
In practice, once the firmware will be ready, it will be possible not only to reflash remotely the atmega controller but also to do it without need of a preloaded bootloader, giving user more space for sketches.
We end schematics description with the RTC (Real Time Clock), built around a well known DS1307 chip from Maxim, a 32 KHz crystal, a lithium backup battery ad a couple of pullup resistors on I2C line.
The module is exactly a copy of Maxim’s application note and is fully compatible with Arduino RTC libraries; all chip functions are managed by I2C line (SDA/SCL).
We’ve already seen that Fishino uses an USB/Serial adapter built around CH340G chip, which needs his own drivers, at least for Windows OS up to version 7. It seems that starting from version 8 the drivers are embedded on OS. On Linux OS drivers are already included in kernel.
Windows drivers can be downloaded from site, in Download section.
Fishino ships with latest firmware version available at assembly time. Being the firmware in constant development, we suggest to do an update before using it the first time and to repeat it periodically, as Arduino Fishino libraries are also constantly updated with new firmware’s features.
Upgrade process is greatly simplified by a downloadable application, available both for Windows and Linux platforms, wich does all needed steps automatically.
Upgrade steps :
If the application is unable to locate Fishino port, the problem comes likely from a sketch using Fishino’s serial port.
If all above steps are correct, the application will locate the serial port on which Fishino is connectet, read its model and firmware version, connect to a remote server and download a list of available firmware versions, showing the last one, anyways allowing the selection of an older one in case you want to do a downgrade, as shown in following picture :
Pushing ‘Flash’ button the firmware upgrade procedure will start and a message will be displayed at end.
To exit the firmware upgrade application just press Exit button.
If Fishino is not automatically detected it’s possible to select the port manually, even if it’s likely due to a connection error on steps above.
Manual port selection become useful if you have more than one Fishino connected on your PC; in this case the first one will be automatically detected, but you’ll still be able to choose another one manually.
Once upgrade process is done, it’s enough to remove connections between Fishino‘s pins and it will be ready to be used with new firmware.
Currently we developed a couple of Fishino‘s libraries :
Usage is almost identical to Arduino’s equivalents, so all you need to do is to change variables types to match Fishino’s ones to make existing code working on it.
The small differences are related to initialization parts, having Fishino more features than original WiFi shield.
We included also the Flash library in the download bundle, being this one used by FishinoWebServer to spare precious RAM space. This library is also available on internet, we just added it for convenience.
All other libraries are already embedded in Arduino IDE downloads and/or easily available on the web. In detail, we’ll need SD library to handle the microSD card and the RTClib library to handle RTC module, and the other usual system libraries.
Our libraries are still under development, so expect more features on next releases, for example the handling of ESP I/O pins, the ESP hardware serial port and others.
To conclude this article and to allow you to quickly test some of Fishino’s cool features we present in short the FishinoHomeAuto demo.
It’s a small web server that allows handling of Fishino’s digital I/O pins with a web browser and with a nice graphical interface.
Given the complexity of the example, we will just show it in short its setup and usage, in order to make you able o test its features quickly; we’ll write a more detailed description on next article.
We state that the demo is NOT a complete home automation application, but the basis to write your own one; in detail we just handle digital outputs (shown as home lights in following pictures). Software is anyway easily extensible, so we’ll implement more features on next releases, like digital inputs and analog I/O.
Unpack FishinoLibs.zip file in ‘libraries’ folder inside your sketchbook.
Once done, you’ll find following new libraries :
// CONFIGURATION DATA -- ADAPT TO YOUR NETWORK !!! // here pur SSID of your network #define SSID "" // here put PASSWORD of your network. Use "" if none #define PASS "" // here put required IP address of your Fishino // comment out this line if you want AUTO IP (dhcp) // NOTE : if you use auto IP you must find it somehow ! #define IPADDR 192, 168, 1, 251 // NOTE : for prototype green version owners, set SD_CS to 3 !!! const int SD_CS = 4; // END OF CONFIGURATION DATA
The application doesn’t write nor erase anything on SD card, so you can use a microSD card found, for example, in your smartphone.
If you want a visual feedback with leds turning on and off following web commands, connect one or more leds (with companions series resistors!) on following Fishino’s pins :
2, 5, 6, 8, 9, 14 and 15
Those are the digital output handled by the demo, each of them has an associated “room” associated inside browser’s floorplan picture.
This page is fully configurable just changing some files in your SD card. Because of tight space here we can’t explain it in deep, so we’ll postpone it to a next article.
Clicking on a light (off at startup, so black color) its picture will change showing an on lamp (yellow) and at same time a led connected to corresponding Fishino’s port will light. Clicking again on same lamp will turn it off again, and so will do the corresponding led:
As said, this demo doesn’t aim to be a complete home automation application but just a small example on how to use Fishino.
Anyway the app is configurable enough to allow you to change the floorplan picture, lights placement and pictures and so on.
We already started the implementation of analog data handling (for example to display a temperature value or to change it) which will be available on next releases.
With this example we conclude Fishino UNO‘s presentation.
On next articles we’ll show some other examples which use all remaining Fishino’s features and new firmware’s extensions.