SyntaxBomb - Indie Coders

hmmm.. I need to look into this a bit more, but for now you can do this:
n = p3.write(address, [alsConfReg, alsConf])

Here an update:

IOIO is working fine on PC and Android. We wrote the following examples, showing how to use IOIO with different protocols:

- BH1750 (ambient light sensor, I2C)
- BME280 (humidity sensor, I2C)
- Button (digital input)
- Duino-1088 (LED matrix, SPI)
- HD44780 (Text display, digital output, slow but usable)
- LED (digital output)
- MPU6050 (Accelerometer, gyroscope and temperature sensor, I2C)
- PWM (digital output)
- Potentiometer (analog input)
- SSD1306 (OLED, I2C, slow but usable)
- ST7735s (LCD, SPI, too slow)
- ST7789 (LCD, SPI, too slow)
- VEML6030 (Ambient Light Sensor, I2C)

You can find these example on Github: https://github.com/smallbasic/smallbasic.plugins/tree/master/ioio/samples

Getting IOIO running on a PC (Linux) requires to build the plugins from source. Not straight forward. You should know what you are doing. I hope Chris can make it easier in the future. Maybe I should provide a better documentation.

Using IOIO on Android is quite easy (but still experimental). Here a short howto from Chris:

- Launch SmallBASIC and then click Setup.
        - On the second screen, click to Load extension modules.
- Restart SmallBASIC and then click About
        - You should see: Extension modules: enabled.
- If you have enabled Android developer options, make sure USB debugging is disabled.
- On your ioio-otg board, connect a power source to the VIN + GND (9v battery worked for me).
- Connect a USB cable between your mobile and the board (I used the included red adaptor plus another cable).
- You should see "IOIO Standard application - no installed apps".
- Launch led.bas
        - You should see a prompt requesting permission for SmallBASIC to access the board. Click okay.
        - You should then see a toast message: IOIO board access permitted.
- For this initial setup led.bas has now timed out
        - You should be able to re-launch led.bas for successful operation.

You have to connect power to the board, because it will act as a host and it will charge your Android device. Instead of a battery, I connected a 5V power supply to the VIN and GND pins.

I will provide an article with more details on the SmallBASIC website. But as always it will take time.

You can find more information for the IOIO board here: https://github.com/ytai/ioio/wiki
An overview of all supported functions in SmallBASIC is here: https://github.com/smallbasic/smallbasic.plugins/tree/master/ioio

Looking good 

What speeds are I2C and SPI actually capable of?

Craig

Speed limitation comes mainly from overhead of sending commands to the IOIO board. Sending a single command, no matter if it is for setting a pin to high or sending a byte via I2C, takes around 5 ms. I think it is not a limitation of SmallBASIC but most probably overhead of transferring data through the cable and processing it on the IOIO board. I2C and SPI can send an array of bytes with around 50 elements in one go. This takes only 5ms. Communicating with a sensor via I2C was no problem. You can receive data every 20ms (approx.). If you want to fill a LCD with 1 million pixels in RGB, a lot of single commands have to be send to the board (every time 5ms). Same is true, if you want to do bit banging (fast switching of pins high/low).

Quote from: J7M on July 24, 2024, 08:18:51Speed limitation comes mainly from overhead of sending commands to the IOIO board. Sending a single command, no matter if it is for setting a pin to high or sending a byte via I2C, takes around 5 ms. I think it is not a limitation of SmallBASIC but most probably overhead of transferring data through the cable and processing it on the IOIO board. I2C and SPI can send an array of bytes with around 50 elements in one go. This takes only 5ms. Communicating with a sensor via I2C was no problem. You can receive data every 20ms (approx.). If you want to fill a LCD with 1 million pixels in RGB, a lot of single commands have to be send to the board (every time 5ms). Same is true, if you want to do bit banging (fast switching of pins high/low).

Oh dear. Totally unusable for me. 5ms is an eternity. The Picomite interpreter on the RPi Pico can execute a minimum of 100,000 commands/sec and I have SPI running at 20MHz 

Craig

Yes - The SPI limitation seems to be in the communications protocol between the java side and the IOIO firmware where only a limited amount of data can be sent per command.

It could potentially be resolved by the IOIO-OTG team, but this would entail a firmware update.

For android this doesn't seem to be neccessary - there is already a screen! Plus as we've shown, the low bandwidth devices work quite well.

Also - maybe I'm wrong here. If some one could point to java code achieving better SPI results, please let me know.

So, back to the Bluetooth question...on the to-do list? 

It looks like I'd just need to include the code from IOIOLibAndroidBluetooth and then have some way to favour that instead of the accessory connection. I guess something as part of the SB program.

This just needs a blue-tooth dongle attached to the ioio-otg right?

Also - I started messing around with porting the firmware to teensy 4.0. It got a little way down the road, but not sure whether to abandon it.

Quote from: chrisws on November 20, 2024, 10:41:45It looks like I'd just need to include the code from IOIOLibAndroidBluetooth and then have some way to favour that instead of the accessory connection. I guess something as part of the SB program.

This just needs a blue-tooth dongle attached to the ioio-otg right?

Also - I started messing around with porting the firmware to teensy 4.0. It got a little way down the road, but not sure whether to abandon it.

I refer to the internal device BT (or is it already in SB and I missed it?), it's obviously a key-feature of a mobile device. I use it as a wireless UART (serial port profile). Extremely robust protocol, even in an industrial environment.
There is "classic" BT and then there is BLE. My preference is classic but other Android programming tools support both.

SB in a MCU would totally rock 
Craig

Quote from: Tinine on November 20, 2024, 11:12:41

Quote from: chrisws on November 20, 2024, 10:41:45It looks like I'd just need to include the code from IOIOLibAndroidBluetooth and then have some way to favour that instead of the accessory connection. I guess something as part of the SB program.

This just needs a blue-tooth dongle attached to the ioio-otg right?

Also - I started messing around with porting the firmware to teensy 4.0. It got a little way down the road, but not sure whether to abandon it.

I refer to the internal device BT (or is it already in SB and I missed it?), it's obviously a key-feature of a mobile device. I use it as a wireless UART (serial port profile). Extremely robust protocol, even in an industrial environment.
There is "classic" BT and then there is BLE. My preference is classic but other Android programming tools support both.

SB in a MCU would totally rock 
Craig

I lost interest in the firmware idea although it was a good exercise learning about cmake. I decided to try building a smallbasic.hex to run directly on the teensy. I currently have this running printing to the Serial (USB) and also turning the LED on and off similar to the ioio-otg example. Next is to be able to output to a ssd1306 LED display screen.

The build in the test channel now has (experimental) BT support.  For details:
https://smallbasic.github.io/pages/android.html

Quote from: chrisws on April 23, 2025, 00:07:29The build in the test channel now has (experimental) BT support.  For details:
https://smallbasic.github.io/pages/android.html

Oh heck, SUPER exciting 
Won't be able to test until weekend.....Is there a receive buffer?