NOTION JOURNAL FOR ALL WEEKS PAST 5




JOURNAL PDF





Project Journal for Seth Deegan

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

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

Date: Februrary 14
Start Time: 1:30pm
Duration: 1 hour

Today instead of getting embassy to work, I went back to researching on how to implement the emulator because I now get how to implement the CPU. You can make the CPU a struct with methods like step(instruction) that will parse the instruction, and modify the registers/execute memory transactions based on the instruction.
Now that I knew this, I then looked through the Intel 8080 datasheet again to look at how the opcodes for each instruciton are formated. As I read, I realized that the opcodes were actually the same for multiple different instructions and that only register values of a different arrangement of bits differentiated them. 8080i is not like RISC-V where the opcode is the entire instruction. This means that I will need to write a parser that will take the opcode and the register values and determine what instruction to execute based on the opcode and the register values.
After understanding this, I then looked at the rs80 emulator again to see how he implemented parsing the instructions. He had a custom txt file format that stored all the instructions and their format and what rust code to execute for them. This txt file was then ingested by a separate package from the emulator that was responsible for code genning all of Rust code to handle the instructions. As he notes in his documentation, there are "256 possible 8-bit opcodes. Instead, the input file contains 59 instruction definitions which are processed and specialized." This is a great approach and probably what we should do for our project. In fact, how he implemented the emulator is exactly what we should do for our project so I then freaked out a bit how we could possibly make our emulator different.
After talking with Brian, Brian reminded me that the rs80 emulator did not handle memory wait, waiting for actual memory to respond and that in our emulator we would need to do that.
Therefore, I came up with my next steps which will be:
  • I think I'm just going to get the Emulator programming on the Pi
  • Run and hook up the RS80 simulator to our embedded code
  • Simulate bus signals on the GPIO pins
  • Hook it up to the pins and LEDs on the board
  • Then use the IO expander we have to expand the signals like we will do on our final board.
  • Modify the rs80 code to handle memory waiting stages so that is is machine-cycle based and not instruction-cycle based.
And that's our software development plan!

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

Date: Februrary 12
Start Time: 12:30pm
Duration: 1 hours

As a continuation of this time on the 12th, I asked ChatGPT a variety of questions about RTOSes and how interrupts/allocating CPU time between proceses work to better understand how process switching works in operating systems. This wasn't exactly relavant to our project, however it gave me a better perspective on how interrupts work and when they are executed so I knew their differnce with classic polling loops. For this reason I think we will do interrupts to step through/run/stop the CPU.
Thy questions/answers:
does px4 autopilot use an rtos when it runs on a pixhawk? yes nuxtt os

what's happens between when a person clicks a button on a keyboard and the program recieves it on linux? what syscalls or whatever are involved? x11/wayland, can use poll, read syscalls. poll freezes execution of a program. can spawn multiple threads to wait for things in an os.

can you manipulate cpu time, the scheduling method, etc. in linux? yes cgroups
can you cahnge scheduling type in windows? kinda ya you can set priority

can i see the list of processes and their ids in linux? ya

what does %cpu usage mean in task manager technically? isn't the cpuu techincally running at 100% most of the time beause it's running monitoring loops? it's the percent of time the cpu is active with user requests. most programs just wait for interrupts triggered from syscalls to resume execution. they don't need to run 24/7. only if you make a while (1) loop will it run 24/7.

what's the diff between proceses, subprocesses, and ids in windows task manager cpu. ids mean all threads

does rust have a callback queue/event loop like js? no it just spawns threaded runtimes

when you write a driver for linux do you interact with syscalls? are syscalls the only interface/api to a kernal? no you use kernal space interfaces. kernal interfadce links hardware to os. syscalls link os to program. open() syscall will call the open function defined in the driver. same with read() write().
END Q/A
Finally I learned about memory ICs and broswed digikey on how to find them. I later learned Brian had already selected one, however this gave me the opprotunity to understand what was available out there, the sizes of memory ICs, and the different protocols they used.
My next steps will be to try to get the embassy crate to work with our Pico repository so that we can program our microcontroller with Rust using that.

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

