Hacker News Reader

Comment by meekrohprocess | Hacker News Reader

Nice. The XTensa cores always felt weird.

Too bad they only included the I/M/C extensions - no floats, vectors, or atomics. And USB would be nice (nevermind, it has USB :D).

But it's still very exciting. Maybe there'll be less conflict between ARM/XTensa/PIC32/etc. cores in the coming years.

View on HN

> And USB would be nice.

The block diagram show "USB Device" in the peripherals block.

Oh yeah, cool - I missed that.

Finally! An Espressif chip with WiFi, Bluetooth, and USB!

Note that the USB device is not a full-function software-controllable device; it provides a built-in 'serial port' and JTAG debugger only.

I believe the problem was XTensas not being available in hard macros, or at least Chen will not sell them at a price point a mortal can afford.

That's a huge thing when power efficiency, and operation from battery mattered.

Having a RISC-V based ESP also means it should be easy to add support in Renode [1].

[1]https://renode.io/

Why do you need atomics on a single core device?

There are ESP32 variants with a dual-core Xtensa processor (https://en.wikipedia.org/wiki/ESP32).

Interrupts and exceptions can happen at any point in a program's execution on a microcontroller, and they are free to modify memory and peripheral registers.

>Load <register>

>Modify register in memory

>>Interrupt happens and changes <register>

>Write incorrect value back to <register>.

These sorts of bugs can be pernicious to debug, and they are easy for novice developers to create.

That's horrifying. What is the fix/mitigation if you don't have proper atomics? I can't see how to properly avoid that.

Obviously interrupt code can't clobber registers like that, any shared register the ISR needs to share with ordinary code must be saved/restored on entry/exit somehow.

I think GP is talking about MMIO or some device register rather than the CPU’s register file.

You implement higher-level abstractions like mutexes. On a single core device this could be as simple as masking interrupts. You can use the mutexes to avoid the described race.

Only communicate in one direction. I write, you read. I can also provide a large coherent set of data so long as you dont read it until I mark it as ready. There are many other ways too.

You just guard those sequences by disabling and reenabling interrupts around them. It's a very common pattern in systems not designed for SMP.

You can disable interrupts when modifying locking primitives, and save/restore the CPU context when interrupts are entered/exited. You can also minimize the amount of changes that any interrupt handler can make within the interrupt context.

It's not really that bad, and plenty of microcontrollers lack atomic operations.

If you disable the interrupts, does that mean any incoming events get ignored, or simply queued for later? If the former, that sounds like you risk missing something important.

Queued for later.

Obviously with a certain max depth, most probably of 1, meaning you're still missing repeated interrupts.

The critical section is typically very small, usually just modifying a single variable. Interrupts can't happen faster than the CPU frequency anyway, so you won't miss much.

Sure, although I think "missing" has negative connotations that don't actually apply to this. When unmasked, your interrupt handler usually just runs until there is no more work to do, which is (again, usually) discoverable. Your device driver is still awoken promptly if the interrupt arrived during a critical section.

You disable interrupts for the three instructions it takes to emulate the atomic instruction. Which is barely slower than the atomic instruction would be anyway, because both have to read and write RAM, which is the slow part whether it's one micro-sequenced instruction or several standard ones.

Because you are likely still running a preemptive multitasking operating system.

Reply on news.ycombinator.com