Need help starting with embedded programming - Page 1
Forum section: electronics / general

author: avogadro
author_rank: Contributor
timestamp: November 25, 2018, 01:05:15 pm
content: So Im currently in the second year in uni studying EE. We recently started learning about digital electronics and vhdl and Im starting to really like it. I was plaining on buying an fpga board to do projects at home. Anyway I stumbled upon fpga and arm interfacing stuff so now I want to get more into embedded in particular arm microprocessors but I dont know where to start. Im okay in C but I lack knowledge in the workings of an mcu. I would also like to buy a cheapish arm dev board. So if anyone could point me in the right direction, suggest books, online courses and dev boards Id really appreciate it.

author: pyroesp
author_rank: Regular Contributor
timestamp: November 25, 2018, 02:56:00 pm
content: STM Discovery boards are pretty cheap.

author: newbrain
author_rank: Super Contributor
timestamp: November 25, 2018, 03:44:01 pm
content: If I could have a nickel for every time this topic came up and I gave MHO...well, maybe I could buy me an ice creamOf course this question has as many answers as thre are forum members, so here's some link to older discussions.https://www.eevblog.com/forum/microcontrollers/microchip-or-atmel-arm_s/https://www.eevblog.com/forum/microcontrollers/starting-with-arm-cortex-m/https://www.eevblog.com/forum/microcontrollers/best-way-to-start-moving-away-from-arduino/https://www.eevblog.com/forum/microcontrollers/which-board-to-buy/To the above I would add this: since you are interested in programmable logic, have a look at thePSoC 5 Prototyping kit.The MCU is a Cortex-M3, and it has some programmable logic on it (enough to build a VGA like video adapter!).Pros:- Extra cheap- 5V if you need to interface 5V stuff, plus some IOs can be set to a reference voltage of your choice- The peripheral libraries are clear, well documented, no-nonsense and not bloated.- The FPGAish part can be programmed in verilog- It has also some analog capabilities (comparators, op-amps, mux, mixers, PGA, ADCs and DACs)- The provided IDE is decent both for the C and the schematic entry partsCons:- Cheap construction and packaging- No VHDL (well, for me that's one of the pros)- The proprietary IDE is more or less the only way to use it, and it's Windows only.If you want a FPGA only board, I have the older versionof this one, not bad for the price.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 25, 2018, 04:23:33 pm
content: IMHO, from the learning viewpoint, if you have time, it's better to get a grip and understanding on logic circuits, FPGAs, and HDL, and only then move to MCUs. This is because the MCUs are made mostly of logic circuits (both CPU and peripherals), and you will understand them better if you already know their inner workings. And the best way of moving from FPGA to MCU is to design a small soft core on FPGA.If you're more interested in practical side of things instead of learning, then get Zynq.Shortly after you graduate, the quantum computers will mature, or something of that sort will happen. Everything you do now will become obsolete. Keep that in mind when you choose things to do.

