Category Archives: School

SC’23 Notes

The entryway to the SC23 conference at the Colorado Convention Center

I got talked into going to SC again this year, as I have almost every year since 2009.
It’s not really my area of focus, but it’s always interesting.

UK's booth at SC'23, featuring the KES PBP demo.


UK’s presence featured a mixture of IT/CCS types and researchers, the research end of the booth was mostly focused on ongoing Parallel Bit Pattern Computing work, featuring a new demo/visualization thing that I built much of the hardware and some of the software for in the 3 weeks before we left for the conference (the rest came from Hank modelling some printable parts, pulling the compute engine from an older demo he wrote, and building some adapter code). It was more exhausting than the conference itself, but a really fun prototyping/micomanufacturing flex. Fancy 3D printed parts, 2020 extrusion, some laser cut bits, piles of addressable LEDs, a bit of embedded electronics. There is also a partially-functional prototype backplane to link 4 EBAZ425 FPGA boards through an Aggregate Function Network as a PBP substrate that …I designed. There’s a lot of not-my-job work I did on display; I should probably start throwing more of a fit about that.

Some notes about the stuff we were showing and interesting(?) industry observations below.

Continue reading
Posted in Computers, School | Leave a comment

Porting Labs from ARM Compiler V5 to V6

I spent the last two afternoons procrastinating from other work doing a deferred maintenance project, porting the labs for UK’s CPE287 Introduction to Embedded Systems from the “V5” armcc to the “V6” armclang compiler, since the most recent releases of Keil (the IDE we use in the class) have dropped support for the older compiler, and all our materials were written against V5. It has been a somewhat interesting porting exercise for a “same vendor, same platform” situation.

We have some slightly unusual circumstances: First, because the class starts in writing pure assembly, proceeds through manual bit manipulation in C, and eventually starts to write high-level software driver model code, we hit all the styles and interfaces. Secondly, we have an inexpensive textbook and supporting materials we rather like, but all the examples use the old style assembly syntax, which differs significantly from the more modern GCC/LLVM style, and for pedagogical consistency reasons we’d like to write our code in that style.

ARM/Keil have produced a document AN298 – Migrate ARM Compiler 5 to ARM Compiler 6 which covers most of the important details, but it was still a bit of a skilled process.

Some notes:

  • For the time being, Keil with the V6 toolchain includes the older armasm binary, so separate pure-assembly .s sources written in the old syntax can still be ingested, you only have to port inline assembly.
  • Keil’s debugger doesn’t appear to be able to keep source lines of inline assembly and the disassembly view synchronized for GCC-style inlined assembly the way it could with armcc. Unfortunate, and a bit klutzy for setting breakpoints, but not a deal-breaker.
  • armclang defines __ARMCC_VERSION as 6something so various pieces of existing code have pre-processor directives that will decide to use the armcc style inline assembly instead of the gcc style ones. Particularly irritating, TI’s first party TivaWare library has this problem in both cpu.c and sysctl.c, so I had to make a hacked version with the #ifdef s swirled around appropriately. The code in TivaWare intended for IAR ewarm is suitable for armclang … as long as you remove some spare ewarm-specific pragmas embedded here and there for suppressing return value warnings; I ended up putting -Wno-return-type in the extended compiler options for projects depending on those files.
  • armclang is much more aggressive about optimization by default than armcc was. In particular, you could get away without marking variables used in busy wait loops or ISRs volatile in armcc, and armclang will happily optimize them out if you forget.
  • armclang is more vocal about implicit type conversion than armcc, especially where it might affect signedness. This is triggered a lot by the REGISTER_NAME &= ~0xMASK bit-specific addressing idiom. I sprinkled in lots of UL suffixes on literals to avoid the issue.

Long term we might try to get off of Keil, though my experiences with CodeComposerStudio have been sufficiently frustrating that I’m in no hurry to move to it for the TI TivaC boards we’ve been using, and while I like ST’s Cube environment, it would both be a major change of materials and a potential supply-chain nightmare (when is the last time you saw a legitimate major electronics vendor with STM32 parts in a stock status other than “Expected Date: Eventually”?)

Posted in Computers, General, School | Leave a comment

PhD Qualified

As of about a week ago, I’ve apparently passed my Qualifying Exam research proposal, which was my last hurdle to PhD candidacy.

