Rationale I was reading up on web frameworks available when programming in Haskell earlier today, and I liked the use of domain-specific languages (DSLs) within frameworks such as the routing syntax in Yesod. Compared to how routes are specified in Django (as a similar example that I’m already familiar with), the DSL is both easier to read (because it doesn’t need to be valid code in the hosting language) and faster (since it ends up getting compiled into the application as properly executable code).
A pattern I find myself using rather often in Python projects is to have a small module (usually called config) that encapsulates an INI-style configuration file.
I got a.. “fun” e-mail from mediafire a few weeks ago, saying that one of my files had been suspended due to suspected copyright infringement.
fb-hitler? Oh, that’s some Free Software I wrote. I disputed the claim, simply stating that fb-hitler.tar.bz2 is a piece of software that I created (and thus own the copyright to). As of tonight, I’ve heard nothing back about it, and the file is still inaccessible. Here’s the link to it, for future reference:
http://www.mediafire.com/?mhnmnjztyn3 (.tar.bz2, 477 KB)
And here’s the complete message I got. Notice it somehow got pulled in by somebody looking to get links to Dragonball Z downloads removed, and that the link to fb-hitler itself isn’t even in the (absurdly long) list of URLs given.
I caught on to a promotion from AVNet last week, in which one may get a free MAX5214 eval board (available through August 31), so hopped on it because really, why wouldn’t I turn down free hardware? I promptly forgot about it until today, when a box arrived from AVNet.
What’s on the board The board features four Maxim ICs:
MAX8510- small low-power LDO. Not terribly interesting. MAXQ622- 16-bit microcontroller with USB. I didn’t even know Maxim make microcontrollers! MAX5214- 14-bit SPI DAC. The most interesting part. MAX6133- precision 3V LDO (provides supply for the DAC) Board schematic Board, front side Board, back side The MAXQ622 micro (U2) is connected to a USB mini-B port for data, and USB also supplies power for the 5V rail.
Somebody had asked me about the schematics for my divergence meter project. All the design files are in the mercurial repository on Bitbucket, but here’s a high-resolution capture of the schematic for those unable or unwilling to use Eagle to view the schematic: dm-rev1.1.png. Be advised that this version of the schematic does not reflect the current design, as I have not updated it with a FET driver per my last post on this project.
On the actual project front, I haven’t been able to test the FET driver bodge yet. Maybe next weekend..
I got some time to work on the divergence meter project more, now that the new board revision is in. I assembled the boost converter portion of the circuit and plugged in a signal generator to see what sort of performance I can get out of it. The bad news: I was rather dumb in choosing a FET, so the one I have is fast, but can’t be driven fully on with my 3.3V MSP430. Good news is that with 5V PWM input to the FET, I was able to handily get 190V on the Nixie supply rail.
Looking at possible FET replacements, I discovered that my choice of part, the IRFD220, appears to be the only MOSFET that Mouser sell that’s available in a 4-pin DIP package.
I recently purchased a new laptop computer (a Lenovo Thinkpad T520), and wanted to configure it to dual-boot between Windows and Linux. Since this machine is to be used “on the go”, I also wanted to have full encryption of any operating systems on the device. My choices of tools for this are Truecrypt on the Windows side, and dm_crypt with LUKS on Linux. Mainly due to rather troublesome design on the Windows side of this setup, it was not as easy as I might have hoped. I did eventually get it working, however.
Admonishment Truecrypt was https://www.grc.com/misc/truecrypt/truecrypt.htm in 2014, but still works okay.
I recently pulled a few SDR (133 MHz) SO-DIMMs out of an old computer. They sat on my desk for a few days until I came up with a silly idea for something to do with them: rewrite the SPD information to make them only semi-functional- with incorrect timing information, the memory might work intermittently or not at all.
Background My sacrificial SO-DIMM Most reasonably modern memory modules have a small amount of onboard persistent memory to allow the host (eg your PC) to automatically configure it. This information is the Serial Presence Detect, or SPD, and it includes information on the type of memory, the timings it requires for correct operation, and some information about the manufacturer.
I just enabled SSL on this site in a fit of paranoia. It shouldn’t cause any problems, but please let me know if you notice something that’s broken. Normal browsing shouldn’t be affected, but site login is forced to SSL. My (self-signed) certificate has SHA1 fingerprint 6c:e4:77:91:e8:59:f8:d1:fd:ea:cf:87:6b:af:ce:3b:19:be:fa:b5.
I’ve been able to do some more work on the divergence meter now. The university’s labs made short work of the surface-mount soldering, but there were some hitches in the assembly and testing phase, in which I discovered some of the part footprints were wrong, and it was a bit of trouble getting the programmer working.
I was able to work around most of the bad footprints, but some of them were barely salvageable, since the through-holes were too small. I was able to drill them out on the drill press in the lab, but that left me with very small contact areas to solder to, so I had a few hideous solder joints.
Working on mkg3a upgrades for libpng more, I was getting unusual crashes with the gnuwin32 libpng binaries (access violations when calling png_read_int()). It turned out that the libpng dll was built against an incompatible C runtime, so I had to build static libraries. With the official libpng source distribution (and zlib), building static libraries was reasonably easy. Using the MSVC make tool in the libpng source tree, I first had to build zlib. The default build (for some reason) doesn’t build the module containing _inflate_fast, so I had to add inffast.obj to the OBJS in zlib/win32/Makefile.msc (this manifested as an unexported symbol error when linking a program against zlib).