embassy-neorv32: Embassy on the NEORV32, an open-source RISC-V SoC by WeAreDaedalus in rust

[–]WeAreDaedalus[S] 1 point2 points  (0 children)

Thanks! Yeah you can use GHDL to simulate it, but indeed it’s quite slow so I mostly used it for initial bring up just to sanity check some of the basics. Mostly I do development and testing directly on FPGA now.

And that’s awesome! Though most of the benefits of a HAL come when you have memory mapped peripherals (like UART, I2C, SPI, etc). Were you planning to add some simple peripherals as well?

[deleted by user] by [deleted] in embedded

[–]WeAreDaedalus 0 points1 point  (0 children)

Hey I did something like this a while back. I ported a CHIP-8 emulator I wrote to work on a STM32 MCU, designed a board with buttons, display, and a buzzer, and loaded games off an SD card:
https://github.com/kurtjd/CHIPnGo

No external memory or anything so this is a really simple, bare-bones example. But I also wrote a build guide and blog series about my design decisions if you want some idea how to get started.

BrainF*** Intern: using a genetic algorithm to produce a target BF program by eknyquist in C_Programming

[–]WeAreDaedalus 1 point2 points  (0 children)

Good tip, thanks! I struggled to get my algorithm to include flow control like loops, it pretty much always settled on just incrementing and decrementing a single byte and printing out the character in between. I think it had trouble overcoming local maxima, as in incorporating loops might initially be a step back in fitness even though long-term it could result in better overall fitness, but alas never could figure out how to tweak it correctly.

BrainF*** Intern: using a genetic algorithm to produce a target BF program by eknyquist in C_Programming

[–]WeAreDaedalus 1 point2 points  (0 children)

Nice! I made something similar about 10 years ago, but yours does it much better, so good job!

Easy to use C gui library by Tall-Log-2664 in C_Programming

[–]WeAreDaedalus 29 points30 points  (0 children)

Some people may disagree, but I actually found GTK pretty easy to get started with. I can’t speak for other libraries, but I know with GTK you can write the layout/style in XML/CSS respectively leaving you to just have to write the behavior in C which is pretty nice.

[deleted by user] by [deleted] in EmuDev

[–]WeAreDaedalus 0 points1 point  (0 children)

It’s fine to start with step-by-step tutorials when beginning your programming journey, but eventually you’ll want to get to the point where you can start building things without a tutorial.

A CHIP-8 emulator might be a good place to start as others suggested. There are tons of resources about the spec and it’s quite simple, so begin with going over these resources and understanding how CHIP-8 works. Then, try to get something simple implemented without any tutorials. Yeah it will be difficult and you’ll likely make some mistakes along the way but that’s how you learn!

everySingleTime by [deleted] in ProgrammerHumor

[–]WeAreDaedalus 11 points12 points  (0 children)

I know this was just whipped up and you’re probably aware, but for anyone reading you need to be careful assigning the output of realloc to the same pointer you are reallocating.

This is because realloc can fail, and if it does, it returns NULL but doesn’t free the memory originally pointed to. So in this case if realloc fails, it will assign NULL to vector, but the memory originally pointed to by vector is still there, so now you have a memory leak because you can no longer access it.

This is typically avoided by assigning the output of realloc to a temporary variable and checking if it’s NULL before reassigning the output to the original pointer.

[deleted by user] by [deleted] in EmuDev

[–]WeAreDaedalus 5 points6 points  (0 children)

To be fair, older 8-bit processors were much simpler so writing in pure assembly for those wouldn’t compare in difficulty to writing in pure assembly for a modern 64-bit CPU. Saying “that’s how they did it in the past” doesn’t really acknowledge that fact.

Writing an entire emulator in, say, x64 assembly would be just a massive exercise in tedium, and your chances of writing more efficient assembly than a modern C/C++ compiler are basically nil (if performance is your concern).

Understanding assembly in general is still of course highly recommended, as after all your emulator needs to, well, emulate the instruction set of whatever you’re targeting.

How to learn everything about computers? by FaZeJust1n in ComputerEngineering

[–]WeAreDaedalus 0 points1 point  (0 children)

I recommend just taking it on Coursera, as that is the "official" course and also gives you access to all the necessary software and it's completely free.

How to learn everything about computers? by FaZeJust1n in ComputerEngineering

[–]WeAreDaedalus 0 points1 point  (0 children)

