Andy GeppertAfter a wide survey of options, I think there are two architectures that standout for this project. The first one meets the MUST HAVE requirements and the second one exceeds the NICE TO HAVE requirements with significant benefits and capabilities. I welcome feedback and discussion on this fork in the road!
ARCHITECTURE V1 (OLED with I2C simplicity):
- Display is OLED with I2C control directly via SAO I2C lines.
- The two knobs are analog pots, each connected to GPIO 1 and 2 of the SAO port.
- Accelerometer is connected to the SAO I2C lines.
Architecture V1 is the easiest and most direct path to a solution. But it lacks the ePaper, which I think is the magical element that will really make the Etch sAo Sketch pop. OLEDs are nice, but I think people will enjoy ePaper more. This will be my starting point. Maybe using a fully illuminated OLED display, with the drawing point being OFF pixels will sell the look?
ARCHITECTURE V2 (ePaper, I2C-to-SPI bridging, standalone MCU operation, with even more benefits):
- Display is ePaper, which is only available with a SPI interface. Minimal [enough] SPI functionality could be bit-banged through the 4 available SAO lines, but this deviates from the I2C bus standard expected with SAOs. Therefore, I2C to SPI translation is needed. A dedicated solution exists as an NXP SC18IS606 I2C to SPI Bridge, about $3 in low volumes. But a DIY MCU bridge could easily cost less. See MCU point further down...
- The two knobs are still analog pots, optionally connected to SAO GPIO1&2, or tied to the MCU onboard the SAO, enabling stand-alone operation.
- Accelerometer is still connected to SAO I2C lines, and optionally accessible by the onboard MCU.
- The MCU. I could roll my own dedicated bridge on a low cost MCU like this, but I'd like to pick up a lot more functionality by using a small pre-made MCU board. Considering capability, compatibility, support, ubiquity, price, a desire for USB-C to Arduino simplicity... leads me to the RP2040-Zero and ESP32-C3. Both of those are available for < $2. I really like the drag-n-drop simplicity for firmware on the RP2040 (no IDE needed), but I also like that the ESP32-C3 opens the door for this SAO to access Wifi and BT. Perhaps I can configure the footprint on the back of the SAO to work with either board. Otherwise, it's likely the RP2040 simplicity is going to end up in this architecture.
- I2C to SPI Bridge: I can do the direct ePaper/SPI heavy-lifting in the ESP, and offer a simplified (and customizable) protocol to the SAO port in either I2C or UART (UART per the SAO standard). And maybe this DIY I2C-SPI bridge could be a spin-off project library to benefit the SAO community and beyond.
- Having a configurable I2C to SPI Bridge in an MCU also opens the door to other SPI displays, like multi-color OLED and TFT options. This I2C constraint really only exists in the SAO port right now, so not sure that's a big seller. Although, Badge Life and SAOs would benefit more. Considering the whole impetus of this project and the Supercon Add On contest is to stretch into more I2C functionality, why not open the door to SPI too?!
- Does this mean the SAO becomes the badge?
Architecture V2 is going to be my extra credit project.
Can I complete both by October 15?
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
My SAO is rapidly becoming a badge in its own right. I have a drawing API written, a method for writing data to memory, and a preferences setting methodology. Even a factory reset is on the docket. While I'm not providing direct access to the display from the host badge, it's close enough for a given user to accomplish what they want.
I'm a software guy more than a hardware guy. If it were me, I'd just bridge the i2c to SPI through software on the MCU. Might not be your proverbial cup of tea though.
Have you considered doing the knobs with encoders?
I'm excited to see where you take this project. It's really cool!
Are you sure? yes | no
Awesome - I would like to follow your lead on that level of API bridging. I'm going to knock out the OLED version first, so that'll be all I2C. Then I'll try to squeeze in the ePaper version with the software bridge you suggest - at least get a prototype running before Supercon.
I did consider encoders, but I'm going to try "cheap" analog pots first, for the sake of analog signal and analog feel. I think having analog inputs on the GPIO1&2 of the SAO will be a fun twist for folks. In the ePaper version with ESP32, I'll optionally route the analog pots to the ESP32 as well, and maybe provision to try some encoders too.
But I gotta focus on that OLED version first. After the Core4, the Demo Controller, and a Nunchuck SAO... go go go!
I like your trick to solder the screen behind the board without thru-holes on the front!
Are you sure? yes | no
I will say this...it seems that the focus on SAOs this year (and the contest) are helping to shine a light on some of the technical issues that have thus far kept SAOs simplistic. For example, now we're talking about SAOs that have to have their own internal I2C buses for their own hardware, while still communicating with the main badge over I2C. Like you said, at what point does an SAO become complicated enough to be considered badge?
As an example, I figured it would be easy to just do another spin of my cyberdeck SAO, but this time run the I2C lines to the header. But wait...the MCU on the SAO is communicating with the OLED on those lines, so what's going to happen when other devices tap in and potentially want to start talking? In that case, it would make more sense to just do a cyberdeck version without the onboard MCU, allow the badge to drive the screen and LEDs directly. But then the SAO becomes useless on any other badge...
For the record, I don't think this is a bad thing necessarily. We need to know where these pain points are. But it's all a bit trickier than we initially imagined it would be.
Are you sure? yes | no
I agree with your sentiments. I'm planning to address the particular challenge of demoing otherwise MCU-less SAOs with an SAO DEMO CONTROLLER. I plan to bring the SAO Core4 which doesn't have an MCU and needs a brain to work. So the SAO DEMO CONTROLLER is a simple "SAO plug + RP20240 Zero + SAO socket" that drives the Core4. This makes it easy to show people what SAO Core4 does and gives them the option to wear it around to demo as is, or make their own interface. https://hackaday.io/project/198034-sao-demo-controller
Are you sure? yes | no