Notices by Andrew Zonenberg (azonenberg@ioc.exchange), page 2

I wonder if the engineers at ST were on something when they named this peripheral...

@whitequark Would memsetting (void*)0 be any more legal?

@whitequark So is there no legal way, from C++, for me to initialize the first byte of ITCM?

So I just wrote

memset(NULL, 0xcc, 2048);

on purpose, expecting it to actually do something. Does that make me a horrible person?

@whitequark Is it? The value of NULL is implementation defined not UB. In my libc (as with most) it's zero.

And on this chip's memory map, zero is a valid, writable, executable address at the beginning of a 64K ITCM SRAM segment.

I'd rather build better bitcoin miners or stock-trading FPGAs than self driving cars, and that says something.

@alan I would happily work on military/defense stuff as long as it was interesting and didn't require getting a security clearance that would interfere with my F/OSS work (I've turned down several roles that would have needed one).

But self driving cars serve purely capitalistic interests and in many cases are actively hazardous to their occupants and other road users.

@alan This is also why I'm more opposed to corporate datamining than government surveillance.

NSA, at least on paper, has my best interests at heart. They're looking for foreign terrorists and spies and couldn't care less about the cat gifs I'm sending to a friend. I'm boring and they're not supposed to be looking at me anyway.

But corporate spies have a fiduciary obligation to their shareholders to datamine everything they can learn about me and exploit that information to serve their financial ends, typically to my detriment. They're actively seeking to harm me and they certainly aren't legally obligated to ignore me because I'm a US citizen on US soil.

An ex-coworker now at [redacted autonomous vehicle company] just tried to convince me to come work for them. Obviously I declined.

In case it wasn't obvious to anyone else, let me just state in plain English: there is no amount of money that will get me to build self-driving cars for you. The bigger the number the harder I'll decline.

I don't even like sharing the road with L2 ADAS equipped vehicles. The last thing I want to do is contribute to making the problem worse.

Now, if you wanted me to work on a fully human-controlled EV with no telematics or automation, designed for repairability with a 30+ year target lifespan, and redundant sensing and actuation and triple redundant lockstep CPUs on safety-critical components like ABS? Maybe we can talk.

But self-driving cars are probably one step above "DRM'd medical devices that stop working if you don't pay a subscription fee" on my "these should not exist and I will not lift a finger to help you create them" list.

Made good progress on the FPGA - MCU link revamp.

All of system information/health registers (ID code, serial number, fan RPM, temp/voltage monitors, bitstream timestamp, etc) are now readable over QSPI-APB and the legacy-bus interface has been removed.

So far the bridge only works in read mode but I'll be adding write support shortly.

Once I have most of the registers converted over I'll start playing with memory mapping again on the MCU side.

While I wait for the front/rear panel cables (expected to ship tomorrow) I've been working on some other parts of the firmware.

In particular, rather than using embedded Linux like most people probably would have, I wanted to keep this bare metal. So I found myself implementing things like a SSH server for bare metal STM32 with no OS (and no dynamic memory allocation).

Currently I'm working on a SNTP client that syncs the STM32 RTC to a network time server. Almost done with the NTP side of things, just have to write the RTC driver.

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.

Other than that, pending TODOs:
* IPv6 support in the TCP/IP stack
* libscopehal driver support for the SCPI commands (already implemented in firmware) to set input threshold and output drive voltage
* Finish the CDR trigger mode. Right now I have 8b/10b and 64b/66b decoding in the FPGA bitstream, but need to add a pattern matching engine and SCPI commands to configure it
* Add commands for deep BER integration (continuous sampling reporting number of PRBS errors since last clear or something)
* SFTP-based OTA firmware update for (at least) the main processor and FPGA. Will probably try and get the front panel processor as well, but neither the supervisor nor the IBC has enough flash for A/B images. I'll probably switch to different STM32L0's with more flash in future projects to enable OTA flashing of the entire system.

NTP client is now pretty-printing a human readable yyyy-mm-dd hh🇲🇲ss.uuuuuu timestamp with hard-coded UTC-to-local offset.

Next step: make that offset configurable, get the RTC driver written up so I can store the timestamp to the RTC, and add a #define to logtools to make it print the timestamp from the RTC instead of since boot.

I think OTA support is probably the next priority after I finish NTP.

Once I get working OTA support and all of the front/rear panel cables are installed, I'll be able to close the thing up and free up a ton of bench space.

Although I might not rack it right away, since having access to JTAG will still be handy for active firmware development.

Let the NTP firmware run over a few hours while having dinner and doing family stuff.

It looks like the local oscillator on my MCU is just a tad fast relative to GPS time (the stratum 1 NTP source on my lab LAN).

The polls are approximately 1024 seconds apart, and I'm running about 2.8 - 2.9 ms fast every time I re-sync the clock to NTP.

Let's call this 2.85 ms of error into 1024 seconds, which comes out to about 2.78 ppm.

Not bad considering i'm using a non-temperature-compensated quartz oscillator with a datasheet tolerance of +/- 25 ppm.

NTP on the STM32 is working!

First line: RTC timestamp prior to sync
Second line: timestamp received from time server, after correcting for network latency
Third line: RTC time read back after synchronizing it to match the NTP timestamp

Only thing left is logging library integration.

Results of an overnight test run. Not bad.

And I think that's all the CLI and library plumbing needed for full NTP integration including the logging library.

Only thing missing is adding configurable UTC offset and DST support at some point, although that's not an immediate priority since I'm the sole user of the system and the next DST transition is quite a ways off...

Ok, got some housekeeping stuff out of the way. Confirmed some of the display corruption I was seeing on the front panel was due to overflowing the SPI FIFO when data came from the FPGA too fast, but I had plenty of RAM so I just made the FIFO a bit bigger and the problem went away.

Also made the SPI class have compile-time variable FIFO sizes which will simplify things a bunch.

Still probably going to have to make some tweaks to some of these peripheral drivers to make things nicely integrated without adding too much overhead. It's going to be a process.

Anyway, the elephant in the room is OTA firmware update via SFTP. This is going to take some time to get right.

Before I work on that I have a few other more small yaks to shave, like https://github.com/ngscopeclient/scopehal/issues/866.

So I think that ticket will be the next focus, it should be straightforward.