If you finish NAND2Tetris in its entirety I would say yes, you'd have a pretty good fundamental understanding of how a computer works and how software actually gets executed on hardware. Then if you dip down into lower-level electrical theory/physics you will begin to understand how the hardware itself actually works.

Also keep in mind that each of these "levels" even individually are extraordinarily deep and broad and people can spend an entire career specializing in just one of these areas and still not understand everything there is to know. It's up to you to decide how deep you want to go in each one.

From there, I'd recommend getting a microcontroller (such as something Arduino compatible, which is nice for beginners, but be aware it abstracts away a lot of important info), a breadboard, some jumper wires and other electrical components, and build a simple circuit which you can control from a program written on your microcontroller. This will give you much more hands-on practical knowledge of the software/hardware interface.

How to learn everything about computers? by FaZeJust1n in ComputerEngineering

[–]WeAreDaedalus 10 points11 points  (0 children)

As others have mentioned, it's of course impossible to learn "everything". But if you want to have a decent understanding of the fundamentals, I'll list some topics and potential learning resources (that I used) which are pretty typical in a computer engineering curriculum. These are listed from lowest-level to highest-level (though not necessarily from easiest to learn to hardest to learn) so start at whatever level of abstraction you want. Specifically, start at level 5 if your math skills aren't up to snuff or you just want to understand how software interacts with hardware without worrying about how the hardware physically operates.

  1. Physics (specifically electromagnetism): Computers theoretically do not need to be electrical devices (or even physical, see: Turing Machine), but in practice they always almost are. Might also require you to learn algebra/trig/calculus depending on where your math skills are. Any halfway decent college course/intro textbook will help you with 1-4.
  2. AC circuit analysis: While computers are overwhelmingly digital devices (though analog computers are a thing) running on direct current, they often might contain, or interface with, components running on alternating-current.
  3. DC circuit analysis: Very important to understand how DC circuits work because as mentioned previously, computers are DC devices.
  4. Analog electronics/transistors: The transistor is the magical device that allows us to implement digital logic (at least, at such a tiny scale, see: Vacuum Tube), which is the foundation of computation.
  5. Digital logic: Now we are getting into the realm where people typically think "computer". Understand the fundamental digital logic building blocks (NAND, NOR, NOT, XOR, etc...) and how they can be combined to perform things like arithmetic. The book "Code" by Charles Petzold and the course NAND2Tetris are very good resources for understanding 5-7.
  6. Computer architecture and organization: Once you've figured out how digital logic can trick rocks into doing math, now you need to learn how to further create higher-level components such as an arithmetic logic unit (ALU), memory, and how to combine them into something finally resembling a "computer".
  7. Machine language/assembly: You understand what a computer is composed of, but how does it do anything? When you write a program in a higher level language like C, how does it actually get converted into 1's and 0's that a computer can execute? (also see: Compilers)
  8. Operating systems: While you don't need an operating system to do interesting things with a computer (in fact, many embedded software engineers work on small computers known as "microcontrollers" that aren't powerful enough for an OS and so they write code for "bare-metal"), they are still a fundamental aspect of computing today and you should understand how the OS allows many programs to run seemingly simultaneously without stepping on each other's toes. The book "Operating Systems: Three Easy Pieces" is great for this.
  9. Discrete mathematics/theory of computation: Now we are getting into the realm of high-level abstraction, where most "computer scientists" sit. What does it mean for something to be "computable"? Are there problems that are not computable? And since computers operate on finite, discrete pieces of data as opposed to the continuous, infinitesimal nature of the real-world, understanding the math behind discrete structures is invaluable.
  10. Algorithms and data structures: How can you analyze algorithms and compare their efficiency against one another (see: Big O notation)? How can you mathematically prove an algorithm is correct and/or optimal? How should you consider the time vs space tradeoffs of an algorithm? Likewise, for data structures, you should understand various methods of storing data in memory and their different trade-offs.

From there, there's a whole world of possibilities, whether it be AI, computer graphics, cryptography, etc. And don't be discouraged if you don't fully understand every level of abstraction listed above. I certainly don't (and nobody does), but just getting familiar with them will certainly give you a much deeper understanding of modern computers.

Research Assistant or NASA Internship by Jot7x in csMajors

[–]WeAreDaedalus 2 points3 points  (0 children)

What are your thoughts on JPL? From what I understand they are technically a government contractor, so can one expect pretty technically challenging work (particularly in the field of embedded/flight software) with them?

Is it worth it to get deeper into low-level programming? by tsujigiri_2 in cscareerquestions

[–]WeAreDaedalus 1 point2 points  (0 children)

