Here's a quick mock-up of the RasPi service UI.
Having a pin out reference I always find useful ... can prevent blue smoke sometimes :)
Alexinator40 and Ray have been suggesting a generalized I2C interface. I think components from the Serial service can provide a UI which allows for generalized reads and writes to devices on an I2C bus.
The buttons on the right would be just to read and write GPIO pins..
Not sure .. got to start somewhere.
A good place to start :-)
The GPIO pins on the Raspi could be potentially used for any digital interface similar to what the Arduino does.
In general the GPIO can be configured as an input of an output.
None of the GPIO are analog, but that just simplifies it a bit :-)
Like the Arduino, some of the GPIO pis are multi-function:
I2C on GPIO02 and GPIO03
SPI on GPIO09, GPIO10 and GPIO11
I2S AKA PCM on GPIO18, GPIO19, GPIO20 and GPIO21
TTL Serial on GPIO14 and GPIO15
PWM on GPIO GPIO12 and GPIO13
The ability to access and use the GPIO could be very useful instead of having to add another breakout board to have digital IO via the I2C which already has the service for the PCF8574
The generalized I2C interface could be used not just on the Raspi3 but also on the Arduino with it's I2C interface, the generalized I2C would allow for experimentation with new I2C devices that specific services have not yet been created for and I would suggest that it not be considered an expansion of the Raspi service but as a separate service in its own right.
The major thing that's required for the generic I2C service is the ability to convert or cast byte data (I2C native format) to other data types. An array of 4 byte can represent a float, or real value, just split up for the purpose of transmission on the I2C bus.
The Python service (jython) is very good for beginners to the world of robotics, and being able to use the I2C for new types of I2C devices within Python would be a major advantage.
USB Cam --> RasPi -->
USB Cam --> RasPi --> mjpg-streamer --> http/mjpg over network --> laptop --> mrl --> opencv --> browser
Very little if any noticable
Very little if any noticable difference between aiming a browser directly at mjpg-streamer vs aiming a browser at localhost running the webgui and using OpenCV's mjpeg to stream.
The second route is going through an additional filter lkoptical track too, while converting the binary opencv image into a base64 jpg to be displayed.
Some frames are skipped.
Terrible and mrl is running at 110% on the raspi :P - slow fps and high latency (calcualations are still messed up :P )