View source for F24: Jardinains

=== Grading Criteria ===
<font color="green">
*  How well is Software & Hardware Design described?
*  How well can this report be used to reproduce this project?
*  Code Quality
*  Overall Report Quality:
**  Software Block Diagrams
**  Hardware Block Diagrams
**:  Schematic Quality
**  Quality of technical challenges and solutions adopted.
</font>

== Project Title ==
Jardinaiins

== Abstract ==
Prepare for endless bouncing, breaking, and gnome-busting excitement! Jardinaiins reinvents classic brick-breaking gameplay with a delightful twist. Dive into vibrant, garden-themed levels filled with challenging obstacles, quirky gnome antics, and thrilling power-ups. Smash through barriers, outsmart mischievous gnomes, and uncover surprises as you progress in this fun and addictive adventure!


== Objectives & Introduction ==
•  Interface the SJ2 board with the Waveshare 64x64 RGB LED Matrix Panel to display dynamic text, colorful images, and animations. The onboard GPIOs of the SJ2 microcontroller will drive the LED panel, and its chainable design will be utilized to facilitate scalability for larger displays.
•  Use the MMA845XQ accelerometer onboard the SJ2 board as the player controller, mapping tilt and motion inputs to control animations, select media, or interact with displayed content on the LED matrix.
•  Integrate the HiLetgo GD3300 UART Control Serial MP3 Music Player Module to enable digital audio output by leveraging the SJ2 board’s UART protocol. The system will send serial commands for operations like play, pause, track selection, and volume control.
•  Utilize the General Purpose Direct Memory Access (GPDMA) controller on the SJ2 board for memory-to-memory transfers, reducing delays during video buffer updates for the LED matrix.
•  Leverage the DMA controller's memory-to-peripheral function to minimize frequent I2S interrupts while loading digital audio content to the MP3 module, optimizing system performance.
•  Implement an SD card peripheral driver on the SJ2 board to facilitate reading and writing of multimedia data, enabling seamless storage and retrieval of audio and visual content for playback and display.


=== Team Members & Responsibilities ===
*  Dev Hitesh Malkan
**   
*  Nidhi Sharma
**   
*  Sunny Shah
**   
*  Navya
**


Sure! Here is the updated table with your provided data in the requested format:

== Schedule ==

{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-
! scope="row"| 1
| 
* 10/14/2024
* 10/14/2024
|
* 10/20/2024
* 10/20/2024
|
* Review past projects, gather insights, and discuss with team members  
* Initial ordering of parts (SJ2 board, 64x64 LED Matrix, GD3300 MP3 module).
| 
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 2
| 
* 10/21/2024
* 10/21/2024
| 
* 10/27/2024
* 10/27/2024
|
* Submit project proposals.  
* Identify and select sensors and peripherals.
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 3
|
* 10/28/2024
* 10/28/2024
|
* 11/03/2024
* 11/03/2024
|
* Learn about LED matrices and display "Jardinains."  
* Study accelerometer principles and operation.
|
* <span style="color:green">Completed</span>
* <span style="color:green">Completed</span>
|-
! scope="row"| 4
|
* 11/04/2024
* 11/04/2024  
* 11/04/2024  
* 11/04/2024
|
* 11/10/2024
* 11/10/2024  
* 11/10/2024  
* 11/10/2024
|
* Create gitlab repo for the project.  
* Develop basic game graphics and user interfaces on LED matrix.  
* Develop code to control LED matrix based on accelerometer input.  
* Familiarize with GD3300 MP3 decoder module.
|
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>
|-
! scope="row"| 5
|
* 11/11/2024
* 11/11/2024  
* 11/11/2024
|
* 11/17/2024
* 11/17/2024  
* 11/17/2024
|
* Design and implement game rules and systems.  
* Integrate game logic with LED matrix display.  
* Integrate sound effects with game logic.
|
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>
|-
! scope="row"| 6
|
* 11/18/2024  
* 11/18/2024  
* 11/18/2024
|
* 11/24/2024  
* 11/24/2024  
* 11/24/2024
|
* Test hardware integration and debug accelerometer-controlled input.  
* Optimize DMA usage for efficient LED matrix updates.  
* Validate UART-based communication with GD3300 MP3 module.
|
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>
|-
! scope="row"| 7
|
* 11/25/2024  
* 11/25/2024  
* 11/25/2024
|
* 12/01/2024  
* 12/01/2024  
* 12/01/2024
|
* Implement advanced game mechanics (e.g., power-ups, increasing difficulty).  
* Optimize and fine-tune user experience and interactions.  
* Test and validate system performance under real-time conditions.
|
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>
|-
! scope="row"| 8
|
* 12/02/2024  
* 12/02/2024  
* 12/02/2024
|
* 12/08/2024  
* 12/08/2024  
* 12/08/2024
|
* Finalize sprite designs and integrate animations with LED matrix.  
* Conduct system-wide integration testing.  
* Address edge cases in game logic and audio synchronization.
|
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>
|-
! scope="row"| 9
|
* 12/09/2024  
* 12/09/2024  
* 12/09/2024
|
* 12/17/2024  
* 12/17/2024  
* 12/17/2024
|
* Perform final testing of the complete system, ensuring stability and performance.  
* Prepare and conduct final demonstrations.  
* Submit final project code to GitLab and update project documentation and wiki.
|
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>  
* <span style="color:green">Completed</span>
|-
|}

<HR>
<BR/>

== Parts List & Cost ==
Give a simple list of the cost of your project broken down by components.  Do not write long stories here.

== Design & Implementation ==
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.

=== Hardware Design ===
Discuss your hardware design here.  Show detailed schematics, and the interface here.

=== Hardware Interface ===
In this section, you can describe how your hardware communicates, such as which BUSes used.  You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.

