I am planning to start with a fresh vision and prepare a comprehensive learning plan document for embedded systems that I aim to execute in new year. I am working on creating a roadmap that covers practical aspects of embedded systems. I would greatly appreciate it if you could share your valuable feedback and suggestions to help me refine this plan and make it more effective.

Here’s an overview of the tasks I have planned so far:

• Oscillator Configuration
  • Internal Oscillator:
    • Set up the internal oscillator to the desired frequency and blink the LED every second.
  • External Oscillator:
    • Configure the external oscillator to the desired frequency and Blink the LED every second.
• Timer Configuration
  • Use various timer modules to blink the LED at 1-second intervals.
• Interrupts
  • Timer Interrupt:
    • Set up the timer interrupt to control the LED at every timer interrupt.
  • Hardware Interrupt:
    • Set up a hardware interrupt (e.g., button press) to toggle the LED.
• LCD Interfacing
  • Interface the LCD in:
    • 4-bit mode.
    • 8-bit mode.
• Data Communication
  • PC Communication:
    • microcontroller to send voltage measurement data to a PC.
  • I2C Communication:
    • Interface with an RTC (Real-Time Clock) module using I2C protocol.
  • CAN Communication:
    • Implement Controller Area Network (CAN) communication to transmit and receive message
  • Modbus Communication:
    • Configure Modbus communication for data exchange.

I would greatly appreciate your valuable feedback, opinions, and suggestions on refining this document plan. Are there any additional tasks or topics you think I should include? Or best practices index you would recommend?

 

Don't forget SPI for Data Communications. You can interface external devices (some LCDs can use SPI interfaces) with SPI at up to 16 MHz (64 MHz FOSC) with modern 8-bit controllers. (even faster with 32-bit controllers)

 

What microcontroller are you going to use? Do you have an oscilloscope or logic analyser? I did something similar with the ATtiny85 to learn how to use most of its hardware peripherals. I'd have been less informed of a lot of details without using an oscilloscope (cheapest Picoscope). The scope's I2C decoding was a real benefit in understanding what was going on with I2C

 

Don't forget SPI for Data Communications. You can interface external devices (some LCDs can use SPI interfaces) with SPI at up to 16 MHz (64 MHz FOSC) with modern 8-bit controllers. (even faster with 32-bit controllers)

I’ll add SPI-based tasks to my plan to gain hands-on experience

What microcontroller are you going to use? Do you have an oscilloscope or logic analyser? I did something similar with the ATtiny85 to learn how to use most of its hardware peripherals.

I am using the PIC18F45K22 microcontroller for this learning plan. Unfortunately, I don’t have an oscilloscope or a logic analyzer

 

What would you recommend managing documentation for these kinds of activities?

Would an Excel sheet be better to track progress and maintain a structured , timelines, and outcomes? Or MS Word files would be more suitable for documenting code snippets, observations, and learnings?

 

What would you recommend managing documentation for these kinds of activities?

Would an Excel sheet be better to track progress and maintain a structured , timelines, and outcomes? Or MS Word files would be more suitable for documenting code snippets, observations, and learnings?

I use MS Word files to keep a log book. I sometimes use an Excel sheet to record results and link to it from the Word doc, or put a screen snip of it in the Word doc.

Edit: Attached sample log book covering the work I did to get familiar with ATtiny85 programming. I still find this useful after a few years, when I occasionally need to do some ATtiny85 programming. I usually convert the docx to pdf before posting for others to read.

 

I dare to say that your learning should be accompanied always by a simple project that involves the functions in your list. That's what I did from the beginning and it worked perfectly for me.

Math routines were evaluated in parallel with my learning to the point I ended writing my own libraries (used intensively since then).

 

What would you recommend managing documentation for these kinds of activities?

Would an Excel sheet be better to track progress and maintain a structured , timelines, and outcomes? Or MS Word files would be more suitable for documenting code snippets, observations, and learnings?

You might find Milanote suits you. They pitch it to “creatives” but it is really just a mind-mapper combined with a sort of database functionality. It is very visual but can export flat documents in a variety of formats. They use a subscription model, but there is a free tier which is full-featured and only limits the total number of notes. It may be enough for your application, but it certainly let‘s you see if the subscription is worth trying.

The other possibility in the same vein is Obsidian, which is free and open source. Unlimited personal use is free, commercial licenses are $50/year. They also offer some cloud sync services for a few dollars a month billed annually. None of this is required, though, and you don’t even need an account to download and use it.

It uses markdown for formatting which is fast and powerful and doesn’t have much of a learning curve. The high-powered nature of Obsidian is also a potential problem. It is a double-edged sword because of the extra effort in learning the software. It can be worth the trouble, but that’s up to you to decide.

Milanote is “friendlier” but not as powerful and does have limits if you don’t pay; Obsidian is more powerful in the end, but that comes at the cost of learning curve steepness but also has no limits for free users. Both beat spreadsheets and word processors for note taking because the allow connections among notes and documents that make your data collection far more powerful.

Good luck!

 

Thank you for your many suggestions . My current documentation approach is quite straightforward, but I feel it could be more meaningful. I’m thinking of structuring my documentation in a format like this:

1. Flash an LED in the main loop.
2. Detect an input (using polling in the main loop, no interrupt) to toggle the LED.
3. Use a timer interrupt to flash the LED.

Do you think this format is effective, or would you suggest another way to make it more structured and informative?

 

I would greatly appreciate your valuable feedback, opinions, and suggestions on refining this document plan. Are there any additional tasks or topics you think I should include? Or best practices index you would recommend?

You could also look at the TM1637 module interface , similar to I2C format, the IC's 7 segment displays are available with two-wire interface.
Also a few descriptions & videos out there !


e,g AMAZON



Also feeding strip of LED's in slow fade-in, Fade-out, for e.g. !
Which could take you into PWM Programming.