author: rstofer
author_rank: Super Contributor
timestamp: November 25, 2018, 04:39:20 pm
content: Embedded programming and hardware design with VHDL are worlds apart. In fact, they have essentially nothing in common.For embedded programming, I would start simple with the Arduino. Everything that can be built with an Arduino has been built and the projects are all over the internet. But Arduino programming is a long way from bare iron embedded programming. You can skip over all the Arduino libraries and get right down in the dirt. The only thing you want to save is the bootloader. You will be using the same IDE/toolchain, just omitting the library stuff. You will need to understand avr-gcc and avr-libc, both of which the Arduino system is already using.The STM boards are a big step up but there is a tendency to use the factory provided bloatware libraries. I haven't tried to get around this on STM boards. Then there is the original mbed LPC1768 board which is my personal favorite. You can get right down in the weeds with interrupt handlers and all the hardware gadgets. Getting the NVIC (interrupt controller) set up is an interesting learning experience. Stop by mbed.org. BTW, their toolchain works for many 'mbed compatible' STM boards. This allows use of the online toolchain (work on your project from any browser in the world) plus drag and drop device programming. There are mixed opinions on using this toolchain. I like it! If you're going to buy an STM board, it might as wel be 'mbed compatible' whether you intend to use those tools or not.OR...There's a project out in the Google-verse called LC3B (or the earlier version LC3) which is a hardware design project. The given state diagram can be coded up in VHDL (or whatever) to form a functional CPU with nothing more than an interrupt driven serial port. It has separate system and user privileges and while the instruction set is clearly RISC, there is a C compiler for the LC3 version. I don't know if it has been upgraded for the byte oriented LC3B. There is also an assembler for the LC3 version.This is a pretty nice project because first you build the CPU, then you add peripherals (PWM, more serial, <whatever>) then you write bare metal code in assembly language. In the end, you will have a pretty good handle on both hardware and embedded programming.There's a book: "Introduction to Computing Systems" by by Patt and Patel.I am having fun playing with the PSoC 6 and the video series with the end result of creating a robotic arm controlled by a cell phone. This is a most interesting way to create projects but 90% of the code is toolchain created. The entire infrastructure is provided, all you do is add a few lines of specific code. You'll see what I'm talking about. PSoC Creator is the toolchain.OR, if you like command line work, consider installing the AVR-GCC toolchain under Linux and using a simple editor (I use gedit) and connecting to a simple chip like the ATmega128. Now you're as close to the iron as you can get. I did quite a bit of work with this setup a long time back and I really enjoyed it. The '128 is a great chip with lots of peripherals and pins.http://maxembedded.com/2015/06/setting-up-avr-gcc-toolchain-on-linux-and-mac-os-x/https://www.mouser.com/ProductDetail/Olimex-Ltd/AVR-H128-Chttps://www.digikey.com/product-detail/en/olimex-ltd/AVR-ISP-MK2/1188-1008-ND/3471448As to the ICSP programmer, expect to have to play with udev rules to get the USB working under Linux. According to Google, it works just fine under Windows.What you are looking for is an ICSP programmer that will work with avr-dude.It's a pretty large sandbox, you need to decide where you want to play.

author: legacy
author_rank: Super Contributor
timestamp: November 25, 2018, 05:40:32 pm
content: Quote from: rstofer on November 25, 2018, 04:39:20 pmThe MIPS R2K is covered by the 99% of university courses since it is the first examination in computer science. Supported by H&P books, plus slides.

author: rstofer
author_rank: Super Contributor
timestamp: November 25, 2018, 06:22:01 pm
content: Quote from: legacy on November 25, 2018, 05:40:32 pmI don't know that I buy into the 99% considering the number of university references the LC3 on Google. Nevertheless, Hennessy and Patterson is required reading (and studying) for anybody who plans to go very far with hardware design.https://www.csl.cornell.edu/courses/ece4750/handouts/ece4750-T02-proc-uarch.pdfThis paper starts out simple and works through several iterations to get to a fully pipelined CPU - unlike LC3 where no attempt was made to optimize throughput.Due to the scaled nature of the processors in the paper above, it might be interesting to play with. However, the paper doesn't hand feed the information in the way that Patt & Patel do. I think it matters where you are coming from. If this is for a hobby and a person is just starting out with FPGAs, LC3 is much more approachable whereas R2K is a good deal more advanced.

author: rstofer
author_rank: Super Contributor
timestamp: November 25, 2018, 07:57:10 pm
content: If you like Pascal (which I do), take the output of Wirth's P4 compiler and create a stack machine in an FPGA to execute it directly rather than interpreting it as was done with the UCSD compiler. There are MANY advantages to interpreting stack code but speed isn't one of them. But it did make the system portable. All that was necessary to host Pascal was an interpreter for the given host and it wasn't all that complex.So, I basically got the CPU to work but I stumbled when it came time for system calls. I'm not working on the idea any longer but I think I would now just implement them as traps. It's really only the lowest level calls that are problematic. Everything else (OS and friends) would be written in Pascal. Exactly what was done for UCSD Pascal.Given the speed of the modern FPGA, it should be very easy to outrun the original P4 system on the CDC 6400 mainframe.

author: hamster_nz
author_rank: Super Contributor
timestamp: November 25, 2018, 09:34:48 pm
content: If you want an inexpensive ARM dev board that has a well documented learning path, the Texas Instruments Launchpad boards are reasonably good, and are used by this free edX course that will walk you though using it:https://www.edx.org/course/embedded-systems-shape-the-world-microcontroller-inputoutputIf you did want something more feature-rich, then the Cyress PSoC 5 kits are pretty compelling (and have some programmable logic hardware features):http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-andif you just want a microcontroller board for experimenting/learning/tinkering with in your spare time, then the ESP32 board might be of interest. They are inexpensive, have WiFi, and quite a few have battery management for a LiPo pack. The WEMOS boards are usually a good place top start:https://www.aliexpress.com/item/LOLIN-D32-Pro-V2-0-0-wifi-bluetooth-board-based-ESP-32-esp32-Rev1-ESP32-WROVER/32883116057.html

