Customizable Macropad

Its been a long time

Sorry for my absence i have been stuck in the hell that is queues.
In this devlog i will cover how to communicate through serial

I am by no means a good software dev but after many long nights of banging my head against the wall i think i have somewhat of a decent system and understanding of this topic

Speaking Serial

In my last devlog i mentioned the idea of running complex programs on toaster level components by using a wire and a computer, this wire is communicating through a serial bus, which is simply a pathway that communicates information or bits through a single channel, emphasize on the idea of the single channel.

So first we have to establish the serial and how its gonna operate. During this entire log all info will be in c++ and python.
Arduino Section(c++)

#include <Arduino.h>
#include <SPI.h>

void setup() {
    Serial.begin(115200);
}

Pc Side(python)

from serial import Serial
import time
def connect(port):
    try:
	    serial = Serial(port.device, baudrate=115200, timeout=1)
	    time.sleep(3)

So some things to note, set the baud rate for both connections the exact same. Baudrate is essentially the speed of transfer a higher baudrate means faster communication, which in turn needs a stronger wire/cpu to process more info faster. in addition ensure on the pc side after opening the serial connection to add a delay you need to let the micro controller reset and settle its connection.

Communication
From here you need a way to actually communicate, say you have a simple keyboard and its connected to your computer and a user presses a button which is gonna open steam, unfortunately its not smart to just send a serial message to open steam as each character/Letter depending on the encoding can contain multiple bits which each need to be streamed through the serial and received by the pc. So its best to setup a pallet of commands both sides know what each command is and the command is simply just a single bit.

Commands
Arduino

enum Command : uint8_t {
    CMD_HANDSHAKE = 0x00,
    CMD_HANDSHAKE_ACK = 0x01,
    CMD_HEARTBEAT = 0x02,
    CMD_DRAW_IMAGE = 0x03
};

To differentiate commands:

void resolveCMD(uint8_t cmd, uint8_t display) {
    switch (cmd) {
      case CMD_DRAW_IMAGE:
        #code
      case CMD_HANDSHAKE:
	    #code
	 }
}

Commands can be expanded up to 256 different types, with each one still taking one byte. Now in this scope the computer or arduino send the command through the serial and the other side just does it, heavy lifting stuff is typically done on the pc for example loading and storing the images i want to display (here’s the snippet for that):

