Project Journal for Adhiksit Kalra

=============== Week 15: =================

Entry 7: -----------------------------------------------------------------

Date: April 25th
Start Time: 12:00pm
Duration: 5 hours

Still Writing. Summary: Final integration steps to use code from Rahul (fix some minor bugs), and be able to the use the LCD code. Editted the main editing page to show values like page and pbm and have space for writing drum names.

Entry 6: -----------------------------------------------------------------

Date: April 24th
Start Time: 11:00pm
Duration: 7 hours

Still writing. Summary: Made the different visual pages for loading and interfacing screens.

Entry 5: -----------------------------------------------------------------

Date: April 24th
Start Time: 2:30pm
Duration: 5 hours

Still adding Images

The others had gotten the PCB working, and Rahul got some sample LCD code working just to show that the LCD can be coded. I wanted to show the SPI communication working, but I waited to have another teammate come to be sure that there would be no problem while working with the LCD. When turning on, the LCD does visually turn on. I also downloaded and set up Rahul’s new code in a new project environment so that I know that there would be no interference with any replicated name or previous project configurations. I also added some change to the color to ensure that what I sent from my computer is being sent and recorded. Once Juho came, I ran the code and we could test, in which we could see the background color being changed. We then waited for a GTA to be free in order to run the code to get the PSDR checked off. While we were waiting, I mainly went through some ideas on what the visual display would look like, like some designs on the grid system. I also tried writing out a demo to see how it would look like, but not running it to ensure we still had the same screen ready. This mainly included setting the lines for the grid, allocating space for the text, and setting a random text on top of the grid. I also planned out how to show the cell selection. Rahul had mentioned how to show the selected cell as blinking borders, we would just redraw it over and over. However, I felt that might be more computing intensive than necessary, since we had so many timers running for the motors and keypads. So, I decided a color selection that would be different from the border should be enough. I then tried planning out the coordinates of the cells, and try creating the code for cell selection and intensity selection. For cell selection, I first decided what the general cell column and row positions would be like. Since the LCD screen has a height of 480, as a test I dedicated 80 pixels for the text section, and 400 for the rest. This would give me 3 more horizontal lines, so 4 four rows each drum part. Then for columns, I chose a random testing value just to get multiple columns, in this case being 100 pp for each starting value of the column. This means the first column line (the rightmost line for the first column) is at 100 pixels. I then write the coordinate for the first cell, for both selection and color, in order to get an estimate of how that would look like. For selection, I assumed 1 input, which would be the cell number. I started cell numbers from 0 with the leftmost first row (not the text row) cell, with 16 cells for each row. For that, I also tried setting up a coordinate system for each cell with offset selection for the x and y coordinate. Since I am redrawing lines with different colours, I have to draw vertical and horizontal lines for just that cell, so the cell number will determine the x-offset and y-offset, leading to the cell selection. I assumed 2 inputs, cell number and intensity value. For the time being, I thought of 3 intensity selections: 0 for no hit, 1 for light hit, and 2 for heavy hit. For each of those values

Entry 4: -----------------------------------------------------------------

Date: April 23rd
Start Time: 4:30pm
Duration: 5 hours

Still adding Images

When I entered the lab, I tried to run my code on the pcb. However, there was a weird issue where I could not upload the original code Rahul had. The ST-link was detected, but there was an error for executing an .elf file. At first, I assumed it was the way I had my project folders set up, since I redownloaded the project with the exact same name, put it in the same workspace, and deleted the previous one I was working on. As I was trying to set that up, Alan and Juho tried running their code to see if it would work, and they were getting the exact same issue. After looking through it a bit, it turns out that the pad underneath the microcontroller was burnt / damaged, so they could not program the microcontroller itself. I believe that may have been caused by me, because one of the ST-link flywires had gotten disconnected when I was testing last night, which I had reconnected and tried to run. It was the ST clock connection, which I had only connected to ground, but not sure where else the issue started since I am guessing that is why the LCD started dimming. We all tried setting up back up plans, with me maybe having to solder the next PCB as a way to get started. One thing we did was get extra 802 parts we would need for the PCB, which Juho gave me a list, from the ECE shop. This took longer than it should have just to find the parts. After that, Rahul came and we tried looking through the code just to see what the issue could possibly be. We checked through the programming manual and the library library. Seeing that there was no other possible reason, we tried to check the wiring of the LCD connection. There was confusion on the 0.5 mm 20 pin connection, because there are 2 sides, but we confirmed that since there was 1 mm connection, it has a completely different connection point, so the different pinouts should not interfere. Since there was no other code issue, I left Rahul and the others to get the PCB set up, because I had another homework due.

Entry 3: -----------------------------------------------------------------

Date: April 22nd
Start Time: 11:30pm
Duration: 2 hours

Still adding Images. Will include an artist rendition for the LCD visual.

I had an exam, so I started working quite late. By the time I had just started walking back to the lab at around 11, Rahul showed the LCD lighting up! He also says that he could get a blue screen with his configuration! I immediately went to the lab to see if I could replicate the results on my laptop. He explained he had to make minor changes, which were mainly port configuration changes, which was all there in the code he uploaded. Though he also had it directly set up on the PCB, which he felt was the main solution, since no change was happening with the nucleo board. After that I tried running the code, and when I did, the screen was lighting up to white! Rahul also wanted me to try running the matrix orbital drawing sample code, just so we could see whether we could have other visuals working on the LCD. As I tried experimenting with different values in the LCD configuration, I was only getting white. Moreover, when I was running the code, it was turning white when the GPIOX values were being set, rather then at the end when the PCLK memory was set to 2. I was thinking that since the order of setting values was different from the programming manual, I would try making the code in that order. However, every time I made a change and ran the code, the LCD became dimmer and sort of green lines were being shown instead. At the end, I could barely see the LCD being on. Assuming that it was just a coding issue, I planned to come back the next day and try again, trying to use the original code.

Entry 2: -----------------------------------------------------------------

Date: April 21st
Start Time: 6:30pm
Duration: 2 hours