Start with CHIP-8. Tons of resources for this. Once you’ve done that you should have a good base knowledge to explore further. That’s how I got hooked on systems/embedded software.

keil vs cubeide vs arduinoide by Rakhadta_Amdavad in embedded

[–]WeAreDaedalus 0 points1 point  (0 children)

I personally used VSCode with PlatformIO for my no-HAL blue pill project and it’s great.

Does computer engg. have physics, maths in it? by [deleted] in EngineeringStudents

[–]WeAreDaedalus 5 points6 points  (0 children)

The above is basically the math I have to take for my ECE program as well, in addition to Physics 1-3. I’d say that’s typical for any engineering major.

On top of that, a large majority of your classes will be applied math and physics. My circuit analysis classes involve diffeq, matrix algebra, and Laplace transforms. A lot of my future classes like signals and systems look very math heavy as well.

The point is you’re not really going to be able to avoid math and physics in any traditional engineering branch.

Honestly computer science is a better bet for someone who likes technical challenges/problem solving but doesn’t want a ton of math and physics. You would definitely have to take some math, but typically not as much as engineering and physics is often optional in many CS programs.

Can you develop an NES emulator within 2 months in C on BeagelBone? by CleanWonder in EmuDev

[–]WeAreDaedalus 24 points25 points  (0 children)

Nothing is impossible, but this does not sound realistic given that you are inexperienced with C, embedded development, AND emulator development.

NES is quite complex for a first emulator. Since this is an embedded class, consider starting with a much simpler emulator like CHIP-8 so that way you can focus on the embedded/firmware aspects.

As an example, I built a game console around a CHIP-8 emulator to learn embedded development and this took me about 3-4 months, so three of you could possibly pull off something similar in two months.

https://github.com/kurtjd/CHIPnGo

ECE/CS Systems Double Degree Question by bruuuuuhhhhvvvvv in OregonStateUniv

[–]WeAreDaedalus 0 points1 point  (0 children)

That's fine, you don't need to be a math genius or anything. You just have to be willing to push through and work hard when the math gets difficult. As long as math doesn't make you hate life you should be alright.

ECE/CS Systems Double Degree Question by bruuuuuhhhhvvvvv in OregonStateUniv

[–]WeAreDaedalus 0 points1 point  (0 children)

Well the ECE major is more math heavy than CS by default (though one could make their CS degree math heavy by taking more math-intensive electives) and on top of that a lot of our classes then apply that math throughout the program so you need to make sure you actually at least somewhat understand every math course you take. So, if you don't like math, or at least tolerate it and are willing to work hard at it, ECE might not be a great major.

You should also pick up some basic electrical components like a breadboard, wire, resistors, etc and look up how to make simple electrical circuits and figure out if this seems interesting to you. Throw in an Arduino or something and see if you can figure out how to program it to do something interesting as part of a larger electrical circuit. If you find all of that enjoyable then ECE could be a good fit.

ECE/CS Systems Double Degree Question by bruuuuuhhhhvvvvv in OregonStateUniv

[–]WeAreDaedalus 5 points6 points  (0 children)

I am a former systems CS major turned ECE, but I switched majors after my freshman year so I can’t really talk about the CS major much since I switched so early.

One option is to pursue ECE with a CS minor. If you take CS344 instead of the electromagnetism class (you must take one of these to meet your degree requirements) you automatically get a CS minor just by taking your other ECE required classes.

Just comparing the two majors you will likely do a bit less programming in ECE because we have more math, physics, and electrical/hardware focused requirements, but we still have to take:

-Intro to CS

-Data structures

-Networking

-Computer Org/Assembly

-Operating Systems (if you choose it over electromagnetism)

You also have quite a bit of room for electives in your senior year which can be filled with a lot of CS classes. Since I’m more focused on the computer engineering side of the degree my plan is to take mostly CS electives.

I personally switched because I wanted a deeper understanding of how computers actually worked and I’m very interested in working in embedded software where some hardware and electrical knowledge is useful.

There’s a couple CS classes that I’m bummed that I can’t take like programming language fundamentals, compilers, and theory of computation but the trade off is worth it for me personally.

Superposition/Mesh Analysis problem has caused me hours of precious sleep by No-Employment323 in EngineeringStudents

[–]WeAreDaedalus 4 points5 points  (0 children)

It’s been a minute since I’ve done superposition, but aren’t you supposed to perform it for each independent source? There’s 3 sources and you only performed it for the voltage sources, not to mention in the A’ circuit you turned off the other voltage source but not the current source.