author: brucehoult
author_rank: Super Contributor
timestamp: November 26, 2018, 02:40:17 am
content: Quote from: avogadro on November 25, 2018, 01:05:15 pmTinyFPGA BX is on special at the moment for $28https://www.tindie.com/stores/tinyfpga/With 7680 LUT4s it's got a ton of space for anything you'd design yourself, and even enough to use maybe a third of it for a soft-core CPU (typically RISC-V such as PicoRV32) while still leaving room for your own circuits.It uses a fully-Open Source tool chain from Verilog or VDHL (or Chisel, or ...) to the bitstream. No obscure hard to set-up toolchains. No licenses to fight with.

author: rstofer
author_rank: Super Contributor
timestamp: November 26, 2018, 03:44:55 pm
content: Quote from: brucehoult on November 26, 2018, 02:40:17 amAt first I was thinking that 7680 LUT4s wasn't very much but it turns out that the LC3 RISC CPU project (all over Google) only takes 611 LUTs on an Artix 7, even with my sloppy approach to VHDL. LUTs don't always equal LUTs but, even so, the project would fit several times over.However, the TinyFPGA BX is limited on BlockRAM such that it can only implement 8k x 16b but that may be just fine for a learning project.

author: JackJones
author_rank: Regular Contributor
timestamp: November 26, 2018, 04:11:36 pm
content: I know this isn't ARM, but here's an excellent basic tutorial for PICs:https://www.gooligum.com.au/PIC-tutorials/baseline-PIC-tutorialIt might be worth a read through even if you don't want to use PICs. It explains the most basic things very clearly.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 26, 2018, 06:11:47 pm
content: Quote from: rstofer on November 26, 2018, 03:44:55 pmYes, not always equal. Artix-7's LUTs are 6-input LUTs, each of which is roughly equivalent to four 4-input LUTs, not to mention their flexibility - they can be converted to memory or to shift registers. Also Artix-7 has other things such as muxes and carry chains, which don't count as used LUTs but they do help.

author: shangaoren
author_rank: Regular Contributor
timestamp: November 26, 2018, 06:32:34 pm
content: I'm working with cortex M4 every day, i think you shouldn't try to mix FPGAs and microcontrollers at the beginning, it will be too much complex.If you want to know how Arm Cortex works you can read "the definitive guide to Arm cortex-m3 and cortex-m4" by joseph yiu, this book explain very well how the core works.If you plan to work in electronics i suggest you to avoid arduino, this is an easy plateform to create some things but many of microcontrolers useful features are not used (DMA, Interrupts) as far as i know.The cheapest Arm boards i know are ST's Nucleos, you just have everything to start on board for about 20 bucks for the biggest chips, and ST's documentation is not bad.

