Week 4: Electronics Design

Research

I have little to no experience in this department and so I think a lot of my time this week will be spent becoming familiar with the uses of the componenets themselves, the communication systems, and how they all fit together. I'm going to use ChatGPT 5 as a means to gain some baseline understanding (the converstaions will be linked at the bottom of the page). To get a more indepth understanding if needed, I will then likely continue to more detailed and specialized resources.

Communication Systems

After talking to ChatGPT and based on what was mentioned on the class website I learned that there are four main communication systems that might be used: I²C (Inter-Integrated Circuit), SPI (Serial Peripheral Interface), ADC (Analog-to-Digital Converter), and UART (Universal Asynchronous Receiver/Transmitter). Below is a summary of the information I learned in my converstaion with ChatGPT

I²C (Inter-Integrated Circuit)

Communication is send through a 2-wire bus using the SDA (serial data) and SCL (Serial Clock) pins on the microcontrollers. It works in a master/slave relationship; the master typically being the microcontroller and the slaves are the sensors/displays. The data is sent in packets controlled by the clock pulses.

Pros

• Super efficient pin wise, only needing two
• Supports multiple devices very easily
• Widely accepted for sensors

Cons

• Not very fast
• Bus is shared and so you can run into jams when using too many devices
• Good for short distances ~ 1 m, doesn't work much longer thatn that

Beneficial for connecting a bunch of slower components, ie. temp. sensors, accelerometers, clocks and for short distance, board to board communication.

SPI (Serial Peripheral Interface)

Communication is sent through MOSI (Master Out Slave In), MISO (Master In Slave Out), SCLK (Clock), CS/SS (Chip Select/Slave Select - one per device). The master provides the clock and contorls which slave is active. The data is also shfited in and out on each clock pulse.

Pros

• Much faster thatn I²C
• Can communicate with multiple slaves simultaneously

Cons

• Requires at least 4 pins +1 for each additional device
• Not great for long distances

Beneficial for high speed data transfer: displays, SD cards, or memory as well as high speed sensors such as gyroscopes or radio modules.

ADC (Analog-to-Digital Converter)

Converts a continuous analog voltage into a digital number. The resolution depends on how many steps the ADC divides the voltage into.

Pros

• Lets digital systems process real world data
• Built into most microcontrollers
• Works seamlessly with sensors

Cons

• Resolution and speed are finite, loss of precision
• Can be noisy

Useful for reading a potentiometer, joystick, dial, batteries. Also good for audio capture and interfacting with other analog sensors such as temp. probes or strain guages.

UART (Universal Asynchronous Reciever/Transmitter)

Communication is sent in serial, each bit of information is sent one at a time along a single wire. Uses the TX (transmit) and RX (recieve) pins on microcontrollers to communicate. They do not share a clock line and so they must set a baud rate (bits per second).

Pros

• It only uses two wires and so it is quite simple
• Better for long distances ~15 m while using lower baud rates
• Widely supports

Cons

• Only enables communication from one device to another
• Limited number of UART communication pins on microcontrollers

Beneficial for GPS modules, bluetooth, Wi-Fi, or celluar modems.

Getting Situated

I started using by using the Falstad AVR8JS simulator, allowing me to use code as well as see the analog side of the circuit. I quickly left it behind as it is mostly an analog simulator as opposed to a digital simulator which I would need for any of the projects that I wanted to work on. I ended up using Wokwi for the week.

Project Plan 1...

This week I want to try and design a device for sailing. I am on MIT's varsity sailing team and I practice Tuesday through Friday every week. I think it would be super valuable if during practice I was able to see my current speed and heel (angle of the boat to the horizon) on a screen that mounts to the mast of my boat.

To get started, I turned to ChatGPT to determine what components I would need. I thought that I would want an esp32c3 to enable multiple devices to report back to one main device potentially on a coaches boat so they can see the differences in the speed of the boats. I then was debating whether or not I wanted to include a solar panel so that the device could recharge while its on the water but I determined that it would be better to keep the first design simpler and so I want it to just be battery powered...

After further thought, I am going to abandon this idea as I have something that I think will be more useful/applicable. I want to make a breakout board that is purpose built for testing servo motors and stepper motors with room for input devices and output devices.

Project Plan 2

As I said above, I want to design a development board focued on the use of stepper motors and or servo motors. I want to also make it easy to add additional input devices to control the motors such as limit switches. I want to be able to support at least three stepper motors and at least three servo motors. I want it to have a few built in potentiometers or buttons to control the motors. I am now planning on using the Pico W as I will need many more pinouts than are available on the XIAO RP2040.

Execution

I spent a good amount of time reading through the TMC2226 Data Sheet and thought I had a rough understanding for how it should be wired within the PCB. I was unsure as to how to control the microstepping pins or if I needed to use the STEP and DIR pins if I was using the UART connector, I planned to meet with Anthony to seek guidance and advice. In the meantime, I spent some time trying to figure out Wokwi to little avail. I've found that Wokwi's servers can get somewhat busy and your compilations may time out and the simulation won't run. I couln't even get a simple button and led to work.

In preparation for my meeting with Anthony, I tried to draw the schematic for what I believed the connections needed to be. Note that this image was taken slightly later and so there is an additional component that I will talk about later, the focus here is on the TMC2226 and the rats nest of cables.

Meeting with Anthony!

First, a huge thank you to Anthony for taking the time to sit down and help me figure all of this out, I wouldn't have been able to get anything done if it wasn't for him.

