I was a little confused about that board until I found this answer here, which says it does indeed have an Atmega 328 microcontroller on it, and this this photograph, showing the bottom of the board:
It is not so clear that is there from pictures taken from the top, and for whatever strange reason, the OEM's website and github page don't mention that explicitly at all, although looking at the examples there, and the fact that communication with the Pi is via serial imply the Arduino pins do not correlate to any of the GPIOs and it is, in fact, a pretty normal Arduino but with a 28 pin pass-through header that fits onto the Pi.
Presumably this means all it actually uses are power, ground, and (probably optionally) the UART, so you are free to use any of the GPIOs as you like independently of the Arduberry pins. I don't know if, e.g., the I2C pins are linked, but if not you could connect them normally.
"Normally" here means via a level shifter, since the GPIO pins passed through will still be 3.3V.
Although the other question says it will fit on 40-pin models and it should, notice that means it will cover up about a dozen extra pins at the bottom.
So other than a bit of convenience, I don't see a huge advantage to this vs. just connecting any other kind of Arduino.
access to the Rpi3 file system.
As jogco says, you'd have to implement that yourself. How elaborate that is depends on what you want to do; if you wanted to hook up controls and an LCD or something to broswse via the Arduino it would have to be pretty elaborate, but since it is hard to see what the purpose of just looking at lists of files is, more likely you would want to add a layer of abstraction that would make the implementation simpler and more focussed on a specific goal.
With regard to serial communication, it is much like network communication only there aren't, as far as I'm aware, protocols like FTP with commonplace implementations for both sides. A crucial abstraction layer which is fundamental to networking missing here are ports, such that one could connect independent processess to access an FTP server, a web server, etc.
However, you can accomplish much the same thing by using a simple protocol of your own in the way that you might implement some kind of custom network service, just in this case, the purpose is to provide multiplexing in a way similar to the how port numbers are used with IP based networking.
Network protocols prefix "header" segments to wrap data, and this is how ports are created by the transport layer (to be clear: ports are software abstractions, so e.g., there is no physical hardware port 80 in your computer intended to receive HTTP requests, etc. -- there is just the network interface, and it is the operating system that parses incoming messages to extract "port numbers"). In this case, all we need is a fixed length ID number.
If you use an 8-bit value, you have 256 different possibilities. If you use a 16-bit value, the usual size of an Arduino
int, you have 65536 possibilities. It's unlikely that you really need more than 256.
Note that you can create a hierarchy here to create an endless array of possibilities. E.g., ID tag 32 could have a further 256 subtags and so on.
So in this simple protocol, the primary ID is the first element of any message, to or from the Arduino. You then need a way to determine the length of the message, so you can read them in, break them up, and dispatch them appropriately.
The length could be associated with the ID tag, and quickly looked up that way. I use a look-up scheme like this:
Some IDs used fixed length messages that are always the same, so the message itself does not need to indicate this.
Some IDs use variable length messages, and this is indicated by the next one or two or four bytes, depending on the ID.
The look-up value is signed: If it is negative, the absolute value is a fixed length. If it is positive, it is either 1, 2, or 4, the number of bytes used to indicated the message length. Use cases for 4 bytes with an Arduino are pretty limited, but if you wanted to feed it a whole file this way that might be one such example.
Arduinos and Pis are both little endian and reading integer values from a serialized stream with either one is trivial.
You can elaborate the purpose of individual tags much the same way standard ports have specific protocols associated with them. For example, say ID 32 from the Arduino means fetch a file, using a 2 byte variable length indicator. A request for
/home/pi/whatever/foobar.txt would then be:
- An 8-bit message type ID (32).
- A 16-bit value (28, the length of the path).
- 28 ASCII bytes containing the path.
Notice I didn't bother with a null-terminator or anything. However, if an ID is always associated with text you could do that instead (but beware it results in an inefficiency, since you must then check the value of every byte). If you want to go beyond ASCII you're going to have to find, or write, a UTF-8 implementation (or something) for the Arduino.
Now lets say a message from the Pi with ID tag 40 is a reply to a file request. Depending on context, this might not have to bother including the path. If it does need to be differentiated, it would probably be better to make the original request slightly more complicated by using an message request identifiers that the reply header can also contain. But to be contrived, let's wrap a file's content and include the path in the header:
- 8-bit message type ID (40)
- 16-bit value indicating the length of the path (28)
- 28 ASCII bytes containing the path.
- 4-bit value indicating the length of the file data, e.g. 420661
- 420661 data bytes.
At 10 bits per byte for normal 8N1 UART communication, that's 1 + 2 + 28 + 4 + 420661 * 10 = 4206645 bits, meaning at the Arduino's top speed of 115200 baud that transfer will take ~36.5 seconds.
Of course, what you are actually going to do with it on the Arduino end is another question, and that is where things get complicated by the fact that the Arduino's serial buffer is 64 bytes (whereas the Pi's is 64 KB, and the Pi is fast enough, and has acres of RAM, making accumulating in a userspace buffer of whatever size easy). At 115200 bps, that means you have to make sure the buffer is cleared about every half millisecond -- simple enough if you can stop everything and just deal with it, more challenging if you must deal with it in a loop which is maintaining timing of other things.
Using lower baud rates may simplify life in some such contexts.