Date: Februrary 12
Start Time: 10am
Duration: 2.5 hours

Today because I now shifted my focus from coding to emulator to coding for the microcontroller, I decided to create a new package in our main Rust repository dedicated to just programming the Pico. I did this instead of just starting on a Rust repo because the Pico was just our development board and was not going to have the same layout/interface/board abstraction layer as our final board design. I then added the cargo dependencies from the example RP2350 example repository that I used previously to first progam the RP2350 with Rust. I ran into some missing linker files which I added from the original repo to mine, however even after adding those I ran into other linker errors that did not relate to missing files. This is the one I got stuck on:
rust-lld: error: undefined symbol: _critical_section_1_0_releaseā
I think it got stuck because the rp235x-hal package is not correctly built for the version that is published on Cargo.
I was unable to fix this so instead of trying to further debug how to get the rp235x-hal package to work, I researched again if any other Raspberry Pi microcontroller HAL cargo crates existed. I came across this Rust on the RP2350 blog post again and in addition to mentioning the rp-rs project that publishes the rp235x-hal, they also mentioned another project called Embassy.
I looked at Embassy's website and realized it had the unique property of async/await which I was familiar with Javascript. I used ChatGPT to help me understand how async/await worked in Rust vs how it did in Javascript. I learned that in Rust, async/await is compiled to a bunch of state machines and the order of execution/waiting hands idle time over to following instructions. I also learned the difference between concurrent and cooperative running. I also learned what rust runtimes like tokio do. Finally, I learned what RTOSes do and how they differ from regular operating systems. I did this because the Embassy project noted that it was a faster alternative to traditional Real Time Operating Systems at the cost of maybe more code. RTOSes are more lightweight than traditional operating systems and directly use interrupts to handle events and poll for new event priorities maybe every 5 or so insturctions vs time-based CPU slicing which traditional OSes do.
This was all of interest to our project because I wanted to know if async/await or RTOS would be a better/easier implentation for our emulator/microcontroller over standard interrupts/polling loop. I determined async/await would be okay and that we could proceed with embassy.

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

Date: Februrary 10
Start Time: 10am
Duration: 2.5 hours

Today I focused on beginning writing the emulator because I thought that would be easier than starting directly on the embedded interface code. Because I have not coded in Rust a awhile, I needed to review data structures so that I knew how to implement the data structures to hold the registers for the emulated CPU and methods to perform operatoins on the CPU. I began going through the beginning of the Rust Book again. I recalled how structs, enums, mutability, ownership, and implements work. These functions of the language should be enough for me to be able to program the emulator.
I also realized when beginning to write the emulator that we would need separate code for our memory card that was to also operate on a clock cycle and send signals from our bus on the GPIO pins over SPI to a memory module on our memory board. Because of this I started another Rust package in our workspace for the memory and drafted memory get/recieve methods.
Midway through drafting the architecture, I got confused how our Rust package for the emulator was going to react to clock signals. I thought implemting the code needed for our microcontroller from the top down (GPIO signals first, emulator second) would help clear this up.
Now that I switched to thinking about how the emulator would handle clock signals, I was researching whether we should use just an infinite loop to poll for external clock signals or create interrupt functions. This led me to do more research on their differences and review what actually happens during an interrupt routine as we learned in 362.
I ran out of the time for the day so I decided to leave this research of interrupts vs loop for the next day.

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

Date: Feb 8
Start Time: 9:30
Duration: 1 hour

Today I focused on debugging why the pico was not flashing with example Rust-based code.
I was trying to flash it using the elf2uf2-rs tool, however, I found a Github issue that said the elf2uf2-rs tool cannot flash the RP2350 yet and that I should use picotool instead. So I downloaded picotool and changed what tool was being used to flash in the `.cargo/config.toml` file and ran `cargo run --target thumbv8m.main-none-eabihf` and it worked!
What's annoying is that you have to unplug and replugin the USB every time and hold the BOOTSEL button when flashing in order to get it into flashing mode for UF2. However, once it flashes, the program runs immedeately.
Now that we can program the microcontroller with Rust, we can begin writing the Rust code to listen to bus signals on the GPIO pins as well as begin integrating it with basic emulator code to say enter instructions with switches and trigger a clock signal with the push of a button. That will be my next step.

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

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