The first problem that we tackled was dealing with the TMC2226 component and how to communicate with it. The solution was to simply switch the component. The TMC2226 was far more powerful than what I needed for this situation and would have been overkill, not to mention it has almost 30 pins. Instead, he recommended using the DRV8428, a smaller and simpler stepper driver that would be easier to work with.

Simultaneously, we dealt with the mess of wires that I had in my schematic, making it difficult to read and understand. Soltuion: simply use labels... I know this was mentioned in the EDA video but I forgot about them. They made the schematic SIGNIFICANTLY easier to parse and work with.

After reading and rereading the DRV8428 Data Sheet multiple times, I was able to come up with a rough first layout for the DRV. The sleep and decay pins were left unattached and the DVDD was set up incorrectly and so I revised it later, connecting all pins. The general structure remained the same.

With that, we moved onto the issues that I was facing in Wokwi. I had wired a simple button and led to turn on when the button was pressed while also printing to serial that the button was pressed. It turns out that Wokwi, in their design of the Pico W, made Serial weird and connect directly to pins 1 and 2. These also happened to be the pins that I used for the button and the LED. This meant that while I was trying to send/recieve data from the button to the LED, the simulation was trying to read it through Serial. The solution was to switch to different pins, I used 2 and 3, and to switch to Serial1 which seemed to be designed and implemented properly.

Once we got that working, we moved onto figuring out the servo motor. I was running into problems finding a library for servos that would actually work with Wokwi and Anthony suggested to skip it and simply model the square wave itself which worked! To model 0 degrees, we used a square wave with a pulse high for 1 ms and low for 19 ms and to model "180" degrees, we used a square wave with a pulse high for 2 ms and low for 18 ms. The reason 180 degrees is in quotations is because it never actually rotated that far, for some reason it only rotated about 100 degrees in total. That being said, I was able to get a servo running on the simulator, an example of how my pcb might be used.

Further Progress

Taking what I learned from my converstaion with Anthony, I went ahead and finished the schematic for the rest of the cicuit! I added 3 push buttons, a potentiometer, two LEDs, two pinouts for servo motors, and another stepper drvier. That sounds like a lot, but after having wrestled with the stepper driver alone for probably and hour and a half, the rest of the components felt trivial. I then went on to use the electrical rules checker (ERC) and resolve any errors that it threw at me (there were many). Almost. if not all, of these errors were solved by using power flags to signal whether or not something was a power source as Kicad believed that nothing was actually getting power.

Once the schematic was finished, I had to open up everything into the PCB editor. When I did that, what I initially got looked like this:

It was a complete mess and so the first thing that I did was to take all of the components and spread them out so I could see what exactly was going on. A general note and something I learned while making this PCB is that it is super helpful to have the schematic open simultaneously and reconfigure the GPIOs to make the layout of the PCB much neater.

The first problem that I encountered was that while using the settings recommended in the EDA video, .4 mm clearance and the .4 mm min. track width, I was unable to actually connect to the DRV8428 drivers, they were too small. In order to move forward, I abandoned the constraints and figured I could tackle them later, getting a recommendation from the staff. This enabled me to wire both drivers to the Pico W. Again, having the schematic open and relabeling pins made this SIGNIFICANTLY easier.

After the drivers were complete, I connected everything else. It was an oddly satisfying puzzle trying to get it to all fit together in an appealing and compact way. I had to do some more relabeling in the schematic. I also then ran the design rules check to make sure that I wasn't breaking any of those. There are three errors that I left unresolved. They are in regards to the wiring of the buttons, it wants me to connect pins that don't need to be connected for the button to actually work.

After completing the PCB, I went back to Wokwi to model the entire circuit as seen below:

Here is a link to the project on Wokwi if you would like to test it out.

Thoughts and Reflection

All in all, I am pretty happy with how this week turned out. I was stuck for a long time, trying to figure out what exactly I wanted to build and what might be useful towards my final project. The sailing device, while cool, I think would have been a little complicated and would have strayed from any project I had in mind completely. I am actually super excited about the stepper/servo focused development board, I've spent a good amount of time working with steppers and servos in the past and to have everything already set up without tons of wires all over the place would be huge! I also think it is totally on track with the rest of my project, designing some form of modular robotic system.

Time management was still a big problem this week, even though I thought I started early. Just because I started work for the class on Saturday doesn't mean that I am making progress towards the deliverable right away. I think next week I want to start the deliverable itself earlier, and I can do the research as I go. It is not beneficial to cram the design of a schematic and PCB into a day and a half long stretch.

I was disappointed that I wasn't able to use AVR8JS to simulate my project, I was looking forward to it. I messed around with Falstad a little bit in highschool and was super excited to see how my digital circuits would work with it but it turned out they were a little to digitial for the analog simulator. It didn't have some of the components that I would need to actually model the system, I would like to return to it at somepoint. I was getting pretty frustrated with Wokwi in the end, whether it was because it kept timing out, raising errors, or simply not running, the whole process was unenjoyable.

Actually designing the schematic and the PCB was difficult but also enjoyable. It has been something that I've wanted to learn for a while and so it was great to finally dig in and work through a problem. It was also great as it forced me to read through data sheets carefully to make sure that I was actually wiring everything up correctly. I'm quite proud of how it turned out in the end.

Data Sheets

• TMC2226 Data Sheet
• DRV8428 Data Sheet

Conversations with ChatGPT

• Communication Systems
• Understanding Component Usage