author: rstofer
author_rank: Super Contributor
timestamp: November 26, 2018, 07:32:10 pm
content: Quote from: shangaoren on November 26, 2018, 06:32:34 pmAbsolutely correct. The budding engineer or hobbyist needs to decide whether they want to create hardware or software (firmware, I suppose). There's a huge difference!QuoteThe ATmega328 is not a very sophisticated chip but it is adequate for a number of projects, with or without the Arduino infrastructure. Any of the ATmegas will be more approachable than an ARM for the beginner. That the ATmegas lack the sophistication of the 'be-all, do-all' ARMs is a blessing, not a curse.I started playing with ARMs using the ARM7-TDMI chips like the LPC2148 and LPC2106. There was a sense of 'bare iron' because the only given file was 'startup.S' and it was pretty much a skeleton when it came to the interrupt handlers and such. It was a great introduction. The LPC2148, especially, is a great chip. The 'stamp' form factor of some LPC2106 boards make it easy to plug into a daughter card.As I see the STM boards and even the PSoCs, the amount of tool generated code once again takes the programmer away from bare iron. It's debatable whether this is good or bad and that debate revolves around whether the developer wants a project complete in a hurry or whether they are on a training mission. In the case of the PSoCs, the tool generated code is pretty comprehensive, leaving the programmer to just add a few lines to get an app to work.In the middle is where I see the LPC1768 mbed. There are libraries for things like TCP/IP (and that's a good thing!) but you can still get down in the dirt with things like the NVIC and interrupt driven SPI slave. That's also a good thing.But the original question is "where to start" and there's no more fully documented platform than Arduino and there is no easier platform to get started with. There's time later to take on more complex chips or even take a complete left turn and play with FPGAs.My only interest, really, is hardware design. I like playing with FPGAs. Still, playing with the PSoC 6 has been quite a lot of fun. Today? I'm playing with an Arduino for temperature controller experiments.http://apmonitor.com/pdc/index.php/Main/ArduinoTemperatureControl

author: HB9EVI
author_rank: Frequent Contributor
timestamp: November 26, 2018, 08:04:41 pm
content: Quote from: rstofer on November 26, 2018, 07:32:10 pm+1Imho it's an ideal mcu prototype for many (but certainly not all) purposes; compared to the PICs, the smaller diversity in the AVR family makes it much easier to choose the right for a particular project; and compared to ARM, the less complex hardware offers less pitfalls and makes a start into programming much smootherit's hard to say, if to recommend ARM or AVR for start into embedded; my sole advise would be to never get attached to Arduino, HALs or whatever crippled library set

author: shangaoren
author_rank: Regular Contributor
timestamp: November 26, 2018, 08:25:17 pm
content: HAL for ST's, i don't know for others, is crap it's just good to make a proof of concept but not a definitive code.Bare Registers can be scary but the names are pretty clear and documentation is readable, you don't have to fear of them.I began with PICs but i feel more confortable with ARM architecture and peripherals, but maybe it's the experience

author: langwadt
author_rank: Super Contributor
timestamp: November 26, 2018, 08:42:37 pm
content: Quote from: rstofer on November 26, 2018, 07:32:10 pmthere is not thing that forces you to use tool generated code for STM if you are felling masochistic you can program it in assembler using notepad and the usermanualisn't MBED that "internet of things" buzzword powered browser only abomination ?

author: rstofer
author_rank: Super Contributor
timestamp: November 26, 2018, 08:46:37 pm
content: Quote from: shangaoren on November 26, 2018, 08:25:17 pmYes, but you started with PICs (I played with them years ago), not ARM. And that's the point! For a beginner, the ARM can be a stretch. Not that I would wish the mid-range PIC on my worst enemy.I like the AVR architecture, I like the infrastructure (avr-gcc, avr-dude, avr-libc) and I really like the ATmega128. And I can get along with the ATmega328 as used in Arduinos.The question at hand is "where to start" and maybe ARM isn't it.

author: rstofer
author_rank: Super Contributor
timestamp: November 26, 2018, 08:59:14 pm
content: Quote from: langwadt on November 26, 2018, 08:42:37 pmI guess that would be one way of looking at it! OTOH, I like the 'stamp' form factor of the original LPC1768 because I can plug it into a daughtercard with a MagJack and have networking in a heartbeat.The great misunderstanding is the 'browser only' bit. That is a nice feature if you want to be able to work from anywhere in the world, using anything with a browser. But it isn't required!You can download the libraries and use them with Rowley CrossWorks for example. In fact, you can use them with arm-gcc of any flavor. Or you can write to the bare iron. What is important is the 'drag and drop' programming of the device. That's just neat!The flip side is also true of the mbed model. I can develop code on any toolchain that will compile to a binary image. Then I download the image via USB to the board and I'm up and running.It is curious to see 'abomination' used when STM is doing everything in their power to accommodate the idea by making their boards 'mbed compatible'. I was happy with the arrangement long before STM got involved.I was even happier before ARM bought out the operation. I don't know if it lives or dies depending on the mood of ARM at some point in time. Independence was a good thing. OTOH, financing is another good thing.I have toolchains on multiple machines all over my office. Sometimes Linux, sometimes Windows 7, sometimes Windows 10, I don't care which. I don't much care how many different tools are required or how much horsepower they take to run. It all works out. But I still like the online approach! I don't have to install or maintain anything. That's all taken care of by others.

author: HB9EVI
author_rank: Frequent Contributor
timestamp: November 26, 2018, 09:14:40 pm
content: Maybe ARM isn't it... after using AVR for a long time, it was a challenge getting into STM32 the bare metal waysuccess that way likely depends how stubburn and frustration resistant someone isafter being familiar with STM32F1, I newly had to break my head and rewrite functions for I2C on STM32F0 - I didn't try yet other ARM, but ST doesn't make the things easierwouldn't recommend any mid range PICs to anybody either

author: rstofer
author_rank: Super Contributor
timestamp: November 26, 2018, 11:10:30 pm
content: Quote from: HB9EVI on November 26, 2018, 09:14:40 pmMore than any other trait, stubborn is the most important to get anywhere in this field. The chips don't work (read the errata, you'll see!), the documentation sucks, the sample code is bloatware and totally obtuse, and the list goes on...In the end, only stubborn gets it done!Sometimes even the simplest things take an inordinate amount of time. You just have to keep beating on things until they work.