from PIL import Image
img = Image.open(base_dir / folder / img_filename)
width, height = img.size
pixels - img.load()
while True:
    #check for arduino ready state
    packet = bytearray()
    #append display, width, height to packet
    self.manager.write(packet)
    buffer = bytearray()
    for y in range(height):
	    for x in (width):
		    r,g,b = pixels[x,y]
		    rgb565 = (((r & 0xF8)<<8|((g & 0xFC) <<3\(b >> 3))
		    buffer.extend(rgb565.to_bytes(2, "big")
		    #when buffer is above 512 len send to arduino

Unfortunately i am close to the character limit and i hate reading long stuff so i dont want to go on a yapathon. If this is the type of devlogs people like my next one will go heavy in to depth on running a good queue, which plays in turn with the serial, making it more efficient and allowing a more complex system. Check out my git hub (https://github.com/Cunning077/HackPad) as well, all the code for this project is there im terrible at documentation but if it can provide a example or help or if you want to help me i would be very grateful.

Enjoy Summer

Weekly Devlog #3

Even a toaster can run minecraft

This weeks primary focus was software and turning 2 blank display screens into actually functional and usable keypads.
To start i need to define the limitations, for one in the final version of this project there will be 6 240x240 displays, each display having 57,600 pixels, which amounts to around about 1.105 Mib, for reference the Arduino Uno has 32Kb of flash. So i definitely cant just send raw c files for the pixels and simply load then through the Arduino, But why don’t i just load the c files onto a SD card and simply just have the Arduino stream the pixels from the SD card to the display, well i can but who wants to deal with the hassle of loading a SD card and putting it back into whatever contraption i come up with for a case, One of the main pillars of this project was to make it as easy as possible to customize what you want the hackpad to do and i find it to risky to assume anyone can find the SD card and load it properly without problem, i for one cant stand SD cards especially the breakout board readers.

So here’s where i reveal the big solution, the world changing revolutionary problem solving out of this world solution:

Im gonna stream the data through serial.

Essentially the Arduino (or whatever micro controller i use) will simply be a receiver and the host computer will be a sender. Now this introduces some limitations for example you can only send data so fast especially when your wire is bad, additionally im not sure what type of strain this will put on the hosts computer, while im also not sure how im gonna handle multiple events, but indue time i will flush out these problems and implement something that will surely make sense.

This Log is way shorter than my last and doesn’t really offer any insight or helpful information so i apologize but if you haven’t read my last one i attempted to instruct how to build the prototype displays i think its very informative and also maybe you can steal this project and actually make it good. I promise next week i wont disappoint :)

Im late on this one because the displays refused to print images so it took me a day to get the image 😔
**

Weekly Devlog #2

This week i started prototyping the design decisions i had made with the PCB to ensure before manufacturing it works. So i wanted to simulate most of the important factors like the 74HC138 circuit i would use to control the 6 TFT display boards, while also checking whether 3.3v would properly power the board, in addition i plan to run tests to see in the current design how much power pull will be pulled from the computer to power the hackpad. Included in this is also instructions on how to build the full protoboard which can very easily be expanded to include up to 8 TFT displays. This prototype version doesnt include switches which will be next weeks addition including building the foundational code for the entire board.

Instructions

To begin i first put in each component of the board:

• 2x TFT 1.28 inch Display
• 1x 74HC138N circuit
• 1x Arduino Uno R3

Each component besides the Arduino can be found in the first accompanying image with the round board being the TFT display and the rectangle box being the 74HC138N circuit, not shown is the Arudino Uno i believe any mainstream microcontroller can be used for this, just follow the pins.

Power Management

From there its best to start on power management utilizing the rails on the breadboard i connect the Arduino Unos 3v3 pin and any gnd pin to the respective holes on the board. In total i use 5 positive wires and 6 negative wires. The TFT boards power management setup is straight forward follow the writing on the board, however the more difficult section is the 74HC138 which in total needs 4 separate power wires.

To start wiring it find the tiny hole on the actual circuit itself its a little divot in the box, 3 pins down from the top pin on the side of the divot is E0, which the next two pins below it is E1 and E2. These control the setting of the controller, to achieve the setting we want we need to wire E0 as low or GND E1 as low and E2 as high or 3V3, from E2 skip the next pin going down from E2 and the final pin on the left side of the controller is the GND pin. Finally the last pin needed is the pin to the right of the little divot mentioned earlier this is the VCC.

TFT Logic

The next step is where the wiring gets almost unbearable (jumper cables am i right), this is the logic section where the tft boards pins will all be filled up. To start in a section of the breadboard where the is no other connections to the column of holes we need to create our own bus. We need 4:

• RST
• DC
• SDA (SCK)
• SCL (MOSI)

To create the bus just connect 3 wires in the same column these wires will now share the same electrons. from there simply connect the the first wire of the column doesnt matter which direction it just is best to make sure its the first one in that column. The pin for the arduino is as follows:

• RST - Reset
• DC - 9
• SDA - 11
• SCL - 13

Make sure to connect the wires in that bus to the pin of the tft board it corresponds to

74HC138 Logic

The final step is the logic for the 74HC138 circuit which requires 3 digital pins which handle the selection of the outgoing pin to the CS. To start the 2nd pin on the left of the divet in the circuit is A0 the next 2 pins are A1 and A2 each of these pins need to be given a digital pin i wired it to pin 7, 6 and 5 i believe any pin would do. Lastly the 6 pins below the VCC and the pin above GND are the actual output pins these can be wired to the cs of the tft displays to allow information to flow and commands. Simply wire Y0 and Y1 which are the first two pins below the VCC to one displays CS and the other to another CS.

Conclusion

Now you have a working multi display breadboard, in my GitHub i will link the code for the prototype board. In addition each section has picture linked which are shown in order of the instructions sections, if my instructions suck simply look at the photos and hopefully it will clear any confusion

Weekly Devblog #1
This week marked the beginning of the Hackpad project. The primary goal of the project is to expand my skills in hardware design and embedded systems development. Since I had no prior experience designing custom PCBs or working with CAD software, much of this week was spent learning the fundamentals and overcoming the challenges involved in creating a functional board layout.

The main focus was PCB design, which proved to be one of the more difficult aspects of the project so far. Learning the workflow, component placement, routing, and design constraints required a significant amount of research and iteration, the final schematic linked is my 5th version. Despite the learning curve, I was able to make steady progress and gain a much better understanding of the PCB development process.

In parallel, I began analyzing the bill of materials and estimating hardware costs. Based on current pricing, the prototype is expected to cost approximately $37 per unit. The largest contributor to this cost is the set of six TFT display modules. Since these displays are readily available in bulk quantities, there is potential to significantly reduce manufacturing costs, with projected per-unit costs falling below $25 in larger production runs.

Overall, this week was focused on establishing the project’s foundation, learning new tools, and creating the initial hardware design while beginning to evaluate the project’s long-term production costs.