=== Software Design ===
Controller
The accelerometer on the SJ2 board manages paddle movement by sampling the y-axis magnitude 17 times over a 17-millisecond period and calculating the average. This value is capped at a maximum of 700 within a range of 1000. To make it simpler, the tilt value is divided by 31, producing 32 possible readings, which correspond to 5 bits of data. Each time there is a change in magnitude or a button press, the controller transmits a single byte of data to the console. This byte encapsulates all the necessary information for controlling the on-screen paddle. The first two bits indicate button input, with 0 representing no input and 1 indicating input detection. The third bit specifies the tilt direction, where 0 means left and 1 means right. The remaining five bits represent the accelerometer's magnitude.


Audio
Sound effects are added using MP3 Serial Decoder HiLetgo GD3300, source code was written on our own. 


=== Implementation ===
Paddle Movement
The paddle movement is driven by accelerometer data wirelessly transmitted from the SJ-Two board to the LPC4088 board. This data is mapped to 63 possible positions for the paddle. Initially, the paddle would instantly move to the position corresponding to the accelerometer input. However, this approach was refined by introducing an algorithm that allows for a smoother transition between positions. The algorithm calculates paddle velocity based on the "current desired position" and the previous position. Parameters of the algorithm were fine-tuned iteratively to achieve a smooth and responsive paddle movement.
Paddle-Ball Collision Logic
The ball's position is updated each frame by adding delta_x and delta_y to its current x and y coordinates. If the ball's next y-position crosses the paddle's y-position, a paddle collision check is performed. To do this, the ball's movement is modeled as a slope derived from delta_x and delta_y. Using this slope, along with the ball's current position and one pixel above the paddle's y-position, a point-slope equation (y2−y1)=m(x2−x1)(y_2 - y_1) = m(x_2 - x_1)(y2−y1)=m(x2−x1) is used to calculate the x-position of the ball at the time it reaches that y-coordinate.
Once the expected collision point is determined, the ball's collision magnitude and its next position's magnitude are calculated. By comparing these magnitudes, a time fraction for the frame is derived to estimate when the ball might have collided with the paddle. Using the paddle's current position and velocity, the paddle's previous position is estimated to determine how far it moved during this time fraction. By multiplying the time fraction by the paddle's x-position change, it is possible to check whether the paddle was underneath the ball at the moment it reached the pixel above the paddle's y-position.

== Testing & Technical Challenges ==
Ball-Collision Logic
The initial ball collision logic relied on pixel values to detect when the ball entered a brick. However, this approach failed to handle cases where the ball entered a brick diagonally, requiring the logic to be completely reworked. In the updated version, the focus shifted to determining whether the ball was crossing into an area containing a brick. This was achieved by dividing the playing field into a grid representing the positions of the bricks.
The new logic involved an initial check to see if the ball was crossing a boundary near a brick. If the ball crossed only the x-boundary, a collision check was performed to determine if it hit a brick. Similarly, if it crossed only the y-boundary, another collision check was conducted. In cases where the ball crossed both x- and y-boundaries, additional logic was applied to determine which boundary the ball crossed first. This updated method effectively handled diagonal collisions and improved the overall accuracy of the collision detection.
This experience highlighted the value of abandoning ineffective solutions and adopting new approaches, as they can lead to better outcomes.
Paddle Movement
We encountered an issue where the paddle would slow down as it neared the walls. This happened because the difference between the "current desired paddle position" and the previous paddle position decreased near the walls, resulting in a reduced paddle velocity. To address this, we adjusted the logic so that whenever the accelerometer data mapped to the minimum or maximum paddle index, the "current desired paddle position" was extended. This adjustment ensured that the paddle velocity remained consistent, preventing the paddle from slowing down as it approached the walls.
Paddle – Collision Logic
During final integration and testing, one major issue we faced was a bug where the ball failed to detect collisions with the paddle, causing it to pass through instead of bouncing off. To troubleshoot this, we implemented a clever debugging method: changing the ball's colour during each collision check. This allowed us to visually confirm whether the collision logic was being executed. Through this approach, we discovered that the section of code responsible for checking paddle collisions was being skipped, even when the ball's next y-position had crossed the paddle's y-position. This debugging method proved invaluable in identifying and resolving the root cause of the issue.

=== <Bug/issue name> ===
Discuss the issue and resolution.

== Conclusion ==
We thoroughly enjoyed the process of creating this project and gained a wealth of knowledge along the way. Our driver development skills were sharpened as we wrote drivers for various modules, including the LED matrix and MP3 decoder. Additionally, our understanding of the FreeRTOS API deepened, and we acquired fundamental game and graphics development skills through our work with the LED matrix.
Throughout the project, we faced numerous challenges, such as getting the LED matrix driver to function properly, implementing collision detection with multiple game objects, and designing and maintaining a complex game logic state machine, among many others. Each obstacle provided valuable learning experiences and contributed to our growth as developers. By applying design principles and communication protocols learned in lectures, we successfully brought this project to life. Key concepts we utilized include UART, SPI, I2C, I2S, DMA, FreeRTOS mutexes, binary semaphores, queues, task creation, stack sizing, task scheduling, interrupt service routines, and bootloaders.
Through countless hours of testing and verification, we learned the critical importance of allocating sufficient time for integration and debugging, as it greatly increases the likelihood of a successful outcome. Without this phase, the project might have faced significant issues upon delivery. We hope this project serves as a helpful resource for future engineers and wish you all great success and enjoyable development experiences ahead!


=== Project Video ===
Upload a video of your project and post the link here.

=== Project Source Code ===
*  [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
Any acknowledgement that you may wish to provide can be included here.

=== References Used ===
List any references used in project.

=== Appendix ===
You can list the references you used.