author: Bassman59
author_rank: Super Contributor
timestamp: November 27, 2018, 07:47:10 pm
content: Quote from: rstofer on November 26, 2018, 11:10:30 pmYou forgot:"Vendor tech support is worthless."

author: nctnico
author_rank: Super Contributor
timestamp: November 27, 2018, 09:16:06 pm
content: Quote from: HB9EVI on November 26, 2018, 09:14:40 pmThat is your punishment for buying the cheap crap everyone is using. The LPC series ARM controllers from NXP are much easier to use. And since the peripherals are 99% the same across the entire range you don't need to rewrite stuff you already wrote.

author: rstofer
author_rank: Super Contributor
timestamp: November 27, 2018, 09:23:43 pm
content: Quote from: nctnico on November 27, 2018, 09:16:06 pmI LIKE the LPC series. The device drivers are easy to write, NXP produces good documentation and there are library archives all over the place.If somebody was going to use something like the NXP LPC2148, I would direct them to the superb code atwww.jcwren.com/armYes, the code is long in the tooth but so is the chip. I have several development boards from Olimex.The LPC2106 in stamp form factor was the basis of a music player I built as a demo. The codec was connected to the 2106 as was an ethernet gadget. The 2106 would make a connection to my music library on a Linux box (NFS as I recall), grab the MP3 file and play it. There was quite a bit going on in the code so it was a great learning project.Super easy to program with ICSP or JTAG and I was writing the code on a Linux box with arm-gcc and gedit. Good times!

author: nardev
author_rank: Unknown
timestamp: November 27, 2018, 09:27:59 pm
content: @avogadro ako te zanima, ja imam neku Spartan E3 platformu, mislim da je skoro povucena ali je jako jako dobra za FPGA. Ima dosta periferije dodane.Javi se, mozda da se nekako dogovorimo. LP

author: avogadro
author_rank: Contributor
timestamp: November 28, 2018, 07:45:34 pm
content: QuoteYeah this is something I would be really interested in doing. Where do I start though? Just reading trough the book you posted or that H&P book? What about that MIPS R2K?

