@azonenberg@ioc.exchange
@azonenberg@ioc.exchange avatar

azonenberg

@azonenberg@ioc.exchange

Security and open source at the hardware/software interface. Embedded sec @ IOActive. Lead dev of ngscopeclient/libscopehal. GHz probe designer. Open source networking hardware. "So others may live"

Toots searchable on tootfinder.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

azonenberg, to random
@azonenberg@ioc.exchange avatar

Well, looks like it's doable! I have a draft pinout for the STM32H735 that hooks up one quad SPI channel to a flash chip, parallel trace, plus three different interfaces to an FPGA:

  • Octal SPI + DQS
  • FMC configured as 16 bit multiplexed PSRAM
  • RMII

Still have to figure out what other peripherals, if any, to hook up. This is mostly just a testbed for MCU-FPGA communications to see what interface I want to use for my next big embedded project, it won't actually do anything useful.

But if I can test as many things as possible, that will help avoid the need for more sandbox boards in the near future.

gsuberland, to random
@gsuberland@chaos.social avatar

JLC order arrived! 🎉

azonenberg,
@azonenberg@ioc.exchange avatar

@gsuberland Yep. I use 0.47 uF 0402s (Samsung, I don't have the part number handy) as my default small decoupling cap.

I still use 0.1 uF for AC coupling of signals sometimes, though. Mostly out of habit because I have a reel on the shelf and I know it'll work for those standards and I don't feel like running the numbers to make sure it will work with 0.47.

azonenberg,
@azonenberg@ioc.exchange avatar

@gsuberland In general most of my designs are 100% MLCC for anything below 12V, and hybrid or solid aluminum polymer for 12/24/48V bulk caps.

azonenberg,
@azonenberg@ioc.exchange avatar

@gsuberland (looks over at 330 and 680 uF MLCCs on some recent BOMs)

And you call polymer caps pricey?

azonenberg,
@azonenberg@ioc.exchange avatar

@gsuberland Hmm looks like I misremembered, it was a 330 in both cases not 680.

Anyway, representative part for that kind of cap would be GRM32EC80E337ME05K ($1.26 @ qty 1, $0.86 @ 50). DC bias curves are excellent, down maybe 10% at 1V so perfect for the 850/900/1000 mV rails on modern FPGAs and such.

A typical high voltage cap I'd use on a 12V rail would be Panasonic 25SVPF330M which is $2.08 @ 1, $1.46 @ 50. So around double the cost of the MLCC (but rated for 25V rather than 2.5V lol)

azonenberg,
@azonenberg@ioc.exchange avatar

@gsuberland Yeah, that's more in line with what I remember really big MLCCs costing.

Right now 330 looks to be about as high as I am likely to go, if I need more I'll parallel 330s rather than buying a chonker like that.

azonenberg,
@azonenberg@ioc.exchange avatar

@gsuberland Yeah. The 330 vs half a reel of 4.7s, otoh, makes a lot of sense.

azonenberg,
@azonenberg@ioc.exchange avatar

@timonsku @gsuberland I stock 22 uF in both 1206 (for low voltage) and 1812 (for 12V) depending on where in the C/V curve I need to be.

azonenberg, to random
@azonenberg@ioc.exchange avatar

What's the go-to option for RGB status indicator LEDs that contain an integrated controller so I can control a lot of them from a handful of pins? Are people still using the WS2812 or are there better options these days?

azonenberg,
@azonenberg@ioc.exchange avatar

@ignaloidas I want indicator (rather than illumination) level output power levels, a reasonably small package (smaller than 5x5mm if possible, I see a lot of 5x5s), an interface I can easily drive from a bog-standard MCU or FPGA (not picky on specifics of protocol), and some way to daisy-chain them to simplify PCB routing if I want one per input channel or something.

azonenberg,
@azonenberg@ioc.exchange avatar

@mossmann Single color indicators are nice for pass/fail type stuff but for e.g. color coding inputs, it can be hard to find all of the colors you want as discretes. I suppose I could use RGB discrete LEDs with fixed resistors to set the desired color for a given channel or something, but making it programmable seems simpler from a BOM/layout perspective.

azonenberg,
@azonenberg@ioc.exchange avatar

@mossmann This is one thing LeCroy does well on all their stuff.

Even their active probes light up depending on which channel they're plugged into.

azonenberg, to random
@azonenberg@ioc.exchange avatar

@pervognsen Yep.

For my embedded projects my requirements were "key-value store for binary data", "usable on a tiny cortex-m0", "smallest flash usage possible", and "resilient to power failures, resetting the chip at any point including during a write cycle should result in writes atomically succeeding or failing".

This ended up leading to the creation of my MicroKVS project which is optimized for small code size and minimal flash usage at the expense of speed, and uses the smallest amount of flash theoretically possible while still providing power loss protection (two flash erase blocks) unless you explicitly ask for more space to store larger amounts of data.

atom, to random

If Windows XP was released in 2024

azonenberg,
@azonenberg@ioc.exchange avatar

@atom Thanks I hate it.

azonenberg, to random
@azonenberg@ioc.exchange avatar

First light on the Thunderscope beta after grabbing an upstream driver fix. There's definitely some rough edges I'm going to need to fix before it hits production, but I'm really excited - it's FAST!

With ngscopeclient running directly on the laptop the scope is plugged into (i9-10885H, Debian Bookworm, Quadro RTX 3000) I get 17 WFM/s for 4 channels @ 250 Msps with 10M points memory depth. That's 680 Ms/s (out of a theoretical 1000 coming off the ADC). At 8 bit sample size that's 5.44 Gbps, around double my previous record (PicoScope 6824E).

With the TS.NET bridge server on the laptop and a 10GbE Thunderbolt dongle connecting the laptop to my LAN, then ngscopeclient running on my main bench workstation, I "only" get 7-10 WFM/s - about half speed and competitive with the PicoScope.

There's likely room to optimize all of these numbers, this is just an initial sanity check.

azonenberg,
@azonenberg@ioc.exchange avatar

@ignaloidas AFAIK this is TBT3. It's also available in a PCIe addin card form factor.

azonenberg,
@azonenberg@ioc.exchange avatar

@ignaloidas And I'm pushing them to make a 10GbE connected version with a SFP+ cage at some point, so we'll see if that happens.

azonenberg,
@azonenberg@ioc.exchange avatar

@ignaloidas Yeah the only challenge is they'd need a bridge chip since the FPGA they're using only has 6 Gbps transceivers.

Next-gen platform will probably have native 10GbE.

mia, to random
@mia@void.rehab avatar

theseus and antitheseus combine to form syntheseus. but how much of the original theseus remains?

azonenberg,
@azonenberg@ioc.exchange avatar

@mia I thought they just annihilated and you got a bunch of gamma radiation?

azonenberg, to random
@azonenberg@ioc.exchange avatar

Little code snippet if anyone needs a hand with executive functions...

void executive()
{
//yep, this is where you do that thing you keep not getting around to
}

pervognsen, to random
@pervognsen@mastodon.social avatar

Somehow I doubt it. Headline: "Microsoft is finally getting its native Windows UI platform act together with WinUI 3 and WPF."

azonenberg,
@azonenberg@ioc.exchange avatar

@pervognsen Not unless it lets you make classic Win2K styled applications.

azonenberg, to random
@azonenberg@ioc.exchange avatar

So apparently Murata makes high power, fixed ratio (6A, divide by 4) 2-phase charge pump step-down converters intended for 48V -> 12V applications.

It looks to have higher efficiency especially at low loads than the TDK module I'm using now. Seriously considering making a variant of my IBC to try it out. Non-regulating but that should be fine given my use case (generating 12V intermediate rail which will itself be fed to other buck modules).

Anyone have thoughts? I've always thought of charge pumps as ittty bitty things you use when you need a negative bias rail, not something you pull six amps from.

https://www.murata.com/products/productdata/8815194046494/MYC0409.pdf

azonenberg,
@azonenberg@ioc.exchange avatar

@0h00000000 I'm using a buck now, and certainly open to exploring other buck units as well.

But I'm specifically looking for integrated DC-DC modules (whether buck, charge pump, or other topologies) that have all of the passives and transistors included and just need external bulk caps.

When I have a dozen rails on a board I don't want to lay out SMPSes by hand every time. I'd rather just slap down a module and a few caps. The IBC is only a single channel but still, if I'm building a bunch of prototypes modules are less effort than throwing down a bunch of discretes.

Also usually lower risk in terms of a higher probability of a right-first-time design.

hazelton, to random
@hazelton@sparkgap.marsfreeradio.org avatar

trying to create smol test structures for 4-point probe measurements using maskless lithography, each pattern is 140um square. this is only photoresist on silicon, next will need to evaporate some titanium and gold.

azonenberg,
@azonenberg@ioc.exchange avatar

@hazelton At one point I was literally using copper strands out of a mains power cord I found in the matsci department e-waste bin lol.

azonenberg, to random
@azonenberg@ioc.exchange avatar

New thread on my big ongoing embedded project since the other one was getting too big.

To recap, this is a pilot project for a bunch of my future open hardware T&M and networking projects, validating a common platform that a lot of the future stuff is going to run on.

The primary problem it's trying to address is that I have a lot of instrumentation with trigger in/out ports, sometimes at different voltage levels, and I don't always have the same instrument sourcing the trigger every time.

So rather than moving around cables all the time and adding splitters, attenuators, amplifiers, etc. to the trigger signals I decided to make a dedicated device using an old XC7K70T-2FBG484 I had lying around.

Of course, as with any project, there was feature creep.

I'm standardizing on +48V DC for powering all of my future projects as it's high enough to move a lot of power but low enough to be mostly safe to work around live. So I needed to design and validate an intermediate bus converter to bring the 48 down to something like 12 for the rest of the system to use.

The FPGA has four 10G transceiver pairs on it. I used one for 10GbE (not that I need the bandwidth, but I was low on RJ45 ports on this bench and had some free SFP drops) and the rest are hooked up to front panel SMA ports (awaiting cables to go from PCB to panel) to generate PRBSes for instrument deskew.

Since I'm pinning out the transceivers and am planning to build a BERT eventually, I added BERT functionality to the firmware as well (still need to finish a few things but it's mostly usable now).

And since I have transceivers and access to all of the scope triggers, it would be dumb not to build a CDR trigger mode as well. That's in progress.

azonenberg,
@azonenberg@ioc.exchange avatar

Well, of course I discovered more yaks.

On the plus side, it looks like probably >90% of the code for the bootloader on the front panel is going to be reusable for the main MCU as well.

Just need to finish refactoring it (and the main MCU firmware) to enable this.

azonenberg,
@azonenberg@ioc.exchange avatar

@xpi Oh, they stay shaved. But every time I shave one another few come around the corner. It's whack-a-yak.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • JUstTest
  • tacticalgear
  • DreamBathrooms
  • thenastyranch
  • magazineikmin
  • Durango
  • cubers
  • Youngstown
  • mdbf
  • slotface
  • rosin
  • ngwrru68w68
  • kavyap
  • GTA5RPClips
  • provamag3
  • ethstaker
  • InstantRegret
  • Leos
  • normalnudes
  • everett
  • khanakhh
  • osvaldo12
  • cisconetworking
  • modclub
  • anitta
  • tester
  • megavids
  • lostlight
  • All magazines