My PhD project is on TDCI (Time Domain Continuous Imaging) – an alternative imaging technology that folks in the research group I’ve been working with for almost 15 years now have been building, with my help, for the last 6 years. The basic premise is that digital sensors are not, in fact, re-settable film, and we should leverage them accordingly. By rough concept, TDCI capture is like recording the waveform of incident light from each sensel of the sensor, then computationally exposing that data into an image after the fact, to maximize information capture and so that the sensor and shutter behavior can be tweaked after the fact.

The specific deliverables I carved out as a PhD project were building a high-quality capture device (By hacking a mirrorless body), adding non-uniform exposure behavior to TDCI integration (specifying functions and regions for integration), and building a decent user-facing tool for rendering TDCI images from TDCI captures (A DSL + a GUI to specify common options) – because these were some fun tool-building to carve out of the larger research needs.

The deck with notes that I used are uploaded here. Some of the notes are …not entirely proper… because they were second-screen things for my consumption.

It’s a slightly odd situation because I’ve been working things that feed into this project for 6 years (and 11 papers), and technically started UK’s CS PhD program in 2012 (admittedly, I just signed up so I could keep taking classes while I finished my MS work, finishing the degree is a little “eh, might as well”), but it looks like I’m getting away with it. Also odd, thanks to the COVID-19 situation, it was done via zoom, in pajama pants.

The only points in the presentation I did things I was immediately not happy about were:

  • I was asked about doing spatially continuous models, and spent some time babbling about sensor spatial quantization and fill factors instead of just saying “diffraction” and shutting it down.
  • I didn’t include anything for the “TDCI makes exposure time and shutter angle independent” concepts in the slides, and it came up twice.


Plus I have the concern that Rafi (my Co-Chair) soft-balled the hell out of me and pitched a bunch of questions I’m reasonably sure he knew I had prepared spiels for from my materials. That’s not his usual behavior by reputation or observation, and it makes me slightly paranoid.

Now to finish out the deliverables and actually become Dr.

Posted in Announcements, General, Navel Gazing, School | Leave a comment