Had an idea of checking whether I could write information and see if it was written into the LCD. I added the function calls after each write that would read to see if there were any differences. Every value I was sending I could read directly from the memory of the LCD, so at least the values I was being in some sense recognized or at least taken from the SPI channel.
However, now I am not sure where to check, since the SPI communication is working. After this, I ask Rahul to take a look whenever he gets a chance.

Entry 1: -----------------------------------------------------------------

Date: April 21st
Start Time: 9:30am
Duration: 2 hours

Since there was no visual display, even though we could read values, I first tried to check through the write functions to see if there were any glaring problems. Compared with the github library from Matrix Orbital I used as reference earlier. The order of information being sent was correct. The byte by byte information was being sent correctly. However, One thing I noticed was that for each information they sent, they broke the information down into bytes (which I also did), but they immediately sent it byte by byte rather than utilizing the transfer of the whole buffer using the SPI communication that we get from HAL. Updated every write function (apart from host commands since that works). Still no change. Another difference was that for each memory address they were writing to, it was a summation of the base starting address and the offset of the location they were writing to. The library also had a comment on why they were doing it, which could be leading to me not writing to the correct addresses of the LCD. So I tried updating that for the definitions and how I was calling them in the functions. Still no change.

=============== Week 14: =================

Entry 3: -----------------------------------------------------------------

Date: April 18th
Start Time: 8:00pm
Duration: 3 hours

