Hey this is a very well written blog, good job! I tend to do my markdown in vscode now. However, before that I was using VIM with goyo and ftplugin/ftdetect for *md files. I guess I'm just lazy now.
Much of learning is repetition. I don't have the best long term memory so I solve this by regularly keeping an engineering journal. I designed a Django app to help me with this at work. Should it be of any help to you feel free to use it, hack it or build off it. Cheers~S
I haven't needed my notes that often but on occasion I do and that's usually when I'm glad I took the time to keep a engineering journal.
I accomplish this with a jupyter-notebook inside a git version controlled repository. I'll usually write my notes down in markdown format. Markdown is nice for me because it forces me to write clean/formatted/organized notes versus just writing random stuff down in a word doc. Jupyter-notebooks work great for me because much of my scripting is done with python. So I can include snippets of python code if I want as well as share it with my friends/colleagues.
Our company has an internal server that hosts the atlassian tools such as confluence/bitbucket/jira/cruciable. Each of us in the software department have our own company bitbucket account. Therefore, I keep my jupyter-notebook hosted on my bitbucket account.
For personal use I have moved away from paper/pencil journals. I usually collect my notes in the same way or sometimes just in a text file that I organized in their own dedicated git repositories on my GitLab account. Usually it's a project per project basis. For example, I version control many things in my home directory on my Linux computer like my bashrc/bash_profile/vimrc/zshrc and files alike. This gets consolidated in a "My_Linux_Setup" with other notes of mine of what packages and libraries I need to install should I need to reimage my computer.
I "was" in the same boat as you so don't feel bad. For the past few months I've been writing unit tests.
My application has the ability to receive commands and send telemetry back over a socket to a user interface. This exposes several features in how I can test it's functionality which makes writing unit tests much easier. Good code is code that can be tested well!
Something that isn't taught but is more so learned (I've personally noticed) is architecting your software to be testable. This has really made me think about how I should write code to not just "do it's intended purpose" but also "in how it will get tested".
My preferred setup is something small but manageable. By this I mean something that I can scale if needed but also reliable across different domains (such as gaming, coding, web surfing, etc)
How many?
2
Size?
~27inch
Resolution
2560x1440
Why not 4k? The 4k'ish feel of having multiple windows opened on your monitor will plenty of space left over is a good vibe. However, I've experienced several IDE's that do not scale well with 4k monitors. Several embedded design suites look awful because of this and you sometimes need a magnifying glass just to find the right button you need. Yea you can find work arounds for this but why deal with it at all.
Ultra Wide
They look appealing I admit but haven't invested in one yet. There's just something about multiple monitors that's appealing to me over one gigantic one. Plus if I ever have two systems I want to hook up and see at the same time then I have this option with two monitors. If I had one gigantic one i would need to invest in a switch i guess.
I don't like the glossy style screens. I like that dull rough look (I can't think of the technically term for it but the less shiny screen whatever that is). I use a few color schemes that just look awful on the glossy "shiny" style screen. My eyes start to hurt on those screens as well which is another reason I favor the "dull" screen look.
I get a high frame rate monitor. I find it less stressful on my eyes along with the dull screen I mentioned above. Comfortable distance is about 2 to 3 feet.
Was this part of the datasheet of the chip? Perhaps I've missed this section but I've never recalled the datasheet including this information. Is this usually covered in a separate application note or whitepaper?
It could be anyplace. You might try calling the vendor and asking to speak with one of their Application Engineers. Their job is to encourage chip adoption, so they will usually take such calls if you tell them you are doing a new implementation on their chip.
I'm very new to this concept of bootloaders for embedded processors so bare with me. The answer that best aligns to your question is "trying to initialize the processor prior to running to application code".
Some of the critical tasks I would like my bootloader to cover are...
1) Initialize critical parts of the processor (oscillators, clock branches, peripheral enables, etc..)
2) Initialize a few peripherals like UART to provide some useful "readable" output during this process
Some additional "would be nice" features I would like to do are...
1) Load an application from a SD card
2) Parse over the application executable for validity purposes
Let's establish one fact first: when working with the smaller processors and SoCs, there's no such thing as a generic bootloader. The final code for any bootloader will be highly specific to the part.
Your request #1 is on the mark: you want to cold-boot the chip and get the various necessary registers in place to accomplish #2, which is set up some of the peripherals to begin working.
So you have two choices:
1) Start reading the TRM and writing assembly code to do this, then read the TRM again and understand the boot sequence to figure out how and where to load the code.
or...
2) Read existing code to learn from someone else's work, because they did the exact same thing at some earlier point in time.
Then you just need to read the chip docs and initialize "everything" to a reasonable state. There's not much to it beyond that--there's no generic process for doing that.
Loading an app from an SD card is likely harder than you think: it needs to be compiled/assembled correctly, you need to define where it starts, how it's linked, etc.
"Parse over the app executable for validity" is super-broad, and could mean just about anything. If you're trying to validate compiled programs, this will be difficult. If you're trying to validate byte-code programs (or something similar) it's significantly easier (or even unnecessary).
It'd probably be helpful if you were able to define specifically what you're trying to accomplish, and why an existing system doesn't meet your needs. While writing a trivial execution environment is really easy, writing a general-purpose OS is significantly more difficult.
You should strive to find out what area of computer science you enjoy versus making it about your GPA or trying to be the smartest in the class. If the latter is your goal you're going to be disappointed.
It's hard, or was for me, to do projects on your own time when you're full time student. Therefore, apply yourself in learning as much as you can from your classes and build off the assigned work as much as possible if you have free time.
Lastly, learn how to develop a good work ethic. Try to revert from googling answers. Struggle and try to find your own solutions. Pay closer attention to your compiler warnings without googling them. Utilize tools to debug your code versus googling if someone else had the same issue and what their solution was. In all, learn how to struggle effectively to improve your overall understanding of concepts and problem solving.
Thank you for the thorough advice! Thing is, I'm interested in so many areas of computer science from low level compiler stuff all the way to machine learning. Hopefully from taking classes, I'll be able to narrow these downs.
I came across an article published by a MIT professor on solving complex problems. I'm going crazy right now because I can't seem to find it anywhere. However, I did come across this site which looked interesting. Perhaps you'll get something out of it.
Cheers ~ S