Difference between revisions of "User:Rlatinov"

From REU@MU
Jump to: navigation, search
(→‎Weekly Log)
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== Personal Info ==
 
== Personal Info ==
−
Rade Latinovich is a current student at Brookfield Central High School with interests in Computer Science.
+
Rade Latinovich is a current student at Marquette University studying Electrical Engineering.
  
−
== Weekly Log ==
+
== Weekly Log (Summer 2020) ==
 +
*Preliminary Event Planning:
 +
:- Write driver for audio module on-board to be able to output audio
 +
:- Write driver for USB Microphone to get input signal
 +
:- Various digital signal processing in-between
 +
::* Could do simple effects (reverb, delay, etc.)
 +
 
 +
'''Week 1 (01 June - 05 June)'''
 +
*Preliminary Ideas / Discussion:
 +
:- Audio Processing on the Raspberry Pi
 +
:- Raspberry Pi appears to have built-in facilities to output an audio signal, but not input one
 +
:- Would either have to use an ADC (Analog-to-Digital Converter) to capture a signal (not preferred)
 +
:- or use a USB Microphone (more preferred)
 +
::* If going down the route of a USB microphone, a driver would have to be written for the device
 +
 
 +
'''Week 2 (08 June - 12 June)'''
 +
*Ordered Pi and USB Microphone
 +
:- Received microphone but the Pi was ordered from Adafruit and it seems that it will be delayed
 +
*Explored the audio port on the Pi
 +
:- Various documentation was scattered
 +
:- Seems as if the Audio port is directly connected to the PWM channels built-in on the Pi
 +
*Pi also has a PCM module
 +
:- Unclear what it is used for
 +
:- Does not seem to tie into the Audio port at all, perhaps requires external circuitry
 +
 
 +
'''Week 3 (15 June - 19 June)'''
 +
*From previous week, a challenge was presented. How do we get audio data out from the audio port? The audio port is directly tied to the PWM, but how is the audio data (PCM encoded) translated to fit into this scheme?
 +
*Explored Linux source code to see how it is done:
 +
:- Learned that there are many abstractions in the Linux Kernel (knew previously, but the idea was reassured)
 +
:- Have not found the part of code that directly talks to the hardware on the Pi
 +
*Pi still has not been delivered in the mail
 +
*In the mean time, I have been working on the maintaining / auditing the current port of Embedded Xinu to the multicore platform
 +
:- Worked on auditing spinlock mechanisms in the kernel
 +
 
 +
'''Week 4 (22 June - 26 June)'''
 +
*Received Raspberry Pi 3 B+ on 22 June, Monday
 +
:- Also received oscilloscope from [[user:brylow|Dr. Brylow]] to borrow for the summer
 +
*Working on UART initialization issue
 +
:- When running Embedded XINU standalone (outside of Systems Lab), UART does not get initialized proper
 +
*Assisted Embedded XINU team with various bugs
 +
:- UART bug as mentioned above
 +
:- Exception handlers (traps) for various types of errors that can occur (work in progress)
 +
 
 +
 
 +
== Weekly Log (Summer 2017) ==
 
'''Week 1 (30 May - 4 June)'''
 
'''Week 1 (30 May - 4 June)'''
 
*Downloaded a new cross-compiler toolchain (aarch64)
 
*Downloaded a new cross-compiler toolchain (aarch64)
Line 22: Line 66:
  
 
'''Week 3 (12 June - 16 June)'''
 
'''Week 3 (12 June - 16 June)'''
−
*Found out default UART clock frequency for Pi 3 was 48 MHz
+
*Found out default UART clock frequency for Pi 3 is 48 MHz
 
*Hacked together a method to initialize the UART hardware in the full version of Xinu
 
*Hacked together a method to initialize the UART hardware in the full version of Xinu
 
*Started working on correctly implementing the UART driver in Xinu
 
*Started working on correctly implementing the UART driver in Xinu
 +
 +
'''Week 4 (19 June - 23 June)'''
 +
*Correctly implemented synchronous UART driver in Xinu
 +
*Started on changing Exception Level (EL) upon boot
 +
