Android device as UI to pyboard

[Arc]

I want a pyboard to handle sensors and servos in a real-time application, but don't want to burden the board with handling the user interface as well. Instead I'd like to use a rooted Android ereader to provide slick buttons and display, and pass data both ways over USB.

Has something like this been done already? I'm new to SBCs, real-time programming and cooperating processes so I could use some prior art but am struggling to find practical examples.

Thanks

Anthony

[dhylands]

I'm fundamentally planning on doing something similar.

There are several ways to connect to the pyboard, all of which look more or less like a byte-stream/pipe.

1 - Use bluetooth. You can use the SPP profile, which then looks like a serial port on the android side of things. Many of the bluetooth adapters which you'd connect with the pyboard also connect via serial.

2 - Use WIFI. This is probably the simplest from the android side, and you'd need to use something like the CC3000 on the micropython side. You'd then connect to a socket and essentially wind up with a bidirectional byte pipe.

3 - Connect a UART on the pyboard to a supported OTG serial device on the android side (probably FTDI).

4 - Connect the pyboard directly into the phone, using an OTG adapter cable. This may require kernel drivers, but I'm not sure until I try it.

Personally, I'm leaning towards using bluetooth, since its wireless, and overall requires less resources on the micropython side of things.

I've also thought about using a web interface. For this, my android app would be a simple web server which can forward requests over Bluetooth SPP. Then I can just use web browser on the android side of things, and it would allow me to also use my desktop/laptop, if desired.

That's my own thoughts on this. Sorry I can't be much help yet.

[danpeirce]

My Pyboard should be coming soon so I have not tried any of this with a Pyboard yet.

I have found with PIC projects that a Raspberry Pi makes a nice interface between a PIC project and WiFi (or ethernet). Depending on one's existing LAN/WiFi setup it can be very easy to connect the Raspberry Pi to an existing wireless router. I expect the Pyboard could connect directly to a USB port on the Raspberry Pi. One can then use SSH over WiFi to connect from any tablet or phone (even if it has not been rooted). In this setup the Android is simply used as a terminal to control the Raspberry Pi which controls the target (Pyboard).

At the following link one can just imagine a Pyboard replacing the PIC18F2620
rpi_pic_led.html#headless-raspberry-pi-connected-to-pic18lf2620-connected-to-led

raspberry_pi#remote-command-line-interface-cli

ssh.html#remote-login-from-android-tabletphone

You may want to go a different way but I think the Raspberry Pi makes a very cost effective interface between projects and both ethernet and WiFi. They also have a newer model now that has four USB A plugs rather than just two. They have also improved the power distribution on the newer B+ board.

[dhylands]

I was just in the process of setting up a Raspberry Pi using OctoPrint to front-end my 3D printer, and figured I might as well try plugging the micropython board in and see what happens.

I plugged my MicroPython board into my RPi, and the serial device showed up as /dev/ttyACM0.