After I asked Rahul yesterday to glance through my code to see if there was anything wrong, he said that he tried some things, but then found that the (https://github.com/MatrixOrbital/EVE-Basic-Demo-STM32) was showing how the MSB configuration for reading and writing to the LCD was not correct, so we did not need to configure those specifically. After that, he wasn’t completely sure, so he asked me to check the wiring again once more, and if still not working, try incorporating the code from the github repository. There were minor improvements for at least readability, but I only focused on making the send host commands the same as the library, as that seems to be influencing where my code was getting stuck. I then checked the SPI configuration, and I finally see the problem. The data bit was configured to 4 bits, so whenever we sent bytes of data, we were only sending half the information. After incorporating that, when running through the code, it was finally not stuck in the REG_ID part, and was now in the main loop. However, the LCD was still not turning on, so there was still an issue in the write bits function for the other commands in the bootprocess, since I configured the clear_LCD color to be all red.

Entry 3: -----------------------------------------------------------------

Date: April 17th
Start Time: 10:00am
Duration: 6 hours

After running the code last time, I saw that the LCD was showing no response, I first assumed the wiring was the issue and rewired it. No change, So I try the debugger to see where the issue is. The code was getting stuck on one of the wait conditions for the init process: reading for the register ID. When looking at the return value for the read, it is returning just a zero, meaning the LCD is not returning anything. I first check whether there was any problem in the SPI communication, but the SPI transmit and receive was returning HAL_OK, so we know that at least there was no problem with just data transmission with the microcontroller. Since I was still seeing no visual results from the LCD, I still believed I had a wiring issue, so I asked help from Juho to see if he could help go through the LCD wiring.

After a bit, Juho arrived and asked me to explain the wiring and what all I used as a reference. Hearing nothing wrong, he checked the wiring himself and saw that there was no problem, at least from my side. He did suggest to do it once more, while having only 1 voltage and 1 ground pin, rather than having multiple as there were in the schematic. After trying that and running the code, there was still no change. Since at least there seemed to be no issue in the wiring, I tried looking through the code again and see if there was any issue there. Here, we go through multiple github repositories, which I try and compare and see what to change. While many of the values of the commands seemed correct, we went through the functions themselves. One thing I saw was that I was not taking into account sending the address data information and sending 3 bytes of information with 1 dummy byte included with them. Another thing was that there was no clear value for the clock select command to see the SPI communication to 72 MHz as the bootup process suggested, so I started to believe that may be causing the issues. Seeing some example code not use that, we commented that line out. However, even after those changes there was no change on the LCD.

Since my code wasn’t working, we tried finding libraries of code to see if we could import that onto our project and see if they would work. One we found promising, (https://github.com/MatrixOrbital/EVE-Library/tree/main), had great code. There was some problem in just downloading and putting the files there, since the project within STMCube IDE would not detect them, no matter how many times I reloaded the project. So I just created the new files there and ran the code. However, when running the code, the functions that were used as a bridgway for the STMCube in the hw_api.h file, were just declared in the library and not defined anywhere.





There, Juho found one demo code for the LCD that I could try and run, just to see if the LCD would turn on (https://github.com/MatrixOrbital/EVE-Basic-Demo-STM32). It did take a while to try and figure out how to import the project, but as I was just about to run, I see that the code was designed for the STM32F401RETx microcontroller, so we would not be able to run it on our board.

When I asked whether there was any debugging LED on the LCD, he checked and saw that there was. However, that was turned off, so that means the LCD was not being powered correctly. After checking that the LCD was at least receiving power through the multimeter, he checked the datasheet for the pinout again. When he examined further, he realized that the LCD hardware connection point was flipped with our connector piece, with pin 1 being on the right most side, while the connector was having pin 1 on the left side. After changing the connection and rewiring the connection again, the LCD debugging LED would turn on, so we could at least confirm that it was powering on. However, we still had not fixed the issue of the loop, so now we’re sure there was still some problem in the code.

Entry 2: -----------------------------------------------------------------

Date: April 16th
Start Time: 9:00pm
Duration: 6 hours

Focused on wiring up the LCD to the microcontroller first, using the connector piece we have. Used the MCU schematic, https://www.st.com/resource/en/user_manual/um2407-stm32h7-nucleo144-boards-mb1364-stmicroelectronics.pdf (pg 36) for the flywire connection on the nucleo board, same port configuration (pa 5 as SCKL, pa 6 as MOSI, pb 5 as MISO, pb 8 as PD, pb 6 as CS, and pb 7 as NSI) as the earlier trial LCD, and the datasheet of the LCD for a final confirmation of the pinout. It took me a while to find the datasheet page for the flywire connection, since I was searching it up as fly wire connections, but from one source, I was able to find that they are actually called zio connection points. From there, I wired up the LCD, double and triple checking each port connection to ensure it was correct.



Worked on bringing the terms and definitions of different commands onto my own files like a library, in order to make the coding more efficient. This mainly meant defining the terminology / command addresses. As I was working on that, I realized I was missing a crucial part of using the LCD, which was a specific bootup process, which at least the programming manual does give an example of. However, some of the functionalities it shows are not completely explained. One was the send host command function, and the values of the host command themselves (such as CLKEXT). The programming manual mentions that the datasheet has the values of the host commands in the Serial Data protocol section. The serial Data protocol section only mentioned the importance of the MSB and sending the address information, but nothing about the command host values themselves.









I found one github repository that showed some example code (https://github.com/Bridgetek/Eve-MCU-Dev/blob/main/source/EVE_HAL.c). This repo also showed some of the values of the host commands but not all of them. In the end, I found one datasheet for an older model that had all the host commands and their hex values (https://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT81x.pdf). From there I worked on implementing all the functionality needed for the boot process, including any basic functions. After writing the whole bootup process and all the command values, I ran the code, with first calling reset, and then the bootup process (which I call init). However, there was no response from the LCD. Moreover, the keypad also wasn’t working, which means it was getting stuck in some loop. I stopped for the night there, but I believe it may be a wiring issue.

Entry 1: -----------------------------------------------------------------

Date: April 16th
Start Time: 12:00pm
Duration: 5 hours

Allan wanted some help on getting the keypad code to work with his code on motors so he could start working on the integration. The problem was that the output light was flickering and not being as responsive to the keypad inputs. Looking through the code on his side, there were no general problems and the code could work. However, what Allan noticed was that the code was utilising old ECE362 format, which directly controlled the ports via the BSRR and registers, rather than controlling the ports through the HAL library code. Moreover, my code used timers slightly differently, since it directly called the timer interrupt handler, while Alan was able to find another version, where HAL would look at all timer interrupts, and then compare and see which timer it was and call on that. What we also saw was that the code I was running on was set in the microcontroller directly, rather than using the nucleo board as the code being processed on, so the system clock values were also completely different.







I then worked on getting the keypad code to work on the nucleo board, which would at least make the environment the same as everyone else’s code. Moreover, I utilised the changes Alan suggested, such as the timer checker, and using the HAL library code to change the GPIO pin outputs for charging the columns of the keypad. Once I had the code to be logically the same as the original, I tried running the code and was not getting the same results as the original code. The output LED was still flickering, and when looking through the debugger, the input was storing multiple values. Since I believed I had configured all the ports correctly through the MX software, I had missed that the init_keypad function controlled the pulldown registers of the input ports, leading to less sensitivity while reading in the original function. With that function in place, Alan could start working with the keypad code to integrate with the motors.



Once the code was working, I tried running my LCD code that I currently have, but was getting some syntax errors for the SPI modules, so I tried fixing that while Rahul worked on his portion. There was some discussion on having problems with programming the microcontroller, but after the professor came by we were able to have a good solution. I ran my code a few more times, but there still some syntax errors that I had to fix. I would come back later in the day to work.

=============== Week 13: =================

Entry 3: -----------------------------------------------------------------

Date: April 10th
Start Time: 10:00pm
Duration: 2 hour

Tried making some of my own random functions to see if I would be able to draw visuals. Mainly tried to have some line functions that would help create a grid, fill in a square with color, and adding text. Also tried to add helper functions that would carry out the SPI communication. Tried to find some repositories just for examples. Found a few: https://github.com/Bridgetek/Eve-MCU-Dev, and https://riverdi.com/blog/how-to-create-great-gui-with-software-libraries-bridgetek-riverdi-eve-solutions?srsltid=AfmBOoq8WYp6Ys_L_ZR_xi2BcA3WMCBTUan2w9xiuMFrSJ6EbmoPMKqa. Just read through those to understand how the general programming would work for the LCD.

Entry 3: -----------------------------------------------------------------

Date: April 9th
Start Time: 3:30pm
Duration: 2 hour

During the lab section, I was mainly reading through the Programming Module of the LCD (). Learned of the multitude of functions it has (Audio and touch which we are not utilising), and also it’s own set of commands These were just understanding how the drawing functions work. With the 20 pin header, it has a lot more input it utilises as well.

Entry 2: -----------------------------------------------------------------

Date: April 9th
Start Time: 10:00am
Duration: 2 hour

Worked on the Keypad code, which incorporates all button inputs. Earlier, the code was mainly only reading the left diagonal (1 - D). No change was needed in set up or hardware, just changing the if conditions to incorporate all the different conditions. Similar to the diagonal, used the and condition to check if the correct bit was active with &, which were GPIOD 8 - 1 (Rows 4 - 1). However, when pressing the button there was no activity shown on the LED. When going through the Debugger, I could see it the current_row value change correctly, but it was not going into the if condition itself. Changing it to use == instead made it work.

Entry 1: -----------------------------------------------------------------

Date: April 5th
Start Time: 6:00pm
Duration: 3 hour

I then worked on the motor and the buck converter IC, which were harder to understand. At least for the motor. The motor equation relied on variables: Weibull Characteristic Life for the Motor Bearing and Weibull Characteristic Life for the Motor Windings. These were mainly based on the junction temperature as the other values, which I based on the datasheet itself. The main reason for my hesitancy to use the equation given by the military handbook was how well it reflects the servo motors we were using. In the end, there were no other available equations that were closest. The operating time I assumed to be around 2000 hours, since it would play bursts of 4 min songs, and overtime that I believe the product should be able to handle.
The buck converter IC, I used the IC equation I used earlier for the microprocessor and the LCD IC, with the packaging failure being a 6 pin type as that is the number of pins in the base IC.
I then worked on the safety and criticality analysis. I made 3 levels of criticality, H for dangerous, M for loss of feature, and L for problems that can be easily fixed and the product can still generally do it’s work. From there, I broke it down to the microcontroller, the LCD and keypad (since they work together), the buck converter, and the motor. The individual analysis, I was not sure about the exact electrical reasonings for each failure, so I relied on my understanding on what could fail, and listed all possible reasonings for the failure.

=============== Week 12: =================

Entry 3: -----------------------------------------------------------------

Date: April 4th
Start Time: 3:30pm
Duration: 2 hour

Worked on the LCD failure analysis. Since there is no direct conversion of LCD in the Military Manual, after some research decided to break it down into components. There were a lot of different things that could be taken into account, so with some checking with GPT, I decided to go with LED, Resistors, Capacitors, connectors (for within the LCD) and a general IC. I could have gone more in depth, but there were many values I was just unsure of. The resistors and capacitors I will just assume an overall value for the whole device, since there is no way to test individual ones. The LED was relatively simple, but the general IC I basically assumed the highest transistor amount, (considering the document is 30 years old). The temperature coefficient I predict to be the same as the microcontroller. The connectors were another part I made a lot of assumptions about. I chose the printed circuit formula, since those would be the ones generally used these days. The assumptions I made for the formula were the temperature being same as before, the mating and unmating factor having taking a middle value since I had no idea what to use, and the active pin value being 20 pins, since that is number of connections needed by the cable to connect to the microcontroller.

Entry 2: -----------------------------------------------------------------

Date: April 2nd
Start Time: 3:30pm
Duration: 2 hour

During the lab section, after the whole lab meeting ours was the first group that had a team meeting with the TA's. They asked to check on our PCB progress, and we see that it had not gotten manufactured due to some issue. Alan and Juho quickly fixed it as I talked with the professor on the overall team progress. We still have a lot to do in terms of interfacing and integrating our parts. I did ask some questions on how to start working on the reliability report, since many of the components had no exact matches within the military handbook. The professor recommended to try my best to see what would be the closest match and work from there. It took me a while, but looking through the example documents, I worked on getting the microcontroller’s table done. There were many factors of the equation I had not understood like the environmental factor, the temperature coefficient, the packaging failure rate, and the learning factor . Or at least what value I should choose. In the end, I chose the environmental factor to be GF, since our product isn’t really lab equipment, but is not something that moves to different places a lot. For the temperature coefficient, I was able to find the junction temperature in the datasheet. Learning factor is just 1, because the microcontroller has been released since 2020. Package failure rate I was still unsure about, since how many “active pins” there are, but since there were a total of 144 pins, I chose a lower value of 128 pins.

Entry 1: -----------------------------------------------------------------

Date: April 1st
Start Time: 2:30pm
Duration: 2 hour

Since I have the project report for the reliability analysis due this week, I started doing some reading about the articles given to us to understand the process. The first article mainly covered the military handbook and how to use it. Still confused on what the equations are and how to use them, at least for getting the equations on the failure rate. The article does give some examples, which at least helps me start thinking about our own project. The main thing the article covered more was the safety and criticality analysis, which might take me a while to get. Read through the second article, and that was supplementing the criticality analysis, since it covered how transistors would break due to down over time or other reasons. Before leaving, I chose our components for the failure analysis, those being the microcontroller, the LCD, the buck converter, and the motors.

=============== Week 11: =================

Entry 1: -----------------------------------------------------------------

Date: March 28th
Start Time: 5:30pm
Duration: 2 hour

Tried adding my own functions into the LCD, and having different functions for creating the LCD UI. Haven’t gotten a chance to test it, but created the set of functions to try and test it. Mainly tried to set a background color, try and set rows and columns (testing 4 horizontal lines and 5 vertical lines). Tried to add code to make cell color changes, but the dimensions of each cell were still difficult to control.

Entry 1: -----------------------------------------------------------------

Date: March 26th
Start Time: 3:30pm
Duration: 2 hour

As I started working on the LCD control, the links Rahul had sent had their own personal library for changing the display visuals. I researched online to see if there were any HAL library for it, but there was none that was included with the CubeIDE. After reading through some of the examples in the link, I tried implementing my own. There were issues with creating a new file and including that into the main file.

=============== Week 9: =================

Entry 2: -----------------------------------------------------------------

Date: March 14th
Start Time: 6:00pm
Duration: 1 hour

Mainly just updated my code to include SPI communication, including updating the .ioc to update the SPI ports, the clock configuration, and functions to start communicating with the LCD. Still have yet to test and try actually communicate with the device itself. I configured SPI1 as the channel for communication, since most examples used it, and Rahul had wired the LCD for that communication as well.

Entry 1: -----------------------------------------------------------------

Date: March 12th
Start Time: 3:30pm
Duration: 2 hour

Worked on understanding the SPI communication and the LCD usage, so looked into how those are programmed. Rahul had given me resources earlier on the basics, so just used those for learning (https://www.digikey.com/en/maker/projects/getting-started-with-stm32-how-to-use-spi/09eab3dfe74c4d0391aaaa99b0a8ee17 & https://www.micropeta.com/video37). Also watched this video in order to communicate with the LCD itself, since the first link was just understanding SPI communication and the second link was for interfacing with the LCD with some example code.

=============== Week 8: =================

Entry 4: -----------------------------------------------------------------

Date: March 3rd
Start Time: 6:00pm
Duration: 1 hour

Met up with the team, and did final preparations for the presentation, such as updating the website: our functionality and documents. Since the initial update to our functionality, we hadn’t updated the keypad usage and the UART packet usage for the motor control to the website. The PSDR also had to be updated to reflect the UART package as well. Added final touches to the rendition and the gnatt chart (just to make it more clear for visibility).

Entry 3: -----------------------------------------------------------------

Date: March 3rd
Start Time: 1:00pm
Duration: 1 hour

Worked on my slides, mainly creating the Gnatt chart and the artist rendition. The artist rendition was relatively simple, since it was just designing a table with our computer box on top for user interface, and then the drum pieces. For the gnatt chart, since I can generally interface with the keypad, I wanted to focus on helping Rahul creating the UI on the LCD. Then before spring break, the team will finish the PCB design before spring break, and majority of Motor control. Afterwards, keep the MIDI file processing somewhat near the end, and make sure the general integration of the whole system works, which includes the motor control with the beat editor table, the general hardware setup with the stands, and making sure everything works in sync.

Entry 2: -----------------------------------------------------------------

Date: March 2nd
Start Time: 10:00pm
Duration: 2 hour

Tried to get the keypad working. After reading through the error, I believed that even though I was able to power the microcontroller with the connection, I wasn’t actually uploading my code to the microcontroller. The experiments included removing some of the LED calls, and trying to upload while disconnected. That’s how I saw the same error message as what I was facing. So I updated the software (since that was requiring an update) and created a new project. With this new version, I stopped getting the error. Also talked with Rahul and saw that I had to change the IOC file to control the GPIO ports directly (to be input or output), since the enable functions I was using did not actually activate them properly. After adding the .ioc file changes, I was able to see values entered into the current_row variable in the debugger.

Entry 1: -----------------------------------------------------------------

Date: March 1st
Start Time: 6:00pm
Duration: 1 hour

Mainly worked on setting up the presentation. Met up with the group to determine who is doing what slides, and what all of our remaining tasks were in order to finish our progress before the presentation. Mine was to fix the keypad to be able to recognize the keyboard inputs via the GPIO ports. The portion I took was explaining the project overview, the PSDR, my software progress, and the project timeline for the group. From there, my main task was to create an artist overview of our project, and the gnatt chart for the timeline.

=============== Week 7: =================

Entry 4: -----------------------------------------------------------------

Date: February 28th
Start Time: 8:30pm
Duration: 4 hours

Worked on rewiring the microcontroller with the keypad using the new configuration of PG 2 - 9, and now using male to male fly-wires since those will be less loose in connection compared to using normal wires. Even though the schematic has PG2-8 being on the same row, the microcontroller itself has more spaced out connection points.

After getting the wiring done and connecting to the laptop, there were problems with the timer I was using to run the code. Initially, I was using the Systick timer of the Microcontroller to read the keypad input, but since the HAL library given with the STMCube IDE has its own Systick Handler function, my call was being the second definition which could not override the HAL library’s call. Tried to override the call from the library by removing the function call HAL_INIT, but that was not enough. Research was showing how I would need to redefine the init_Systick and Systick_Handler within the imported libraries, which I believed would cause more harm than good.

Instead, I changed the interrupt to Timer 7, since that is what another previous lab had used.

The project was able to build, but not be uploaded onto the microcontroller, due to some debug configuration going wrong. This leads me needing to maybe recreate the project and import my code again to fix the issue.

Entry 3: -----------------------------------------------------------------

Date: February 26th
Start Time: 3:30pm
Duration: 2 hours

During the meeting, I asked Juho if there was a better hardware setup he had designed for the schematic, and there was. He saw that the GPIO ports G 2-8 and one other port for the last keypad connection were better, since according to the schematic those pins were right next to each other.

Rahul had to use the microcontroller to try setting up the LCD, so I focused on updating the code to use the new pins. Since that was done relatively quickly, I finished watching the video on programming the microcontroller: https://www.youtube.com/watch?v=dnfuNT1dPiM. Mainly learned about the STM32 interrupt example they discussed. Learned how they debug and controll the interrupt from the IOC viewpoint

Entry 2: -----------------------------------------------------------------

Date: February 26th
Start Time: 9:30am
Duration: 3 hours

Worked on wiring the keypad to the Microcontroller STM32H7, using PC 0-7 as that is what my old code from ECE362 was using, and had no reason to change. The microcontroller GPIO pins are pins that have no soldered connection, and are just metal holes, so I am not 100% sure if they were safe to use or if they gave any signal or not. Tested it with the ground and 3.3V pins just to check if I got an output, and was able to get a reading.



As I am wiring, I see that it is more difficult to wire since PC0 - 7 are not in a straight line as they were in the STM32F091. Still kept trying, with normal wires, since I want to at least get the prototyping done. With normal wires, the holes in the microcontroller are too big, so the wire connections are too loose and keep falling out when trying to find the correct ports by checking the bottom side. Tried bending the wire to ensure they stayed, but realized that would cause problems of touching wires, and even if I did find the optimal position, nobody else would be able to use the microcontroller since it’s such a fragile setup.



Tried using flywires instead, but still too difficult to actually connect with the keypad, since the female header side would not connect with the keypad wiring well. Double sided male fly wires would be needed.

Entry 1: -----------------------------------------------------------------

Date: February 22th
Start Time: 2:00pm
Duration: 4 hours

There were some final changes I had to make to the document. Reworked the keypad map out to fit our current updates, such as having only four buttons dedicated to selecting a drum part, and mapping the other buttons to different purposes, such as a different button for resetting the beat table and pausing during play. I also had to change the flow diagrams made during the software overview to update the different modes. Mainly changed it to have load state (from uploading the Midi file) to go straight to the calculation state, which will go to the playing stage. The reason being that we are only going to have a max of 4 drum parts with the stretch goal, and the remapping of other buttons just ensure more usability as they will be somewhat more intuitive to understand. Then, I also had to update the document to change the communication method to the motors, since earlier I had it as PWM signals, but changed it to UART packets to match with the HT-45H Serial motor setup. Added more information to describe the integration between the different sections, such as controlling the LCD for user usability.

=============== Week 6: =================

Entry 4: -----------------------------------------------------------------

Date: February 21th
Start Time: 7:30pm
Duration: 4 hours

Worked on finishing the document, added details on the software development of the user interface LCD, the motor control, and the USB to UART. Mainly just expanded that information from the software overview and what was already there on the website. Then I added information about the testing plan, where the main focus was unit testing. This involved a step by step process for making sure each state of each component was being developed properly. For example, the key pad would be tested by checking whether I can get any output from where I would charge my columns for the keypad. From there, I will connect the keypad and see if from pressing the diagonal I can get outputs. Then, I will map all button presses to an LED to ensure all button presses are recorded and can submit an output.

Similarly for LCD testing, it would setting up different parts of the display step by step for checking. For example, starting off with being able to program a cell and get boundary for it. From there, being able to have a “flashing” cell for showing selection. Then would be able to shade the cell into a specific color (such as red or green). Then create some grid table format to start having something for the beat editor.

It's after test cases like these where we can see individual cases working where we can then start integrating and testing to see if the different segments can work together. After the individual components work, we then test whether the keypad affects the LCD in the UI. While that integration is being tested, we would also check whether the editor table is affected by the keypad input, which is then affects how the motor operates.

Entry 3: -----------------------------------------------------------------

Date: February 21th
Start Time: 3:30pm
Duration: 2 hours

Worked on the software formalization document more. Confirmed with the GTA that the 3rd party software is mainly focused on what software is used to make the code work and run, rather than other software such as KiCad that is used for the development process. After that, worked on key pad matrix communication section for the document, mainly just adding some more information to those already available on the website. Updated some stuff, such as only using 1-4 for instrument control, but rest is kept as original.

Entry 2: -----------------------------------------------------------------

Date: February 20th
Start Time: 2:30pm
Duration: 1 hours

Worked on importing some of my old code from ECE 362 into the new STMCube IDE, which mainly involved enabling the ports, setting up the interrupt and creating the charging the columns and reading row inputs. I still want to follow the same configuration as the old code, since there is no need to change the logic. So for enabling the ports, I configure the RCC for GPIOC to be active and set ports 4-7 as outputs for charging the columns and 0-3 as inputs for reading row input. This will allow for setting up the matrix communication. Then I set up the Systick interrupt to occur 1/16th of a second, where each call of interrupt will charge a column and get the row values for reading.

Entry 1: -----------------------------------------------------------------

Date: February 19th
Start Time: 3:30pm
Duration: 2 hours

Since I have the Software formalization document due this week, I went through the examples and the software overview in order to get a better idea on what to focus on for writing. Started off with getting some licensing information for the STMCube from https://www.st.com/resource/en/user_manual/um2609-stm32cubeide-user-guide-stmicroelectronics.pdf.

After that, I got the Base IDE code to start working. However, as I was starting to program I wanted to try connecting the microcontroller to the computer. Connection via STlink to the computer wasn’t clear, as the pinouts were not the same as the one for STM32F. Checked this video out to help get started: https://www.youtube.com/watch?v=dnfuNT1dPiM. The video just showed that the connection was made via a USB connection, rather than the pinout connection. Rahul then checks with me and shows that it was just a USB connection at the edge of the board. Mainly just me over complicating the problem.



We had a quick discussion with the professor and the GTA about changing the PSDR from adding 2 more drums to something more ece involving, such as the design for buck converters for the power regulators. They also told where to find the wire connectors for USB-Mini to USB-A for the microcontroller to the computer connection.

=============== Week 5: =================

Entry 4: -----------------------------------------------------------------

Date: February 14th
Start Time: 9:30pm
Duration: 2 hours

Mainly tried actually setting up and trying to start coding. Followed this video to set up the environment properly: https://www.youtube.com/watch?v=WKDxzqnLJVE. I just selected the board as shown in the image. As I watching the video, the IDE does help a lot with the info for the ports in terms of just accessing specific ones we want. However, I was facing an issue where I was not able to start working with code, as I was not able to generate base code for the microcontroller due to the IDE asking me to log in. There was no simple log in page, and instead I had to follow this set of steps from the STM forums: https://community.st.com/t5/stm32-mcus/how-to-set-the-network-connection-parameters-for-stm32cubeide/ta-p/585694. I then really played around with the software for a bit, just trying to understand how to use it, and glanced through the user mannual as well: https://www.st.com/resource/en/user_manual/dm00629856.pdf.

Entry 3: -----------------------------------------------------------------

Date: February 14th
Start Time: 2:30pm
Duration: 1 hours

Earlier we had a quick meeting with the prof, where we just talked him about the final confusions we had about the power management with the motors and just working with the current control for the breadboard. I then mainly tried to set up the STCUBE IDE Rahul had told me about, mainly just installed it from https://www.st.com/en/development-tools/stm32cubeide.html. I then glanced through the quick setup file that was given along with the installation: https://www.st.com/resource/en/user_manual/dm00598966.pdf. It did take some time to download, but I was able to at least somewhat set up the environment. Tried to get the coding environment set up, but couldn’t get it done.

Entry 2: -----------------------------------------------------------------

Date: February 13th
Start Time: 10:00pm
Duration: 0.5 hours

We had quick call on the discussion of the servo motors. Alan and Juho had been talking with the TA’s after the wednesday lab, and were told that the servo motor we looking to use for the project has too much current draw for what the PCB can handle, and that we would need to use different ones. Moreover, if we were to not use Feedback survo’s then after even a minute of playing, the sticks would have a lot of drift. Meaning, that if we kept using just voltage as a control, then we would eventually lose our start / neutral position of the stick. They had found a few options, but I was getting worried that we were too far behind on prototyping, so I pushed them a bit to start getting confirmations on what we would need with the TA office hours, and that we should have a team meeting with the Professor on Friday.

Entry 1: -----------------------------------------------------------------

Date: February 12th
Start Time: 3:30pm
Duration: 2 hours

During the lab section, we first had our lab meeting, where we discussed about locking down the psdrs and just more details on what to focus on in terms of detail. The prof also described what we should include in our Bill of materials, including stuff that we would get free from the lab, such as wood items. I believe we need to put the metal for our stands along with the servo motors, LCD, microcontroller and the other smaller parts in the PCB design. That day, we also got our new microcontroller, so I had to dismantle my breadboard (just removing the microcontroller since it was the biggest we had). However, the microcontroller would not fit, due to the spacing of the breadboard, and extra ground pins on the corners of the microcontroller. When we realized this, we decided that it would be better to use fly wires for connections to it, even for connecting it to the computer via the St-Link. For the time being, I mainly focused on fixing my code, since after last time I could upload my code (just had to wait for it to cool down, should not take more than an hour generally). The main problems I was facing was that when I changed the toggle output to anything apart from PB8-PB11, even if the led was connected properly, it would not turn on. From this, I realized that this was mainly due to me using ECE362 code, which probably had it’s own limitations set for the coursework. Which is why Rahul told me of a new IDE the STCube, which was designed to work with the recent ST microchips. (https://www.st.com/en/ecosystems/stm32cube.html). Didn’t get a chance to install it today, but will try it later.

=============== Week 4: =================

Entry 3: -----------------------------------------------------------------

Date: February 7th
Start Time: 8:30pm
Duration: 2 hours

Mainly worked on trying to get the keypad outputs mapped to the LED’s discussed in the lab section. First worked on the breadboard have LED outputs for PB0 - PB15 for the 16 keys of the keypad. I just used any resistor I had on hand, just to be able to pass some current through the Resister to the LED that is grounded on the other side for a full circuit. However, when trying to upload and monitor for testing, I started getting upload errors, where it could not even detect the device even though I tested it last week. I tried testing with original ECE362 code, but that didn’t work. I noticed that the diodes I connected to the RC circuit for debouncing the keypad were getting warm, so I immediately disconnected that. I noticed that the connection for the USB to the STM32F was also getting warm, so I know something went wrong, which I believe is caused by the Diode connection as well. However, no matter what I could not establish a connection again, so will need to ask for help in debugging. I tried restarting my computer in order to see if that would fix it, and then I see a pop up showing how the device is not recognized. Could be something wrong with my USB device connection, since it uses a device with multiple USB connections, which is then connected to my latptop via a usb-c connection.

Entry 2: -----------------------------------------------------------------

Date: February 5th
Start Time: 3:30pm
Duration: 2 hours

Mainly just tried researching how LCD programming worked, on at least how to start coding the GUI. Read through the sample code from https://web.alfredstate.edu/faculty/weimandn/programming/lcd/atmega328/LCD_code_gcc_8d.html and https://web.alfredstate.edu/faculty/weimandn/programming/lcd/ATmega328/LCD_code_gcc_4d.html. Watched this video where they show an example of C coding for the LCD display: https://www.youtube.com/watch?v=S0m6zKjXn-Q. I tried to work with the code in VS code, but not really got much done in of itself, since there is no testing device yet. I tried watching this video to get a better idea: https://www.youtube.com/watch?v=1rpULi3Y_bs. Then I watched this video: https://www.youtube.com/watch?v=zYtGhmV2-XQ, which at least gave a lot more detailed information on how to approach coding it in our environment. Though, still limited understanding since I haven’t really practiced coding on it yet, should really ask for one LCD to start testing with. Another resource I found was a library for starting to code LCD: https://github.com/alixahedi/i2c-lcd-stm32.

Entry 1: -----------------------------------------------------------------

Date: February 5th
Start Time: 3:30pm
Duration: 2 hours

First we had our 15 min lab meeting we discussed our weekly goals, including the electrical form and the main components form. Then we discussed the microcontroller, motor, and LCD we needed. We talked about the different specifications we would need, such as Alan and Rahul saying we would need a torque of about 600 N inorder to have the best control over the drumstick. Then, we had our meeting with the professor and the GTA’s about our progress. The PSDR was going in a good direction, but we still had to clarify our base goal and stretch. Earlier, we said we would do only one drum piece as a base, and add more later. But, the professor recommended that the LCD display may not be as descriptive or useful in that case. He also gave us an idea on using 2 drumsticks for each drumset, if we were only doing one for base. Another thing Shivam reminded was that we hadn’t really discussed about power on the website, which was true since we hadn’t considered it yet. After that, we discussed those details with our team. For one drum with 2 drumsticks, while it would be great on its own, including more drumsets would make it more complex, as adding each drumset would require having 2 more PWM signal outputs from the microcontroller for control. This would then require maybe more than 1 microcontroller if we wanted to include more than 2 drum pieces, which I felt would not have made the project as interesting. For power, we haven’t tested yet since aren’t completely sure of the component list, but we decided to have one power supply that distributes to the other sections, with multiple regulators going down the voltages. Assuming wall voltage, we then go down to 12 V for the motors, 5V for LCD and maybe other components, and then once more for the microcontroller. Another thing we discussed was how we are powering the microcontroller as well, since we had 2 conflicting ideas. One was to keep the microcontroller constantly connected to the laptop to be able to easily give the microcontroller the Midi files, or to flash the microcontroller and then give the midi file via usb when needed. The main discussion point was having a clean design, and the charging method as well. For one, I was unsure of whether we could power the microcontroller with an outside power source, but Juho quickly searched up that you could. Then, the question of transmission of data came to be for the midi file, where if you were to power the microcontroller separately, would we still have the usb connection we normally do? We decided on using a USB module for the PCB, where it would not need to necessarily be connected to a computer always, allowing for a more clean closed box design. The others in the team did have a list of components that may fit our needs, but we hadn’t chosen one for prototyping, so they messaged a list to Shivam and Liangchen in the teams channel. For one, I had ordered a microcontroller that Juho recommended, the stmh723, but we hadn’t really researched how to use it. It is by the same company as the STM32F (the one from ECE362). Then Rahul and Alan started ordering the list of the motors and LCD from the 477 lab, just to see which ones could meet our specification and so we could start prototyping. I looked into the user reference manual for the microcontrooler, just to get a general idea of whether there were similar in terms of accessing the registers (chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://www.st.com/resource/en/reference_manual/rm0468-stm32h723733-stm32h725735-and-stm32h730-value-line-advanced-armbased-32bit-mcus-stmicroelectronics.pdf). At least some of the register access seems the same as the STM32F. I couldn’t really find some examples of code like they have in the STM32F reference manual, so will have to find later to ensure the code is similar. This website has all the resources related to the STMH723: https://www.st.com/en/microcontrollers-microprocessors/stm32h723-733/documentation.html#.

=============== Week 3: =================

Entry 3: -----------------------------------------------------------------

Date: January 31st
Start Time: 4:30pm
Duration: 4 hours

I focused on trying to research on how to control the debouncing via hardware (https://www.digikey.com/en/articles/how-to-implement-hardware-debounce-for-switches-and-relays), and trying to do the calculation for the capacitor value I would need for 1k Ohm resistors. Using the formula t = R * C, where t would be the time I need to debounce and R and C being resister values and capacitor values I of the RC filter, I calculated around 1uF. Then changed the hardware to include the design, and focused on trying to add more functionality to the code that I described at the end in the last entry. Mainly for testing, just added a few LED for each output in order to test that each button does output correctly. Had to change the init_b code in order to take into account more ports, and just general hardware debugging where I made silly mistakes in connections. Tried researching beat editor code, just to see how we can control all the functionalities. Did find this as a testing base of just controlling beats: https://codesandbox.io/p/sandbox/beat-maker-zj91g?file=%2Fsrc%2Findex.js%3A13%2C27. Then found some example code for controlling LCD designs: https://web.alfredstate.edu/faculty/weimandn/programming/lcd/atmega328/LCD_code_gcc_8d.html.

Entry 2: -----------------------------------------------------------------

Date: January 29th
Start Time: 3:30pm
Duration: 2 hours

In the lab section, we had the quick 15 min discussion, but then we focussed on testing the prototype Alan had made last night. The prototype was mainly a servo motor connected to an Arduino with a drumstick that Rahul had brought attached via tape. I tested the prototype with Alan by just trying different values of delay between neutral and angle to hit, with some different positions of attaching the tape to the servo motor. We started with around 1 second (not 100% sure) delay between each step, but noticed that it was causing some deading to the sound as the drumstick stayed on the drum for too long. We then incrementally decreased the delays, but there was still some deading, so we decided that it was better to choose a stronger motor that had a faster angle change. Moreover, we also saw that the drumstick was slightly wiggling between each movement and hit, and saw the need of a motor and drumstick attachment powerful enough to keep the drumstick in place. Then, I mainly worked on editing the 362 Lab code in order to meet our specifications, where each button can handle different functions. The way the current functions is that once it gets an input from one of the row inputs, it would create an interrupt to handle any other function. In the original lab code, it would handle toggling an led on one of the 4 pins dedicated as output. For now, I am not really creating an output function, mainly focusing on handling the different button inputs for reading.

Entry 1: -----------------------------------------------------------------

Date: January 29th
Start Time: 10:30am
Duration: 2 hour

I focused on starting the setup for using the matrix interface for the between the user and the microcontroller. First I just set up the resistor connections following the ECE 362 lab 1 details (as shown by the schematic). From there, I set up platform.io into my computer to allow for home testing (since I never really did it during the 362 section). This included installing a driver to convert the STLink driver to WinUSB from https://zadig.akeo.ie. Then, it was mainly just debugging different types of errors and following the forum at https://community.platformio.org/t/esp32-pio-unified-debugger/4541/20 to make sure it worked. Then, I tried running my old code from lab 2 for 362 where they started using interrupts for handling the matrix inputs. The setting up did take me a while to get to, but at least for testing matrix communication with my laptop it should be very easy in the future. I was mainly coding in VS code, and had downloaded my github repository from earlier in order to access my old code. From there, I need to modify my code in order to take into account all the button inputs, since the 362 lab code only handled the diagonal 1, 5, 9, D. I mainly want to start initialising the functions that each button press would do.

=============== Week 2: =================

Entry 1: -----------------------------------------------------------------

Date: January 20th
Start Time: 11:37am
Duration: 1.25 hours

We had our lab team meeting in the beginning, just outlining the goals of the week. Then, we just focused on trying to work on the next report, which was outline the functional specifications. Before that, we had a discussion with the professor and the GTA, who gave feedback to the PSDRs, and where we could add more details. They also gave us some ideas to look into for the design, such as the motors with busses for specific angular control, using metal stands, and clarifying the use of LCD display. I really just helped in the other sections bit by bit, leading the discussion of the motors, where we took some from the cabinet as a reference to understand what voltage / power motors we would need. Then, we just discussed the design of the overall stand, such as using metal stands, how the motor would hold the stick and Alan and Juho helped draw out some designs. We then decided Alan would try to bring a drum of his to the lab and we could try a basic design of attaching the drum stick to the motor to test the voltage control. I then helped finish the other constraint section of the document.

=============== Week 1: =================

Entry 3: -----------------------------------------------------------------

Date: January 17th
Start Time: 2:30pm
Duration: 30 min

Just focused on finishing up the report details, with the main focus on the PSDRs. Juho and Rahul had already done some work, so it was mainly just refining. I helped in mainly wording out the stretch PSDR and the software, since I felt the earlier version we had felt a bit vague.

Entry 2: -----------------------------------------------------------------

Date: January 15th
Start Time: 3:30pm
Duration: 2 hours

This was our first lab section, so me and my team mainly did the lab section tour, where we learned about all the roles and equipment available to us in the Lab. That did take the majority of the time, but I did learn about all types of equipment available such as the hot table, the cupboard with all the robot parts, the soldering stations (shared and team ones), and the work area at the back (forgot the name). Then we met up with the GTA’s to talk about our project and discussed some details, where they recommended focusing on just 1 stand and making sure that worked. Finally, I just had a quick meeting in the team to discuss the assignments for the week and make sure the website was running before we left.

Entry 1: -----------------------------------------------------------------

Date: January 13th
Start Time: 3:00pm
Duration: 1 hour

Discussed the budget with the team. Mainly talked about what general kind of parts we would need and where we would source them. Some of them such as the stands, the drumsticks, and the microcontrollers (Which we decided to use our STM32). We also sort of thought about how we would place the motors, whether we would use 3D printed designs to hold the motors or not. In the end, we decided on the budget below, seeing that the actuators, drumsticks, and the PCB will be the main purchases. We also included cardboard as a possible material for holding the PCB and the microcontrollers as the main box.