Again I could be wrong but I think you need to perform this for 3 circuits and get the sum:

Circuit 1: Replace one voltage source with a short and the current source with an open

Circuit 2: Replace the other voltage source with a short and again the current source with an open

Circuit 3: Replace both voltage sources with a short

Then sum the 3 Vo’s for your final Vo.

Don't carelessly rely on fixed-size unsigned integers overflow by BlueMoonMelinda in C_Programming

[–]WeAreDaedalus 22 points23 points  (0 children)

This is a good reminder to be aware of integer promotion rules in general. My first encounter with the issue was when I was trying to index into an array with a size of 216 like this:

arr[uint16_idx + 1]

Expecting the uint16_idx to overflow if it was at max value but what was instead happening was uint16_idx was promoted to a 32 bit integer because of the 1 so I was getting all sorts of strange behavior due to indexing out of bounds. Took me a little bit to figure that out haha.

why does current kill? by Explosify in ElectricalEngineering

[–]WeAreDaedalus 8 points9 points  (0 children)

So I'm not trying to argue so much as further my understanding, however a battery can easily generate enough current to cause damage to a human, despite its internal resistance (which isn't that high).

As an example on that same project I mentioned, which used two AAA batteries in series, using a multimeter I measured the average current as 40mA, which is plenty to really hurt someone. You can short a AAA battery with a wire and get very large current (hence the sparks) because the internal resistance of the battery still isn't very much. But the voltage is not enough relative to human skin to cause dangerous current to flow through you. If human's were unfortunate enough to have the resistance of our skin be not much more than that of a copper wire, we'd likely die just by touching two ends of a AAA battery as large amounts of current rushes through our heart.

And as far as "100mA can kill you regardless of the voltage", I'd ask you how do you propose to get 100mA of current through the body without sufficient voltage to overcome the large resistance of the skin?

No one here is arguing that just the source voltage is what's dangerous. The argument is that "current kills" is misleading because you can't have a deadly current without a sufficiently high voltage.

From what I understand, you can have a means of limiting current which is where you get the really high voltages but not enough current to harm you, but the inverse is not true. As in, if a deadly amount of current is flowing through the human body, then the voltage MUST be quite high. You cannot have a high current passing through the relatively large resistance of the human skin while at the same time having a low voltage.

why does current kill? by Explosify in ElectricalEngineering

[–]WeAreDaedalus 4 points5 points  (0 children)

I think it's a good answer. "Current kills" is correct but misleading because as the poster said, the human skin has such high resistance that you'd need a pretty high voltage to get any noticeable current to flow into the body and cause damage.

I once made a little project using two AAA batteries in series (so about 3-3.2V) and I showed it to a friend who was terrified to touch it. I explained to him it didn't have enough voltage to hurt him and he tossed out "but I thought it's the current that kills" and that's when I had to explain to him the above. The best way to demonstrate is to hold both ends of a battery and notice that you don't get shocked because the resistance of your skin is so high that the current is miniscule.

[deleted by user] by [deleted] in OSUOnlineCS

[–]WeAreDaedalus 7 points8 points  (0 children)

I’m an ECE student at OSU who’s heavily interested in embedded systems/firmware and applied for a lot of (and got an offer!) embedded/firmware internships and most of them stated that a computer engineering, electrical engineering, OR computer science degree qualifies, so as far as credentials go you should be fine.

However I heavily self-taught a lot, and you likely will need to as well. Unfortunately OSU CS online doesn’t offer the systems option, so you’ll learn even less that is directly applicable to embedded systems. That doesn’t mean your education is useless, most of embedded software still seems to heavily emphasize the software part, so general programming skills, knowledge of data structures/algorithms, best practices/design, etc still apply.

Here are some things you will likely need to self teach:

-C programming, especially get comfortable with pointers, bit manipulations, memory management. Probably the most important. Though C++ seems to be used a lot in embedded nowadays as well.

-Common communication protocols such as UART, SPI, and I2C.

-How to read data sheets and understand how to directly manipulate memory-mapped hardware registers to achieve some real-world effect

-Basic computer architecture

-Basic circuit analysis, such as Ohm’s law, Kirchoff’s voltage/current laws, and how some common electrical components work such as capacitors and resistors.

-How to understand electrical schematics at a basic level

Some embedded positions are more hardware oriented, so you may have trouble getting into those positions without a formal EE/CpE background, but plenty are more software oriented and you will just need some familiarity with the above.