I added my username to the dialout group (in /etc/group) and logged out and logged back in (If you're using the pi user, then this should already be done. I was using my own user account so I could do passwordless login via ssh).

I installed and ran picocom (on the RPi):

Code: Select all

sudo apt-get install picocom
picocom /dev/ttyACM0

and got my micropython prompt:

Code: Select all

Micro Python v1.3.3-80-g95908b0-dirty on 2014-10-15; PYBv1.0 with STM32F405RG
Type "help()" for more information.
>>>

I was also able to mount the pyboard's filesystem:

Code: Select all

dhylands@octopi ~
39 >sudo mount /dev/sda1 /mnt
dhylands@octopi ~ 
40 >ls /mnt
boot.py*  foo.txt*  main.py*  pybcdc.inf*  README.txt*

[Arc]

Great info and search terms, including Dan's pic18_serial_io project, thanks to you both.

Suppose I make a virtual serial link from pyboard USB port to RPi USB (i.e. without FTDI interface).

AIUI I would program the pyboard to boot in CDC+MSC mode, run a 'main' script to sample sensors on a timer interrupt, and read and write to the RPi using usb_vcp.recv/send. On the RPi I'd connect stdin/out to /dev/ttyACM0 and run a script that looped reading values from the pyboard via stdin and controlling it by writes to stdout.

I'm unclear about the 'bidirectional byte pipe': is this possible with virtual serial over USB, given that USB is a host/device connection i.e. master at one end? How are the CDC and MSC modes kept separate: could the pyboard waiting to read a character corrupt a file write by the RPi?

Also does one of the pyboard timers have a higher interrupt priority, so that if DSP hangs the pyboard could be told to disable the DSP's timer or execute pyb.bootloader?

Thanks

Anthony

[dhylands]

Great info and search terms, including Dan's pic18_serial_io project, thanks to you both.

Suppose I make a virtual serial link from pyboard USB port to RPi USB (i.e. without FTDI interface).

AIUI I would program the pyboard to boot in CDC+MSC mode, run a 'main' script to sample sensors on a timer interrupt, and read and write to the RPi using usb_vcp.recv/send. On the RPi I'd connect stdin/out to /dev/ttyACM0 and run a script that looped reading values from the pyboard via stdin and controlling it by writes to stdout.

I'm unclear about the 'bidirectional byte pipe': is this possible with virtual serial over USB, given that USB is a host/device connection i.e. master at one end? How are the CDC and MSC modes kept separate: could the pyboard waiting to read a character corrupt a file write by the RPi?

The usb serial is essentially a bidirectional byte pipe. The pyboard looks like a composite device. So CDC and MSC are available at the same time. The RPi is a linux host, and it behaves just like any other linux host, so there are no differences on that front. USB is still a polling protocol, so the pyboard technically can't push character to the host, but any usb host which has a serial port open will wind up polling the other end frequently to determine if characters are available, so for all intensive purposes it looks the same as regular serial.

Also does one of the pyboard timers have a higher interrupt priority, so that if DSP hangs the pyboard could be told to disable the DSP's timer or execute pyb.bootloader?

You introduced the term DSP without clarifying what it was. Neither the pyboard nor the RPi are DSPs or have DSPs, so I'm not sure what you're referring to.

If the pyboard is hung, how is the pyboard going to tell DSP to do anything? Executing pyb.bootloader isn't particularly useful. There will probably be a hard_reset function added soon.

If by DSP, you meant RPi, then if its hung, it will never see anything from the pyboard.

Thanks


Anthony[/quote]

[BobM]

The use of DSP confused me too. I got even more confused when I looked at the ST405xxx data sheet. I quote

It also implements a full set of DSP instructions...

but inspecting the programming manual doesn't reveal any instructions specifically designed for DSP. (Quite likely I haven't looked in the right place but there's no DSP entry in the table of contents.)
Um!
Now to drift off the original topic.
Since it has both ADCs, DACs and a floating point unit, I guess it could be used for DSP applications. The maximum sampling rates are not completely obvious from the data sheet but (allegedly) 2Msps is achievable from a simple setup. So (Nyquist) we ought to be able to handle signals up to 1MHz (but maybe 200KHz would be saner). Multiply these figures by 3 for the most complex triple-shared ADC setup.
The limiting factor seems to be the DAC. Under ideal conditions (no large transients) it can allegedly handle 1M input changes per second.

[dhylands]

So it turns out that the Cortex M4 has some DSP instructions:
http://infocenter.arm.com/help/index.js ... DIGAC.html
Look for table 3.2

[Arc]

Nice to learn about the M4's DSP instructions - I had assumed this had to be done in s/w. I'm looking forward to when there's a microPython framework for real-time coding without the GC, clock timers etc. intruding, showing how to do I/O with low jitter and process the results. Other threads suggest DMA is needed so perhaps a framework will take a while...