Date: Februrary 7th
Start Time: 9:30am
Duration: 4 hours

First I updated our PSDRs and functional description based on weekly feedback.

Then I got to trying to figure out how to flash the pico with our Rust project code. I compiled the Pico code sucessfully using cargo and tried to flash using `cargo run` but that failed. I saw it was trying to use probe-rs which I thought I had installed, but it looks like I did not because the command was not available. I then instaleld it and tried running it again but it said no probes could be found. I then realized probe-rs is only meant to work with a dedicated/separate debugger and I would need a dedicated debugger like another Pico or ST-Link in order to use it to flash our Pico.

So because I did not have another debugger on hand, I found in the flasshing methods section of the repo that you can flash in other ways like UF2.

UF2 allows you to just upload a UF2 file to the pico over its USB file system which is triggered when you hold down the boot select. I was able to do that and it programmed sucessfully.

A debugger will be useful in the future, so I've decided I'll bring my st-link from 270 and hook it up to the SWD lines on the pico to try debugging it.

Finally I needed to work on A5 and write the justification for why we chose the RP2350 microcontroller. As part of this process, I realized I didn't have a good grasp on Program IO so I read this article on how it works and how it can be programmed. I then consulted the RP2350 datasheet to further learn how PIO is supposed to be used.

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

Date: Februrary 5th
Start Time: 10am
Duration: 3 hours

First I worked with Nathan on getting the raspi pico that we had on hand programmed.

First I tried following the raspi pico getting started manual and using the VSCode extension, but I was unable to get the toolchain to download on my computer. So then I had nathan do it and he was able to get it to download and flash.

Next I got started on figuring out how to setup an embedded Rust project and program our Pico with it.

I first created a rust package for "cycle", our emulator, which I wanted to run first. When creating this, I had to learn about cargo and the difference between workspaces and packages. I decided to make our emulator just a package in our monorepo since it may link with other things in the future.

Finally I needed to figure out how to use the repos in the rp-rs org to program embedded rust for our microcontroller. I came across this starter project template https://github.com/rp-rs/rp2040-project-template

I also needed to learn the terms of the other types of repos in the github org like HAL, which is hardware abstraction layer, and PAC which is Peripheral Access Crate. These are the handy APIs/interfaces for manipulating our microcontroller with rust without having to change registers and stuff.

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

Date: Februrary 3rd
Start Time: 10:15am
Duration: 1 hour

First I watch how a microcontroller starts video to learn how the boot process of the program we flash is set up and how the Rust based flasher we are using will do it as well.

Next I did a bit of reading of the embedded rust book, learning about how embedded rust code typically looks and what data structures/coventions we can expect.

Next I got into a bit of a read about posix/cygwin cause I noticed embedded rust code can run on a variety of environments like bare metal vs. hosted. We will probably only need bare metal for our project.

Finally I looked back into how platformio works since I was wondering if it supported Rust-based microcontroller development. I needed an easy way to get started with the pico we had lying around and I knew platformio was mostly C programming so I anticipated it was not available yet and I was correct. So we're going to have to stick with rp-rs.

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

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

Date: January 31st
Start Time: 9:30am
Duration: 3 hours

Today I needed to figure out how to convert the Intel hex to binary. ChatGPT pointed me to just writing a simple Rust program to this which I tried.

I realized that I need to place it in a specific part of the repository like as a binary to make the rust compiler happy because the folder I was putting it into was a cargo project and all Rust files in a project either need to be a library or a binary.

I then did ChatGPT's second suggestion of using the `srec_cat` command line utility to compile the hex to binary. I was confused how to get this CLI tool until I learned more how Debian packages work since I'm working on Debian. I took a little bit of a sidetrack into learning about Debian packages.

