RP2040 - Bare Metal Interrupts and Debugging - BMA08

Поділитися
Вставка
  • Опубліковано 25 сер 2024

КОМЕНТАРІ • 16

  • @deanbell5164
    @deanbell5164 10 місяців тому +1

    Your comments in the intro takes me back to the late 70's with the MC6800 and assembler code 🙂

    • @LifewithDavid1
      @LifewithDavid1  10 місяців тому

      Those were great times. Mine was with the 6502 and machine language. Thanks for watching!

  • @sapiosuicide1552
    @sapiosuicide1552 9 місяців тому

    Ah yes the classic "toggle a gpio line at a certain point in your program to tell where it's executing" trick
    I really like doing this in combination with my oscilloscope. I'll have it do a single high then low pulse at the start of my function, and then 2 pulses at the end to measure the clock cycles between events

    • @LifewithDavid1
      @LifewithDavid1  9 місяців тому

      I love it when signals do what they are supposed to do!. I miss the "blinkin' lights" of the old computers. Thanks for the comments!

  • @benarcher372
    @benarcher372 10 місяців тому

    This so satisfying!

    • @LifewithDavid1
      @LifewithDavid1  10 місяців тому +1

      Thank you! That's why I'm hooked. Thanks for watching!

  • @sveinarsandvin6418
    @sveinarsandvin6418 10 місяців тому

    Brilliant.

    • @LifewithDavid1
      @LifewithDavid1  10 місяців тому

      Thank you. I hope it helps get more people involved in assembly language programming.

  • @benholroyd5221
    @benholroyd5221 10 місяців тому

    6:10
    Bl is a 32 bit instruction with a 23 bit relative address so you jump ~16mb forward or back. So you can jump around xip or ram.
    Rom has pointers in the first few bytes though.

    • @LifewithDavid1
      @LifewithDavid1  10 місяців тому

      Thanks for the comment. You are correct, you can jump around inside SRAM or XIP with BL. However, the start of XIP and SRAM is 256MB apart, which means you can't jump between SRAM and XIP without a few more gyrations.

  • @benholroyd5221
    @benholroyd5221 8 місяців тому

    Im a bit confused about the clearing of interrupts. you don't seem to be doing it here? although you have a comment
    // clear the Uart receive interrupt
    Also have you got any pointers (ha) to what happens with the MSP and PSP. as I understand it when an interrupt is called the stack is switched to the MSP, but I havent found anything on switching back. does this happen automatically when you move the LR to the PC?

    • @LifewithDavid1
      @LifewithDavid1  8 місяців тому

      Interrupts can be complicated. NVIC helps simplify the process for most "normal" uses. NVIC controls when an interrupt is pending or active. I believe the act of pushing the exception return value converts the interrupt from pending to active. This means that another hit on the SAME interrupt will trigger a pending interrupt for the same ISR to be run after the current ISR is completed. This is where priorities come in; which interrupts trump other ones? When the exception return value is popped; the interrupt goes from active to cleared and the next pending interrupt (if any) as determined by NVIC will be processed. Sections 4.2 and 4.3 of the Cortex M0+ Generic User Guide have a lot more info if you want to get into the weeds. This is the "creative" part I talked about for more complicated interrupt schemes.
      Regarding MSP and PSP, that depends which stack you were using at the time of the interrupt. I believe you can change to a PSP for certain routines (I'm not quite there yet in my learning). The exception return value memorializes if you were using the main stack pointer (MSP) or the process stack pointer (PSP) before the interrupt was thrown, and then returns you to that stack when the value is popped. Thanks for the question; I hope this helps.

  • @bitogre
    @bitogre 10 місяців тому

    Your claim that you cannot use interrupts and FIFO buffers at the same time is incorrect. The difference is that the interrupt fires with the FIFO buffer has a given number of byte received. Unfortunately, the smallest number of bytes to trigger the interrupt is 1/8 of the FIFO (4 bytes) so, while the statement is incorrect, your code is probably the best for slow transfer rates and cases where you need response on a single byte. But I can see it having problems if you copy text into the terminal or have other faster data input where the data is coming in faster than you can process each interrupt, one byte at a time (the overhead of entering/exiting interrupts can be problematic in some cases).

    • @LifewithDavid1
      @LifewithDavid1  10 місяців тому

      You are absolutely right, you can fire an interrupt based on the trigger amount. This a debug process; after the program is running well you can enable the fifos again (note the "either or" code) and get rid of the troubleshooting code. Thanks for the comment!

  • @rasiawillmott9250
    @rasiawillmott9250 8 місяців тому

    😣 P R O M O S M

    • @LifewithDavid1
      @LifewithDavid1  8 місяців тому

      I guess promoting you're own channel is a way to get more clicks. That's what the broadcast networks do. I'm not into this for revenue (duh...I'm getting about $0.25 per hour right now). I just hope more people find that bare metal programming can be fun (maybe I AM a little warped ;-) ).