author: rstofer
author_rank: Super Contributor
timestamp: November 28, 2018, 09:17:21 pm
content: Quote from: avogadro on November 28, 2018, 07:45:34 pmThere are going to be a lot of opinions on this. Here's mine: KISS - Keep It Simple Stupid. I like Patt and Patel because they start from the very simple basics of logic gates and work up through an entire CPU with a lot of Computer Science kinds of things mixed in. Fact is, they don't even begin to talk about the CPU until Appendix A and it's in Appendix C (which you can find separately on the Internet) that they even start getting into design.They give you the hardware diagram, some hardware descriptions of the control and data paths and, ultimately, a table to fill out to create microcode (which I didn't use). They give you a diagram of the COMPLETE state diagram - just convert it to microcode or VHDL. The information is more than sufficient.Here is Appendix C:http://people.cs.georgetown.edu/~squier/Teaching/HardwareFundamentals/LC3-trunk/docs/LC3-uArch-PPappendC.pdfThere dozens of videos about LC3 - just Google for 'LC3 video'. These may be an enormous help getting started.Read through it and see if it makes any sense at all. Then read through it a couple of times to let it sink in. What data is moving where? Which MUX input is being selected when? When you catch on, it's really kind of simple. I suppose it is simpler if it isn't your first rodeo...There are things you need to know how to write in VHDL. Most important is the Finite State Machine. The entire CPU is one gigantic FSM with some supporting processes around the outside. There is also a serial port which connects to a PC terminal emulator like PuTTY. You are going to subscribe to OpenCores.org and grab a serial core. Just connect up some signals and you're good to go.Here is just a wee bit of the FSM:Code:case State iswhen 0 => -- Branch Instructionif BEN = '1' thenNextState <= 22; -- branch is takenelseNextState <= 18; -- branch not takenend if;when 1 => -- ADD Instructionif Immediate = '1' thenSR2select <= Sext5sel;elseSR2select <= SR2outSel;end if;ALUop <= ALUadd;GateBusSelect <= GateALU;LD_Reg <= '1';LD_CC <= '1';NextState <= 18;when 2 => -- LD InstructionAddr1Select <= Addr1PC;Addr2Select <= Addr2Sext9;MARselect <= MARadder;GateBusSelect <= GateMARmux;LD_MAR <= '1';NextState <= 25;Look how closely this matches the transition diagram. I didn't invent the thing, I just copied from the diagram, substituting names here and there.The microcode approach won't require nearly as much code but it will be much more obscure. Particularly when making tests that result in different state transitions. I would like to use this approach some time, I like the concept of a reconfigurable processor.The main code is right at 1000 lines plus several support files which vary from 40 to 100 lines. Nothing significant.I'm not going to say the project is trivial or even easy. Starting from ground zero, it's a lot of learning. Start by reading through the Appendix and then asking questions. FWIW, I built mine in a large Artix 7. The main selection criteria is that it have enough BlockRAM to support 64k by 16b words. This isn't a hard requirement but it does provide the maximum memory.Why not start with the RISC-V? It's darn difficult to build pipelined machines. There are some great projects out there, I was reading through the TinyRV1 yesterday. Breaking a CPU down into stages is pretty easy, accounting for the hazards like an instruction using a result that is still in the pipeline makes it really complex.https://www.csl.cornell.edu/courses/ece4750/handouts/ece4750-T02-proc-uarch.pdfFor a first project, LC3 is more than enough. The nice thing about it is that it has no predefined IO. You can add whatever you like. So, when you want to build a gadget, just plunk in an LC3 core and you have the processor. Add widgets as required...Here is the book with CD. Make sure you get the CD if you buy a used book!https://www.amazon.com/Introduction-Computing-Systems-Gates-Beyond/dp/0072467509Alibris has many copies of the previous version - I wouldn't go there just to save $30There may be enough information on the Interwebs to make buying the book redundant.

author: rstofer
author_rank: Super Contributor
timestamp: November 28, 2018, 09:41:54 pm
content: The obvious question after the CPU does something useful is "How do I use this thing?". Good question...When I designed the BlockRAM, I used some code by hamster_nz (a FREQUENT contributor and FPGA wizard!) to allow the system to preconfigure the BlockRAM such that the code image was loaded when the FPGA started up. But that means you need to re-run the Vivado tool to make updates. That's a PITA!So, we need to go back 40 years or so. Say to around '76 or thereabouts. The 8080 machines had the same problem: How to load an image. We wrote programs called 'monitors'. These are teletype interactive programs that would allow us to load and save images from paper tape and later audio tape and, ultimately, disks. You write the monitor program to allow for load/save as well as various debugging operations. THIS is the code you put in the FPGA at startup. You reserve enough memory space for this. It might be the upper 2 or 3k of RAM. Then you tell the C compiler to avoid this high memory. You also force a branch instruction at address 0x0000 or you design the CPU to start from the monitor address. In any event, the monitor is the first thing that gets run.From here, it is a simple matter to load and save programs via the Teletype (RS232) interface by way of a program like PuTTY.Here is a simple 8080 monitor program written in assembly language for the 8080. Not entirely on point but the ideas are correct:https://github.com/jefftranter/8080/tree/master/asm/monitorLater, after you add a compact flash and some variation on the CP/M operating system which you will have the joy of writing (but in C, not assembly language), you will just put the BIOS in high RAM and a branch in address 0x0000. Just like we did it way back when!In the end, this is a post-graduate course in system design. From blinking an LED to a full blown computer in several steps.