:- Boots in highest EL (EL 3) and have to be in EL 1 for kernel to run properly
 +
*Started to work on getting interrupts to work
 +
 +
'''Week 5 (26 June - 30 June)'''
 +
*Figured out Pi 3 boots in EL 2 upon boot
 +
:- This is why code was breaking when trying to change ELs
 +
*Interrupts still not working
 +
 +
'''Week 6 (3 July - 7 July)'''
 +
*Successfully changed EL to EL1
 +
*Starting to refactor messy code
 +
 +
'''Week 7 (10 July - 14 July)'''
 +
*Decided to use Pi 3 in 32-bit mode
 +
:- Compatible with old Pi 1 code
 +
*IRQ's are working!
 +
:- Reaching dispatch() within irq_handler()
 +
:- Vector table is set correctly
 +
 +
'''Week 8 (17 July - 21 July)'''
 +
*Added and modified documentation in start.S
 +
*IRQ's are working successfully and as they should be in Xinu
 +
*Asynchronous UART works now!
 +
:- Tested only printf()
 +
::* Have to have a delay to use printf() immediately after enabling interrupts
 +
*Cleaned up #define's from beginning of project in initialize.c
 +
*The System Timer works and clkhandler() is being called properly
 +
*Preemptive scheduling now works due to interrupts and system timer peripheral working
 +
 +
'''Week 9 (24 July - 28 July)'''
 +
*Starting on working on multicore functionality with Patrick
 +
*Started researching on mutex's and started to implement mutex lock with ldrex/strex opcodes
 +
*Found out some weird info about using ldrex/strex opcodes
 +
:- Cache and MMU have to be enabled
 +
:- ldrex opcode requires memory address to be in cache and marked as shareable by MMU
 +
:- Configured MMU with minimal configuration
 +
::* Virtual address are mapped one-to-one with physical addresses
 +
::* Non-peripheral memory space is marked as cache-able and shareable
 +
*Finished paper and submitted to EWiLi conference for Embedded Systems Week
 +
:- Find out if accepted on August 21st
 +
 +
'''Week 10 (31 July - 4 August)'''
 +
*Continued working on mutex lock implementation
 +
:- Not working as should across all cores
 +
*Poster session
 +
*Final presentation

Latest revision as of 00:00, 28 June 2020

Personal Info

Rade Latinovich is a current student at Marquette University studying Electrical Engineering.

Weekly Log (Summer 2020)

  • Preliminary Event Planning:
- Write driver for audio module on-board to be able to output audio
- Write driver for USB Microphone to get input signal
- Various digital signal processing in-between
  • Could do simple effects (reverb, delay, etc.)

Week 1 (01 June - 05 June)

  • Preliminary Ideas / Discussion:
- Audio Processing on the Raspberry Pi
- Raspberry Pi appears to have built-in facilities to output an audio signal, but not input one
- Would either have to use an ADC (Analog-to-Digital Converter) to capture a signal (not preferred)
- or use a USB Microphone (more preferred)
  • If going down the route of a USB microphone, a driver would have to be written for the device

Week 2 (08 June - 12 June)

  • Ordered Pi and USB Microphone
- Received microphone but the Pi was ordered from Adafruit and it seems that it will be delayed
  • Explored the audio port on the Pi
- Various documentation was scattered
- Seems as if the Audio port is directly connected to the PWM channels built-in on the Pi
  • Pi also has a PCM module
- Unclear what it is used for
- Does not seem to tie into the Audio port at all, perhaps requires external circuitry

Week 3 (15 June - 19 June)

  • From previous week, a challenge was presented. How do we get audio data out from the audio port? The audio port is directly tied to the PWM, but how is the audio data (PCM encoded) translated to fit into this scheme?
  • Explored Linux source code to see how it is done:
- Learned that there are many abstractions in the Linux Kernel (knew previously, but the idea was reassured)
- Have not found the part of code that directly talks to the hardware on the Pi
  • Pi still has not been delivered in the mail
  • In the mean time, I have been working on the maintaining / auditing the current port of Embedded Xinu to the multicore platform