I learned that packages can have the same name in different repositories (debian, debian-updates, debian-security) and the package manager will chosse the package with the highest version when upgrading

I also learned about supported architectures for debian and that the official ones, powerpc, arm varients, x86 64 and 32, ibm z all the packages are supported. So all the packages must be compiled to run on those architectures and the maintainers of distros handle upgarding packages, not the package maintaners. And then you can have multiple versions of a package on a system and apps on a system can point to different versions of a package they need since they are dynamically linked. And then finally, Rust packages try to all be statically linked (all in the binary) but debian maintainers don't like that so they try to break up the packages.

Although this was a bit sidetracked, this helped me learn about the packaging ecosystem and how Rust works with it. It helped me tie my knowledge about dynamically linked libraries learned in OS right now to my work of how we are going to program and link our programs on our microcontroller.

I then got the actual package name for `srec_cat`, Srecord, and tried converting the hex, but didn't have luck. It seemed like that the assembler was not happy with my output and the assembler was not happy what I loaded into memory and tried to step over the isntructions. I wasn't fully confident why it wasn't stepping correctly and also wondered how the processor knows it's on an opcode vs value vs register/address. I need to save that for next time.

Since I now have have a good idea of how the entire repository works, I diverted my attention to getting our own repository setup. However, I realized that I didn't know really how to start and how our emulator was going to interface with the microcontroller itself and not just a human user through a terminal like the emulator in the rs80 project.

This led me beginning my research into embedded Rust. First I looked through the respositories that Brian had linked that are part of the rp-rs organization that has developed tools to program RP-series microcontrollers with Rust. However, I realized I didn't know exactly what most of the repositories did and that I need more of a getting started guide.

I then looked up some embedded Rust resources. I came across this How to Do Embedded Development with Rust which I began watching. Also began watching this How a Microcontroller starts video because I want to get an idea how the Rust framework programs the microcontroller and how memory is laid out on a Microcontroller. Finally I found this Rust on RP2350 - Raspberry Pi blog post which I will save for later.

The progress today has opened my research up to jumping into embedded Rust and getting started on our software development. I'm excieted to learn how to write type-safe code for our microcontroller and how to interface with the hardware. Next steps are to finish getting through those above resources and begin coding!

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

Date: January 29th
Start Time: 9:30am
Duration: 2.5 hours

I wasn't able to find the registers available in the original 8080 manual for computations so I found this additional cheat sheet. We could even make our own cheat sheet that is a bit more understandable like this RISC-V one so that future people can more easily program for our emulator.

After understanding all instructions available for the 8080, I then went back to investigating how to run the rs80 8080 emulator Rust repository. I found that these compiled binaries were available:

mon: a debugger that allows you to read and write to registers and load a file into memory and jump to address and then exec

asm: assembler that take 8080 instructions and turns them into 8080 ones doesn't seem to work well though rn with MOV A, M just as text in an input .asm file. Uses the CP/M ASM compiler. The emulator actually spawns the original CP/M compiler on the emulator itself to compile the assembly code you provide on the host system and then spit it back out. I found the manual for the CP/M assembler here which gave me a better idea of its output and how to use it.

disasm: Just a disassembler

main.rs: A main runtime for the emulator for which you are supposed to provide an OS image like CP/M to execute.

From this research I determined that we will need an assembler like CP/M in order to convert our 8080 code to binary.

I also realized that the assembler only spits out Intel Hex and that the intel hex cannot just be inserted into memory using the mon debugger. Intel Hex != binary. Only part of the intel hex is the binary we need, and we need to convert the hex to binary using some tool.

Finally I learned about the tests folder that contains various test .COM (executable 8080 binary) images that are used to verify the emulator properly exeecutes all available 8080 instructions. We should incorporate such tests into our emuator as well.

I will save the rest of converting the intel hex to 8080 for friday. This progress today got me closer to my goal to running the rs80 repo.

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

Date: January 28th
Start Time: 7:15pm
Duration: 0.75 hours

