Notices by Erin 💽✨ (erincandescent@akko.erincandescent.net)

@hikari France has the same cultural thing going on as the UK, whereby theres lots of cool things going on but it all has links to immigrants or places outside of Paris and thereby is Not French according to the stuffy rich white guys who run the Government.

@whitequark @rygorous What’s this DMA you speak of? Laughs in 8051

@whitequark @rygorous (the plus side of it being a 1T 8051 of course is that a uart interrupt probably only costs like 10 cycles, so it doesn’t matter that much. but probably what I should do is just max out the BRG at like 3mbaud and hook it up to my Glasgow)

@rygorous no

@rygorous busy waiting but it probably wouldn’t have helped to put a fifo in front because the log volume would very quickly have swamped the buffer

(I was logging every byte received in hex and my laptop was impatiently spammig a lot of messages at me)

:drgn_scream_angry: FUCK.

Well, at least this explains why the voltages I’m seeing on the CC lines are so fucky.

Time for a bodge wire >_<

Chat, Erin spent her entire day trying to figure out why the USB PD controller’s interrupt was never firing.

The answer turned out to be that Erin forgot to clear the interrupt pending flag on her 1kHz timer…

The none interrupt code in this project does so little I never realised that it was executing like 1/100th the time >_>

My PD reception buffer now contains

Which looks like (Remember in the followig all fields are little endian

• 8F10 - USB PD Rev 3.x, 1 data object, vendor defined message
• 01a000ff VDM header
  • 00ff - USB PD Standard ID
  • 01a0 - Structured VDM, v2.x Command = Discover Identity
• a4450272 CRC32

Which seems quite cromulent for my laptop to be sending to the cable (SOP’ = addressed to the cable not the device)

OK restricting things just to SOP messages (i.e. messages addressed to me and not the cable I’m plugged into) I see

Which is very much the first message the spec says a source should have sent me, so I think I’m in a good place to draw the rest of the owl

Previously, my device was receiving PD messages but doing nothing with them, so the host was treating it as a dumb PD-unaware device and powering it with the default port vSafe5v.

However I’ve now implemented enough of the stack to start sending messages to the host (but just GoodCRC so far). This means the host is treating it as a PD device which doesn’t ask for power, which means quite promptly it gets its power turned off.

This is mildy inconvenient.

I should probably assemble one of these boards with the MCU not Vbus powered for reduced frustration…

So the basic USB PD sequence is

1. Source: Source_Capabilities { 5V3A, other possible capabilities}
2. Sink: Request { 5V1.5A }
3. Source: Accept
4. Source: PS_Rdy

I spent the entire day trying to work out why the source (my laptop) didn’t like my Accept message. It was bitwise identical to what I saw other hardware sending, so I didn’t understand why it disliked it. I added all sorts of debug logging to track it down.

The problem turned out to be that my stack was too slow, on account of all of the debug logging. A good old embedded systems classic.

Timer Interrupts 3%
Protocol Stack 2%
Waiting for UART 92%
Printf 3%
someone who is good at optimization please help me budget this. my microcontroller is dying

Putting OpenTelemetry tracing information in one of the private use fields of a Mastercard authorisation message, as one does.

@ryanc honestly having my editor be sarcastic with me when working with linux kernel code would massively improve my day.

@hokaze Most of them are i686 (Debian included), which IMO is stupid because the 32-bit x86 chips that are relevant in 2025 are DMP Vortex86s and AMD/National/Cyrix Geodes which are generally i586 not i686 CPUs!

If you’re still using a Pentium 3 or Athlon XP you can pick up some literal trash that’s faster, smaller, has more memory, and consumes 1/20th the power.