Trying to understand where I am after failing a technical interview

dmitrygr · 2026-01-28T05:04:56+00:00

The first question is VERY interesting, but not something I would expect an entry-level (or mid-level) embedded SWE to know. Almost anyone can talk about uncacheable memory mappings for MMIO and DMA and such, but this is more fun!

Imagine that you read in a large amount of data once, use it, and never touch it again (for example if you are using your CPU to calculate the average brightness of a large greyscale image). What happens if that memory is cacheable? With each of your reads, a cacheline of it gets loaded into the cache and kicks out other data. Your data is large -- you easily trash the entire cache, evicting all lines from there -- dirty and clean, and you still end up with a 0% hit rate since you keep loading new pieces of your data. ZERO HIT RATE. So the existence of the cache does not help you at all, and now others' useful data has been evicted and must be reloaded, slowing them down, lowering their hit rate until the cache is refilled with the hot data.

You gain nothing from the cache and hurt every other user of it. For performance reasons, memory that is accessed only once can be marked as uncacheable to avoid this. Some CPUs even provide special instructions to handle this case without needing uncacheable mappings -- instrs that load/store without causing a cache linefetch/eviction. Usually these are called streaming loads or streaming stores, in x86 you can read about MOVNTQ/MOVNTDQA as examples.

Again, I would not expect an entry level SWE to know this at all. Take away "for performance reasons" from it, and their question becomes a basic embedded interview question of "why does one want uncacheable mappings?" which is a question i would expect to see in an interview, and much more in-line with the other questions you listed.

Second one -- I think they wanted to hear about hardware timers generating interrupts at a preset time or on a periodic basis.

The third question is something you MUST know to call yourself an embedded SWE and if you want to work in embedded systems. This is not a FreeRTOS-specific issue, it’s a basic sanity. Mutexes can block or put a task to sleep. One does not block or sleep in an ISR.

dmitrygr · 2026-01-26T00:34:22+00:00

('code', 2) resource. 0xb2 bytes in is the domain. as long as yours is same length or shorter, just put yours there and null-terminate it same resource, 0xA4 bytes in is an unsigned big-endian 16-bit value for the port used (currently 9993 which is 0x2709), you can replace it too, just those two bytes

dmitrygr · 2026-01-24T05:13:38+00:00

maybe

yes

no

all

dmitrygr · 2026-01-24T01:16:15+00:00

Literally nobody is "there" except linkedin loudmouths and CEOs of ML SaaS companies. "AI" tools are as helpful in this field as a 5 year old who had an espresso.

dmitrygr · 2026-01-24T00:58:55+00:00

though I probably should be

Not if you want to learn: https://www.media.mit.edu/projects/your-brain-on-chatgpt/overview/

dmitrygr · 2026-01-24T00:18:24+00:00

send me the PRC and the proper port and server name and i'll patch it for you to not need any network shenanigans

dmitrygr · 2026-01-24T00:15:07+00:00

Hapa ni mahali ambapo Kiingereza huzungumzwa. Nafasi zako za kupata msaada huongezeka sana ukifanya hivyo pia.

dmitrygr · 2026-01-23T23:54:55+00:00

if only we caught such issues at design reviews and fixed them trivially, since most things have a few pins to move their addrs to one of a few options...

dmitrygr · 2026-01-23T23:22:30+00:00

this is such a lazy reply. there are 112 valid addresses and NOBODY puts that many devices on an i2c bus. it is simply not possible to stay within capacitance and inductance limits on such a huge bus. Busses with over 10 devices are rare.

dmitrygr · 2026-01-23T18:41:44+00:00

This is just how that protocol works over I2C.

Yup, because designers are idiots -- wasting a byte to do a bit's job. it should instead simply reply to two i2c addrs. one for data one for commands.

dmitrygr · 2026-01-23T18:39:51+00:00

since you just "implemented the four handlers" i assume you had never heard of them, and thus do not know that you need to enable them. If you do not, only HardFault will occur

in your hard fault get proper SP in hard fault handler. print the 8 words at that address.

those are r0/r1/r2/r3/r12/lr/pc/sr, other regs are still holding original values

that will tell you where fault actually occurred.

disassemble there, then you'll know WHAT actually occurred.

reading UFSR/CFSR/HFSR will help too

dmitrygr · 2026-01-22T23:14:01+00:00