During this time I attempted to get the rs80 8080 emulator Rust repository created by cbiffle on GitHub running. I di this so that I can get an idea of how we can structure our own implementation of a repository and how to construct a Rust project since I don't have really any experience using Rust.

To understand how to run the repository, I utilized GitHub Copilot to look at the repository for me and give me an idea of what its contents, produced binaries, and available commands were.

I then realized I didn't have a good foundation of what the 8080 instruction set looked like so I didn't know how I could write an assembly program to run on the rs80 emulator.

I then began reading the 8080 ISA datasheet. I just read through the first few pages and during this time I determined how the two different clocks of the 8080 work, what cycles and states are, and read through the instruction set. I then learned that opcodes are 8 bits which take up the entire processor bus (8 bits) so it takes multiple states to execute one instruction, contrary to say RISC-V. Learning this helped me understand how I would write our own emulator to process instructions and that we don't need to emulate the entire functionality of the 8080, just be able to process the instructions according to external bus signals.

Next steps will be to continue reading the manual since I didn't get through all the instructions available.

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

Date: January 27th
Start Time: 9:30am
Duration: 2.5 hours

I read through more of the RP2350 datasheet.

I specifically read through the GPIO pins available and their functions. This was to determine what pins would be available to function as our S100 bus.

I then investigated the bus layout (2.1) and processor layout. This was to get an idea of how the microcontroller interfaced with its pins. Additionally how data was controlled between the RISC-V and Arm cores available and how we could use them if we wanted to choose one or the other.

Terms that I found in the document and used ChatGPT to learn about included the Always-On-Timer and Serial Wire Debug Input/Output. Reasearching these terms helped me get a wholistic view of everything that was available with the microcontroller and how we could use it for our project.

I think I am well-versed in the overall capabilities of the microcontroller we are using. I'm now going to move onto researching how to code the emulator I and Caleb will be responsible for implementing since that is a more urgent task.

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

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

Date: January 24th
Start Time: 9:30am
Duration: 1.5 hours

I discussed with brian how our computer would load programs

I learned that the front panel is basically useless because it doesn't allow for easy program input while the computer is running and is mostly for just programming the bootstrapper for the microsoft basic OS you were going to load into memory. Then all programming was done via the os on a monitor connected over the uart. could be teletype, etc.

So our computer is not that useful without uart and although it is a stretch goal it is one I want to achieve.

We would want to connect our computer over uart and open a serial console to interface with it.

I also determined with the team that we are going full rust and not programming the 8080 with C. Based on this rust implementation of the 8080 it's not that much to establish the data structures to get the state machines for the processor. I was concerned that because rust has a high learning curve and Caleb who was working on the software with me might struggle, however we believe we have enough time to learn rust and program the 8080 emulator in the semester.

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

Date: January 22th
Start Time: 9:30am
Duration: 2.5 hours

Today I went through the RP2350 datasheet today (1.5 hours). Learned about how programmable i/o works using ChatGPT (what we're going to use for our bus) and why we're choosing it for our microcontroller vs. others (dicussed with brian).

I attended project discussion/group meeting (0.5 hours)

Looked through the code of the Rust 8080 emulator repository we were looking at that was similar to what we wanted to implement. Determined that we could use this as a test suite to check our hardware if we don't finish our own emulator before.

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

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

Date: January 17th
Start Time: 9:30am
Duration: 2 hours

I wrote the functional description on the a1 doc as well as drafted the budget

I made and reviewed project milestones with the team

I uploaded bio to website and functional description

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

Date: January 15th
Start Time: 8:00am
Duration: 3.5 hours

Before lab I learned about the s100 bus today, researched the 8080 instruction set, and watch some altair 8080 programming videos

Then in lab we learned about the lab resources and introduced our team

I then discussed with brian and team what case we want (extruded aluminum) where the pcb slides in on one of the ledges. What box we choose determines our PCB size

Then we discussed what project management software. microsoft planner, notion, github issues?

I got the Github org setup with the name Alpha Cassiopeiae