roboryman / prototroller Goto Github PK

Used typically for menu traversal or movements. Four buttons that can be pressed to provide directional inputs.

The gyroscope utilizes measurements of angular velocity, typically tilting the controller is enough to register a reading.

Design of the chassis PCB, i.e., the PCB that will go into the chassis the user holds. This consists of setting up design rules and footprints, layout, and routing.

The user may shake, jerk, or otherwise move the controller to provide X, Y, and Z axes acceleration inputs.

Figure out how we can speed-up the SPI baud rate w/o breaking things. I think a good target baud rate for ensuring fast response time is 10 Mbps (right now, we are managing 1 Mbps). This 10x speedup would net us a total poll of 5ms when all 25 modules are connected (assuming there are 256 data bytes + a few handshake bytes = 260 total bytes). It seems if we raise it past 1 Mbps on both master and module ends, things start breaking. We really need to delve into the RP2040 datasheet and see what is going on. And, in the process, try not to break TinyUSB...

These chips don't seem to exist but can easily be created from 1x 2-to-4 line decoder and 4x 3-to-8 line decoder chips.

Our module board design(s) will require quad SPI flash memories to store program code (text), as the RP2040 does not do this internally.

Design of the generic module PCB, (leaving space for specific component interface). This consists of setting up design rules and footprints, layout, and routing.

Our module board design(s) need to allow a way to flash and/or debug our RP2040. USB is pretty much out of the question since these boards need to be tiny (currently, we are targeting 20mm x 20mm for 1x1 modules). We can look into achieving this with SWD, perhaps by placing pads on the PCB and finding a way to automate flashing large amounts of modules (so we do not have to do each by hand).

Our integrated board design needs to allow a way to flash and/or debug our master RP2040. Additionally, we need a USB port for TinyUSB communication between mater and host. Finally, power needs to be delivered to the entire Prototroller. All of these things can be accomplished using a single USB port exposing the data, VCC, and GND lines to the integrated board.

Go into detail about how to build, run, and modify (board requirements, CMake, etc.)
Discuss the project: motivations, architecture, user story, etc (take from Design & Development Plan, Design Mockup, Pre-Alpha Build).

Our module board design(s) may require an external crystal oscillator for a stable frequency source to the RP2040. While the RP2040 has an internal oscillator, they recommend feeding the clock from an external oscillator. So, step 1 is determining if we can use the internal crystal with the high frequencies we will likely need for SPI (>= 10 Mbps), step 2 is picking a crystal oscillator that fits those constraints, and step 3 is designing around the selected part.

When pressed, the input is pulled low until pressed again, from which input is pulled back high.

Used typically for games that take 4 unique inputs. The user may map these buttons to any action/key they desire. Pushing a button incites an action.

Create a component abstraction layer between the component and slave that allows you to easily specify modules based on available RP2040 peripherals and the component I/O. Modules will use functionality this layer provides in their own wrappers. I.E., separate out the lower-level details of the RP2040.

Ideas:

• GPIO (Button might implement this in wrapper)
• ADC (Joystick might implement this in wrapper)
• I2C (OLED, Accelerometer might implement this in wrapper)
• SPI
• UART
• PWM
• PIO (WS2812 LEDs might implement this in wrapper)

Example: For GPIO, we might make an init function that initializes a pin for input with internal pull-up, and a read function that returns the pin status (HIGH or LOW). The button wrapper can utilize these functions on the specified pin to read in the pressed status for transmission to master.

Will function very similarly to a slider, with the exception that this is a 1x1 module that takes twisting action as input.

Can be programmed as a light-emitting output. No form of user interaction aside from the action that leads it to be turned on.

Our integrated board design will require a quad SPI flash memory to store program code (text) for the master, as the RP2040 does not do this internally.

When a module is snapped to the Prototroller, there should be a solid electrical connection for the following 6 pins between the chassis and the module: VSYS, GND, SPI TX, SPI RX, SPI SCK, SPI CSN. The VSYS, GND, SPI TX, SPI RX, and SPI SCK pins are shared among all modules. The SPI CSN pin will be wired to a specific chip select from the 5-to-32 decoder.

We might do this a few ways:

• Contact pads. This is what that MIDI product seems to do, bonus if we can somehow make it magnetic and also solve the physical connection problem. There should be plenty of space for 6 contact pads.
• Female headers on chassis, male pins on module. Pins could be bent in module transit, but we wouldn't have a bunch of pins sticking out of the Prototroller at all times. You would also need to orient correctly.
• Pins on chassis, female headers on module. This has the advantage of pins not sticking out of the modules, which could be bent in transit. The disadvantage is that we would have 25*6 =150 pins sticking out of the chassis at all times. You would also need to orient correctly.

Our integrated board design will require a voltage regulator to convert the 5V VBUS to a stable and clean 3.3V to feed the RP2040s (master and modules).

Our integrated board design may require an external crystal oscillator for a stable frequency source to the master RP2040. While the RP2040 has an internal oscillator, they recommend feeding the clock from an external oscillator. So, step 1 is determining if we can use the internal crystal with the high frequencies we will likely need for SPI (>= 10 Mbps), step 2 is picking a crystal oscillator that fits those constraints, and step 3 is designing around the selected part.

We need a way to physically "snap" or connect the modules to the Prototroller chassis. Here is a page describing the different types of snap fits. We have access to 3D printers, so we can definitely create a model for at least the module portion. For the actual protogrid chassis, we might have to get a bit creative. It would be best if we designed a single model for the entire chassis and superglue/screw directly to it (or have clips to hold the two together).

Can be used to provide analog input varying between 0 V (all the way to the left) and 3.3 V (all the way to the right).

The user will need to press a rescan button to indicate they have connected new modules, from which the master attempts an identification handshake on all possible chip selects. Design the module for this (simple GPIO and pull-up resistor, but we may have to creatively place this on the Prototroller itself).

In our haptic feedback design on the grips we can use something like this in conjunction with our master DAC, or better yet, in conjunction with a dedicated driver (with effects).