- Worked on auditing spinlock mechanisms in the kernel

Week 4 (22 June - 26 June)

  • Received Raspberry Pi 3 B+ on 22 June, Monday
- Also received oscilloscope from Dr. Brylow to borrow for the summer
  • Working on UART initialization issue
- When running Embedded XINU standalone (outside of Systems Lab), UART does not get initialized proper
  • Assisted Embedded XINU team with various bugs
- UART bug as mentioned above
- Exception handlers (traps) for various types of errors that can occur (work in progress)


Weekly Log (Summer 2017)

Week 1 (30 May - 4 June)

  • Downloaded a new cross-compiler toolchain (aarch64)
  • I was able to compile sample code found from https://github.com/gingold-adacore/rpi3-fosdem17, with new cross-compiler
  • Modified the sample code to turn on a LED
  • Downloaded simple and watered-down version of Xinu (homework tarball)
- Modified startup.S file in order to be able to boot on RPi3 (did not do anything, but it compiled, and LED turned on)

Week 2 (5 June - 9 June)

  • Started to narrow down on where the code is not working
- Made sure assembly code (start.S) was able to boot
- Then made sure the assembly code can branch to a C method, or some of our C code
  • We were able to make our kernel image boot at the default starting address, this removes the need for us to manually specify where the Pi should boot the image
  • Got "Hello World" through mini UART.. (wrong UART)
  • Started to work on PL011 UART driver
- Biggest difference between PL011 and mini UART is that mini UART's baud rate is partially determined by systems clock frequency, and PL011 has separate reference clock frequency independent from the system clock.
- PL011 uses reference clock frequency determined by BCM2835 Clock Manager
  • We were able to figure out how to control the clock for the GPIO, now we need to do the same thing but for the PL011

Week 3 (12 June - 16 June)

  • Found out default UART clock frequency for Pi 3 is 48 MHz
  • Hacked together a method to initialize the UART hardware in the full version of Xinu
  • Started working on correctly implementing the UART driver in Xinu

Week 4 (19 June - 23 June)

  • Correctly implemented synchronous UART driver in Xinu
  • Started on changing Exception Level (EL) upon boot
- Boots in highest EL (EL 3) and have to be in EL 1 for kernel to run properly
  • Started to work on getting interrupts to work

Week 5 (26 June - 30 June)

  • Figured out Pi 3 boots in EL 2 upon boot
- This is why code was breaking when trying to change ELs
  • Interrupts still not working

Week 6 (3 July - 7 July)

  • Successfully changed EL to EL1
  • Starting to refactor messy code

Week 7 (10 July - 14 July)

  • Decided to use Pi 3 in 32-bit mode
- Compatible with old Pi 1 code
  • IRQ's are working!
- Reaching dispatch() within irq_handler()
- Vector table is set correctly

Week 8 (17 July - 21 July)

  • Added and modified documentation in start.S
  • IRQ's are working successfully and as they should be in Xinu
  • Asynchronous UART works now!
- Tested only printf()
  • Have to have a delay to use printf() immediately after enabling interrupts
  • Cleaned up #define's from beginning of project in initialize.c
  • The System Timer works and clkhandler() is being called properly
  • Preemptive scheduling now works due to interrupts and system timer peripheral working

Week 9 (24 July - 28 July)

  • Starting on working on multicore functionality with Patrick
  • Started researching on mutex's and started to implement mutex lock with ldrex/strex opcodes
  • Found out some weird info about using ldrex/strex opcodes
- Cache and MMU have to be enabled
- ldrex opcode requires memory address to be in cache and marked as shareable by MMU
- Configured MMU with minimal configuration
  • Virtual address are mapped one-to-one with physical addresses
  • Non-peripheral memory space is marked as cache-able and shareable
  • Finished paper and submitted to EWiLi conference for Embedded Systems Week
- Find out if accepted on August 21st

Week 10 (31 July - 4 August)

  • Continued working on mutex lock implementation
- Not working as should across all cores
  • Poster session
  • Final presentation
Retrieved from "https://reu.cs.mu.edu/index.php?title=User:Rlatinov&oldid=3844"