ATtiny13A TIL

[lkoepsel]

Today I learned
I wanted to try using chip from bare IC and one which could provide a minimal, however, versatile clock and chip I/O. Part of this desire was to gain a greater familiarity with gdb and Bloom as well as using the Raspberry PI for remote development. The experience has been great!

Some hints:
1.) Don't trust AI on simple datasheet information. Even with Claude 4, it had massive errors in things as simple as pinouts, such as swapping the MOSI pin for the MISO pin.
2. Even though you're going to want to use debugWire as it only consumes 1 pin, you will need to wire the chip using ISP. Then just let Bloom do its thing.
3. Sometimes, it helps to use avrdude -p attiny13A -P usb -c atmelice_isp -t just to confirm the part, configuration etc.
4. I'm using headless Bloom so I miss Insight, which is phenomenal, however, its like all GUI's. Once you've mastered the text commands, you don't miss it. (Insight is still phenomenal, just not available, headless.)
5. The new text registers commands such as ``mon rrandmon wr``` are fantastic and the reason why Insight isn't as necessary. I was setting up the timer clock on the ATtiny13A and it was great to be able to do this, to confirm my parameters:

(gdb) mon rr tc0
Reading "TC0" peripheral registers...

`tc0`, `gtccr`, "GTCCR", 0x00000048, 8-bit | 0x00 (0, 0b00000000), PSR10: 0b0, TSM: 0b0
`tc0`, `ocr0b`, "OCR0B", 0x00000049, 8-bit | 0x00 (0, 0b00000000)
`tc0`, `tccr0a`, "TCCR0A", 0x0000004F, 8-bit | 0x02 (2, 0b00000010), WGM0: 0b10, COM0B: 0b00, COM0A: 0b00
`tc0`, `tcnt0`, "TCNT0", 0x00000052, 8-bit | 0x6A (106, 0b01101010)
`tc0`, `tccr0b`, "TCCR0B", 0x00000053, 8-bit | 0x0A (10, 0b00001010), CS0: 0b010, WGM02: 0b1, FOC0B: 0b0, FOC0A: 0b0
`tc0`, `ocr0a`, "OCR0A", 0x00000056, 8-bit | 0x9A (154, 0b10011010)
`tc0`, `tifr0`, "TIFR0", 0x00000058, 8-bit | 0x08 (8, 0b00001000), TOV0: 0b0, OCF0A: 0b0, OCF0B: 0b1
`tc0`, `timsk0`, "TIMSK0", 0x00000059, 8-bit | 0x04 (4, 0b00000100), TOIE0: 0b0, OCIE0A: 0b1, OCIE0B: 0b0

It's unfortunate, the colors can't be represented on this entry. The display is lovely.

My setup is:

• Macbook Pro as my development computer
• Raspberry Pi 5 connected to remotely to enable using Bloom (I've tested with a Raspberry Pi 4, no issues) Its the GUI which will slow you to a crawl.
• ATMEL ICE as my programmer and debugWire interface

Thank you again for Bloom it is a joy to use.
Lief

[navnavnav]

Hey Lief,

Glad you're finding the new register access commands helpful. I use them to manage peripherals during debug sessions, which can be really helpful at times (for example, I often need to turn on/off a timer in between stepping). I touch on this in the following article: https://bloom.oscillate.io/docs/debugging-wch-riscv#accessing-peripherals. The examples are specific to a WCH RISC-V target, but most of it can be applied to AVR targets.

I'm using headless Bloom so I miss Insight

Just FYI: in case you or your students ever want to use an IDE with headless Bloom, you should be able to access peripheral registers via the IDE, using an SVD file (assuming your IDE provides such functionality).

You can generate an SVD file via the relevant target details page on the Bloom website:

Then pass that to your IDE, which should then allow you to access peripheral registers via a GUI.

In CLion, you can supply an SVD via the "Peripherals" pane:

Then CLion will automatically read register values and display them in the pane, as well as provide the ability to write to the registers and individual bit fields:

That's how CLion does it. I'm sure the other popular IDEs do something similar with SVD files.

So that's just another way you can access peripheral registers in the absence of the Insight GUI.

[lkoepsel]

Yes, i see the method of using an SVD, and your page on the ATtiny13A was very helpful to get me started. I used it to ensure I had the right information (along with the datasheet).

I've been using mon rr tc0 and mon wr tco ocr0a all day to ensure I'm getting the right clock cycle, frankly, using it inside of gdb, i've no interest in pursing additional methods. I like using the CLI as I know it will always be there and the mon commands you added in 2.0 are dead simple. And without TUI, look great!

I've got my gdbinit setup, so that td disables and te enables (TUI) so its very easy to go back and forth.

[lkoepsel]

BTW - I wanted to add this very important point. I loaded a Raspberry Pi 3 with 2GB memory with the full tool chain along with gdb and Bloom. I don't notice any significant difference in CLI response than what I have with a Raspberry Pi 5 8GB.

Which is fantastic! This means, it's not the power of the processor which matters, its the ingenity of the software.

It also means i can recommend the Pi3 to my students as a very capable, embedded computer development system.

Note: I might have to have them install an Arch Linux or something other than Bookworm, for Debian's gcc tools seem to be stuck at version 5 or 7.

[navnavnav]

i've no interest in pursing additional methods.

Fair enough 👍🏽

I don't notice any significant difference in CLI response than what I have with a Raspberry Pi 5 8GB

That's good to hear. I've only tested the headless build on a Pi 4, so good to know it works on an older version.

I might have to have them install an Arch Linux or something other than Bookworm

Hmm, I wonder how difficult it would be to install Arch on a Pi. Also, keep in mind that I don't currently provide an Arch Linux package for aarch64. I only provide Arch Linux packages for x86_64.

In a slightly unrelated topic, I'm curious to know if you've noticed a difference in programming speeds, when using GDB's load command?
I introduced delta programming in version 2.0.0, where Bloom compares the new program with the contents of its program memory cache, and then uploads only the differing segments. For small changes to the program binary, this can reduce programming times dramatically.
But to experience this, you have to invoke the load command multiple times in the same debug session (as the program memory cache won't be populated on the first time). And your code changes must result in small changes to the program binary, which isn't all that common. So it's very possible that you would not have noticed this, if you're only programming the target once per debug session, or if you're making changes to the code that result in large changes to the program binary.

[lkoepsel]

1. As a matter of fact, yes i have noticed a difference. When I was working on a clock issue, i'd make small changes to the code then load-mon reset-c. At the time, I hadn't noticed how short it was until I had to load a much larger program in a different scenario. The continuous changes were very fast, and the large program was slow enough to make me think I hadn't pressed return. So yes, its a great feature.
2. Yeah, don't worry about Arch Linux on the Raspberry Pi, its not easy to load a version on the Pi, headless. Not something I want to spend a lot of time on...
3. Building the latest gcc on a Pi5 is pretty fast, my concern is building it on a Pi3 would be glacierly, if at all.
4. I'll do some testing of a stock Bookworm image on 3 to make sure everything works, despite the down level code.