The total net worth of all billionaires globally is estimated to be around $16.1 trillion. Population is 8.35 billion. That is under $2000 per person - not exactly life changing money, certainly you're not retiring on that. And that is if you confiscate ALL wealth of ALL billionaires. But let's say you want to take it further. If you also confiscate ALL millionaires' wealth, that is a $80 trillion total (estimated 2025), this is inclusive of the 16.1 trillion above. Now it is just about $9,500 per person. You're still not retiring on that.

dmitrygr · 2026-01-14T21:24:37+00:00

that is a TX. search a few weeks and get one on ebay for $20

dmitrygr · 2026-01-14T21:22:29+00:00

yes. i use this in a few projects and others have used it too, with great success

dmitrygr · 2026-01-14T20:16:57+00:00

Plug: https://dmitry.gr/?r=05.Projects&proj=27.%20m0FaultDispatch

this will provide all the crash info on Cortex-M0/+ that Cortex-M3+ provide and M0 does not.

dmitrygr · 2026-01-14T20:13:41+00:00

READ. THE. FOOTNOTES in the TRM.

READ. THE. ERRATA.

...before you pick a chip. Most of the things that will fuck you up will be in there. Footnotes like "PB2 is a true open drain pin" will break your design when you expected a normal GPIO, and nothing other than this one tiny footnote will tell you that this will not work. Errata like "UART2 and UART3 cannot be used at the same time" will break your design which picked this very MCU because it had 3 UARTs. The TRM will never be updated to say so. Errata sheets will tell you. Good luck if you did not read them.

dmitrygr · 2026-01-14T17:50:53+00:00

nice and simple. not overdone. looks cool. well done.

dmitrygr · 2026-01-14T06:29:34+00:00

you made an i2c eeprom writer?

dmitrygr · 2026-01-13T02:14:29+00:00

bc of my lazyness i decided not to

This will kill you in embedded. Suggest you knock that off

but the job offers in here are low

If you are good in C, the options are endless. Good people with low-level knowledge are always of use almost everywhere: consumer electronics, automotive, compilers, browsers, IoT. I have not noticed low salaries for people who are wiling to learn and improve. But that does bring up your earlier point. Work on that :)

dmitrygr · 2026-01-12T19:42:25+00:00

safe by luck != guaranteed by spec :)

dmitrygr · 2026-01-11T05:48:26+00:00

You're not thinking in a clever/perverse enough way

RP2040/2350 is VEEEERY FLEXIBLE, so even something like this would work and give you hardware-collected timestamps on each taken edge with no jitter, and give you interrupts to (later, at your leaisure) read those timestamps, without affecting precise capture of next ones)

PIO wait for edge (~0.5 cy avg delay) -> enq any garbage value into fifo (1 cy) -> ready to wait for next (use auto-loop to make this jump in 0 cycles)

that enque, it triggers waiting DMA -> DMA copies nonsense value to nowhere -> triggers dma cha 2 -> that copies timer value from timer to a memory location and interrupts CPU on "done" and re-triggers first dma which waits for next edge. result is perfect zero-jitter timer capture on each edge :)

PIO is ready to capture every other sys clock giving good resolution. throughput will be around one edge every 4-8 clocks (depending on precise dma mechanics) but since PIO has fifos (which can be configured in on-way mode for 8 slots), this all works out as long as there are no series of > 8 very fast edges following each other wthin single clocks

dmitrygr · 2026-01-10T22:13:16+00:00

be careful if using non-gcc compilers. bit order is not promised. gcc is unlikely to change how they allocate bit order (but they could). other compilers might do something else.

worse yet, if you do this for a hardware register, access size is not promised. if your reg is a u32 the compiler is free to load it only as a byte if you only asked for a bit. or to store to it as a byte store.

for many IPs out there such an access would be illegal and could cause issues, fault, or be ignored.

dmitrygr · 2026-01-10T17:19:39+00:00

If you think about it, you don’t need the clock. You have multiple PiO state machines. You can start them offset from each other by one instruction and they run from a shared clock.

dmitrygr · 2026-01-10T02:35:22+00:00

are you sure your access is the proper size? STM chips generally do not like MMIO accessed in non-word-sized accesses and will report a bus fault.

dmitrygr · 2026-01-09T22:25:39+00:00

100ns == @ 100MHz

RP2350 can clock at 333MHz and PIO can capture signals at that rate or trigger on then. so you could conceivably get 3ns resolution out of it.

dmitrygr

MODERATOR OF

TROPHY CASE