I ran into a delightful irony trying to help a student get set up for the embedded systems lab I’m running this semester: Neither Keil MDK ARM (a first-class ARM development environment) nor the Stellaris ICDI Drivers (TI’s programming/debug interface … Continue reading

Posted on by pappp | 2 Comments

College Advice from a University Instructor

I’ve seen a spate of articles pop up recently discouraging people from going to college in fall 2020 because of the COVID-19 pandemic situation. They’re mostly from self-mythologizing startup douches and/or carpetbaggers trying to sell alternative education products, so there isn’t much of value in them and I won’t be linking.

However, talking about them has me refining and recording the advice I give to prospective college students.
So in that interest, a list of my usual advice. Which is very, very explicitly prefaced with the usual “Opinions expressed are solely my own and do not express the views or opinions of my employer” disclaimer.

Continue reading
Posted in General, School | Leave a comment

SC’19

Even though I haven’t done any work in that area in years, I got pulled into the Supercomputing conference again this year.  Can’t complain, it’s always fun.  UK’s combined booth looked good this year

Far corner is a little updated TinyTitan style Raspberry Pi cluster with a interactive CFD demo running on it that the CCS folks have been playing with, that thing in the leading corner is a cute flip-dot “quantum computer” model we built as a front-end for a 16-bit instance of Hank’s parallel bit-pattern computing system that can do quantum algorithms efficiently on a conventional platform – set in the corner of the booth like

You don't need quantum physics to perform quantum compution. Change my mind.

He did surprisingly well with this approach.

The exhibit floor was even more dominated by cooling tech this year. Exciting finds are the coming of very open (Open Compute Project, Coreboot + Open Network Linux) white-box 100GBE switches at reasonable prices, Fujitsu’s A64fx ARM with SVE and obscene memory bandwidth parts actually landing in systems, and (just because it tickled me) pre-wired fully populated Clos topology 100G cable harnesses.  The other dominant species was AI woo; my body is ready for AI Winter 3.0.

Google photos album of my annotated show floor photos is here.

Posted in Computers, General, School | Leave a comment

Masters in Electrical Engineering (Finally) Collected

That MSEE that I was going to finish in 2011, 2013, and 2015? I blew a couple months in the last year to get all the ducks in a row and actually collected it before the credits expired.  Huge thanks to Dr. Aaron Cramer, the current DGS for UK’s ECE department who went to great lengths to deal with the bureaucratic issues my lackadaisical attitude about credentials created.

Thesis is “A Compiler Target Model for Line Associative Registers” document and defense slides with notes linked.

The LARs design is fundamentally interesting, but the compilation work the MS is based on is not my favorite work I’ve done.  The core initial assumption (that LAR allocation and register allocation were more-or-less the same problem) turned out to be very, very wrong, and the implications of that wrong assumption turned out to be far reaching, turning a 2-year MS into a decade-long ramble. It’s not as depressing as I thought it would be when I tried to finish in 2015 (and was blocked by bureaucratic fuckery) because I did eventually determine that LARs aren’t subject to the “you can’t statically schedule around dynamic memory behavior” thing that doomed VLIWs, and in fact LAR allocation can be done greedily in ways that register allocation cannot.

The thesis is more or less assembled from three false starts plus the final effort; my initial research start with the wrong assumptions, my “oh, we’re wrong, but it’s OK” pass, and my “oh shit, we’re screwed, this won’t work and there his historical evidence to show it” pass, plus the final “I’ve figured out how this is tractable and possibly even desirable, but I’m out of time and fucks, so here’s the rough solution” pass.

I formatted the thesis in LaTeX (of course), using the ukthesis.cls class I found on the UK Math site that Eric Stokes, a former student, made a decade and change ago since UK is too chickenshit to provide a valid one of their own.  I did have to hack it a little bit, turn off some features, tweak the front matter, etc. to make it acceptable to the graduate school, and update a few things (eg. adjusted to use biber for references).  There are a few things in the document that should be in the class, and things in the class that should be in the document, but the easy-to-fix stuff is fixed.  Minimal example pulled from the accepted version with makefile and such here to save future students the extra annoyance.

The presentation is in beamer using the Owl theme, which was a delightful recent discovery – someone has made a beamer color scheme with a dark background and colors that actually look good on a projector. I (much to one of my committee member’s disappointment) went with the bullets-to-keep-me-on-track-while-I-talk style slides instead of my usual “amusing semi-relevant pictures to key off of” scheme.

It’s nice to be done and only have one, significantly less depressing, long-term academic project people are grumpy about my progress on.

Posted in Announcements, Computers, General, School | Tagged | 1 Comment

Ebay DB25 Arduino Nano grbl Adapters

A second consecutive CNC post, because I haven’t had time to write up long-form posts for months, and something requiring documentation came up today.

While I’m still quite happy with LinuxCNC (especially since I discovered NativeCAM), my adviser bought himself a GRBL-DB25 adapter board for his 3040T mentioned in my previous post. He has been unsurprisingly unsatisfied with the performance of the terrible old SFF P4 box he has been using to drive it with LinuxCNC, and we’ve (read: I’ve) become reasonably comfortable with grbl due to the several shitty diode laser cutters that have recently proliferated around here (One or more of the involved parties will be posting about those shortly). As I’ve noted elsewhere, grbl is not my first choice, but has reached baseline required functionality in versions >1.1 and is unarguably convenient.

In particular, he went with one of the Arduino Nano based boards floating around ebay with titles like USB 3-Axis CNC TB6560 Driver Board Controller Converter GRBL Arduino Nano DB25, which are unfortunately both undocumented and (as it turns out) unsuitable. He asked me to help set it up, and this post serves to document and warn based on my findings.

It seems like it should be a great solution, but it will not work with the typical black control boxes that come with many little aluminum CNC machines or most other common 3 or 4 axis breakout boards. It has the (dead) URL www.getlofi.com/grbl-to-3axis on the silkscreen, and while getlofi.com does appear to be a valid page run by some hackers mostly into circuit bending, I couldn’t shake any mention, much less relevant documentation out of the page. What I did find with a continuity tester and some patience is the following unfortunate arrangement:

The problem is that the designer decided to tie DB25 pins 2,6,and 14 together to nano pin 11 (D8) with traces on the adapter. This renders it completely unusable with the 2-7 StepX/DirX/StepY/DirY/StepZ/DirZ pinout the vast majority of boards use, as StepX and StepZ are wired together. If I’m inferring which shitty blue TB6560 3-axis board it’s designed to work with correctly, 2, 6, and 14 are intended to be per-axis stepper enable pins, but that is not a particularly common configuration.

For contrast, I picked up one of the Arduino GRBL to DB25 CNC Shield Kits available from “Ron” on Tindie to throw in my parts bin for testing. It’s actually documented, supports the pin-out most parallel control boards I’ve encountered use (with the default grbl pinout no less), and has each individual pin broken out like a sane designer, so it should support any reasonable configuration. I tried my tindie board with the machine that was supposed to get the fail board, and it seems to work fine, so I’m going to encourage picking up one of those instead (unless we get ambitious and just cut our own DB25-Nano board).

Posted in Computers, DIY, Electronics, General, Objects, School | Leave a comment

Install Viavdo 2016.2 on ArchLinux (x86_64)

As of the date of this post, Xilinx Vivado 2016.2 works fine on Arch with minimal coaxing. Said coaxing is documented here in case it will be useful for others.

1. Install ncurses5-compat-libs from AUR, or the installer will hang during a later step. It appears to be required at runtime as well.

2. Mark the installer executable, eg. chmod +x Xilinx_Vivado_SDK_2016.2_0605_1_Lin64.bin, and run it with the confirm flag, ./Xilinx_Vivado_SDK_2016.2_0605_1_Lin64.bin --confirm

3. Hit Y at the “unpack” prompt, then go into the directory it creates at /tmp/selfgz[RANDOMSTRING], and edit xsetup to replace `uname -i` with `uname -m`, which is what they should have used in the first place.

4. Pre-create and permission the install path, a reasonable choice is the default /opt/Xilinx, which needs to be writable by the user doing the install (eg. chgrp users /opt/Xilinx, chmod g+w /opt/Xilinx)

5. Return to the terminal and hit Y to continue until the GUI installer runs.

6. Follow the GUI installer instructions, Feed the prompt your Xilinx credentials, Select Vivado HL WebPACK, etc.

7. The activation prompt at the end of the installation procedure is misleading, in the 2016.x versions if you simply quit without activating, the install automatically goes into WebPACK mode. If you don’t have/need any of the non-WebPACK features, activating the 30-day free trial of the nonfree version is asking for a headache when it expires.

8. It works. (and as a bonus convenience over the old toolchain, at least the Digilent Basys 3 boards use a normal FTDI usb-serial as their onboard programmer, so you don’t have to fight with drivers to program boards, that just works too.)

Posted in Computers, General, School | Tagged , | Leave a comment

Makergear M2 Upgrades

M2UpgradeComplete

The lab Makergear M2’s heated bed power supply died a few weeks ago, so we decided it was time for a serious upgrade, and set out to equip it with basically the best parts currently on the market, as we’re convinced the M2’s mechanical construction is still about as good as it gets.

Our M2 was a very early M2 from early 2013, with a split-voltage 19v/12v power supply setup, was on its second RAMBo after the first one melted around some connectors (high-current 12V is not a good idea), and RAMBo #2 was already abused with an external transistor on a heatsink wired in to the bed heater. It was also on its second hotend after the first one failed catastrophically during a sensor-separation incident some years ago, and was running a mutant Makergear V3b w/ 12V cartridge custom ordered to suit our machine.

So, shopping list:

Plus a whole boatload of connectors. For reasons known only to themselves, Panucatt doesn’t (or at least didn’t at the time) actually document which kind(s) of connectors are on the board, or offer a wiring kit. Some measurement and educated dead-reckoning got us there, so for anyone else looking, it uses Molex KK connectors in 2.54mm with both keys and locking ramp, in 2,3,and 4 positions. Specifically:

  • Motor (4x): 4 position, Molex p/n:0022013047 (Digikey)
  • Endstops/Probes (4x): 3 position, Molex p/n:0022013037 (Digikey)
  • Thermistors (2x): 2 position, Molex p/n:0008500114 (Digikey)
  • Crimp pins for the above (>32x): Molex p/n:0008500114 (Digikey)
  • Fan (2x): Standard 100mil pinheader, 3 positions. We used generic 3pos Dupont connectors from a Chinese kit.

I’d suggest buying at least one extra housing in each size, and a substantial number of extra crimp pins (They’re like a dime each in quantity, we bought 50 and had plenty to spare). I got a bit of a chuckle that they use 2.54mm molex KKs with locks and keys for everything except the fans, while standard PC fans use 3p molex KKs with locks and keys, but we’re running a 24V system so PC fans would be inappropriate anyway. I personally bought myself an Engineer PA-09 crimp tool because this crossed the line on crimp terminal projects where I’m willing to do it by futzing around with pliers.

M2PartsPile

The parts for this little project could have bought us a second low end printer, but that wouldn’t have given us any interesting new capabilities (particularly since we already have a Wanhao i3), and the machine we ended up with is approximately as capable as any FDM printer on the market.

The Makergear specialty parts are lovely, and improved in various ways as compared to even the newer M2 the lab PI owns personally; the power supply is in a ridiculously nice metal case and has ferrule-tipped color coded wires, the new bed heater covers the aluminum spreader more fully, is constructed with a very nicely machined wire and thermistor bracket, and includes a semi-rigid split-loom to keep it clear. I built a couple slightly weird cables and did some aggressive polish and longevity tweaks, including putting ferrules on everything going into a screw terminal (I did it partially because I decided I wanted an excuse to own a ferrule crimper and assortment). Probably the weirdest bit is that all the fans have male 2pos Dupont connectors on them, and the always-on cooling fans around the head are connected via a Y cable that terminates in a 4-position female dupont wired +24,Gnd,+24,Gnd (Picture has the wires routed wrong).
M2FanFork

All the cabling then retreated into the awesome mesh split-loom wire guides Makergear uses, and went on in more or less in the same configuration as the original cabling, including the weird little ball of wire at the back of the frame.

M2InitalElectronics

We also printed a number of parts for the upgrade, including a set of thingiverse user Neo Usagi’s E3D v6 40 mm Fan Duct and Extruder for MakerGear M2, which is an excellent design, though ours came out seriously over-tight and had to do a bit of grinding then perform the install with a vise – the dominant theory is that it was our fault for using 3 walls. Once fitted, it’s proven to be an excellent assembly with very good well-focused airflow and no tendency to bump into parts or the machine. The area around the head in this setup is extremely congested, and you must run the hot-end wires to the X+ side (the same side as the fan shroud mount) or they will hit the frame before the X endstop triggers, but once everything is situated it makes a nice package with no dangly bits. Even though it isn’t showing much noticeable difference in performance relative to late-model Makergear heads, I’m thoroughly impressed with the E3D hotend; the machining, the quality of the accessories in the kit, the efficacy of the heatbreak, the ease of assembly, everything is excellent, and in the mount we used, it only eats about 3mm of Z travel. They richly deserve their reputation.

M2E3DAssembly

As for the X5 Mini, two of the Makergear original mounting holes are close enough (though not perfectly aligned) to mount the board in a reasonable way with a pair of standard brass threaded standoffs, and a pair of those little barbed plastic motherboard standoffs trimmed to size to prevent tilting, all taken from the lab’s vast collection of PC assembly hardware. Leaving it exposed didn’t seem like a good plan, and we were seeing a slightly uncomfortable amount of warming on the motor drivers, so it needed a case and fan shroud. To that end we designed our own cover/enclosure/fan duct/bracket for the X5 Mini V3 and Viki2 (visible in the header picture – it has a 24V 40mm fan facing the Z motor blowing into the case, powered directly from an extra pair of PSU taps), a more detailed post about which will probably appear on profhankd’s thingiverse page shortly. We did all the printed components for the upgrade in our new favorite material, MakerGeeks’ “Raptor” PLA, incidentally in blue.

Software-wise, I’m satisfied but not enthused by Smoothieware. We’re now running this config.txt, which assumes 32x microstepping on all axes and produces very smooth, quiet motion with a minimum of idle heating. The major tuning efforts are just in the heater PIDs and on the Z movement, as the M2 design tends to make terrible noises if the Z movement is outside of a very narrow velocity window.

I wanted to like Smoothieware a lot more, and it is working well enough for the most part, but it is frankly kind of a garbage fire once you start looking at the code. It’s “modular,” but in an entirely ad-hoc way, so the parts don’t interact in entirely reasonable ways (Ex: AFIK it is currently incapable of setting up a “prevent cold extrusion” behavior, and would take pretty substantial changes to make it able to), with random parser fragments spread throughout the code. It also fails silently on unknown configuration keys, so I wasted the better part of a day on the extruder not responding after I wrote extruder.head.module_enable instead of extruder.head.enable because I misunderstood their half-updated documentation from when they hacked it to support multiple extruders. It looks and smells like a Reprappy hacker/hobbyst “move fast and break things” software, which is fine, but is so much so that I really don’t have high hopes for it maturing into something survivable without a complete redesign. This does make me feel better about sticking with LinuxCNC for my latest personal CNC project (Which I will eventually get to writing up and posting…).

Is ridiculously quieter than even the 24V stock M2, prints nicely at 150mm/s in PLA, heats up almost as fast as you can get a file loaded up and sliced, and can do so more or less independent and minimally attended. From a working current-gen 24v M2, none of the changes we made are particularly substantial upgrades, but from it’s state before the improvement is spectacular.

Posted in DIY, Electronics, General, Objects, School | 4 Comments