Previously published
This article was previously published on lhexapod.com as part of my journey of discovery into robotics and embedded assembly programming. A full index of these articles can be found here.
Here’s the source code to the 64 channel ATtiny2313 servo controller. Note that you’ll need to use up to 8 CD74HCT238E, or equivalent, demultiplexer chips and that you can adjust the number of servos that you can control in steps of 8 using as many or as few CD74HCT238E chips as you want.
Eric Lippert has an interesting blog posting (here) on how sometimes you can be so focused on fixing the bug you fail to step back and take a better look at the actual problem that you’re trying to solve.
I’m guilty of this and, with me at least, it doesn’t only apply to bug fixes. Sometimes I can become overcommitted to a design to the point where I don’t recognise that it’s just one design option I treat it as the only design option.
Previously published
This article was previously published on lhexapod.com as part of my journey of discovery into robotics and embedded assembly programming. A full index of these articles can be found here.
I’ve been experimenting with the servo controller that I developed for the ATtiny2313 here and the demultiplexing chips that I mentioned here. The result is a 64 channel servo controller that seems to work pretty well. Right now I haven’t breadboarded all 64 channels, I have two of the CD74HCT238E chips connected to the ATtiny but I/O pins and he firmware would drive 8 of them if they were connected to give 64 channels.
There’s a race condition in the service shutdown code which is most likely to show up if there’s an exception thrown from your implementation of ContinueService(), PauseService() or StopService() but that could show up during any service shutdown sequence.
This race condition is present in all versions of the Service Library and so far has only been reported by one client. A fix is available, please contact me directly if you need it, or think you need it.
There’s a bug in all releases of our performance counter library that may cause the creation of an instance with a name that has been previously used as an instance but that has been released to fail by connecting the new instance to the previously released instance data structure.
The bug is in PerformanceDataBlock.cpp, the else if around line 167 in AllocateObjectInstance() should be changed from:
if (pInstance->NameLength == 0 && !
Previously published
This article was previously published on lhexapod.com as part of my journey of discovery into robotics and embedded assembly programming. A full index of these articles can be found here.
The jitters and general instability of the hacked together simple servo controller (see here) for the ATtiny2313 were, it seems, down to the fact that the internal clock wasn’t stable enough and this caused enough timing issues to throw the PWM off enough to jiggle the servo position around rather than hold it steady.
Previously published
This article was previously published on lhexapod.com as part of my journey of discovery into robotics and embedded assembly programming. A full index of these articles can be found here.
My progress has been slow over the past couple of weeks because a) I’ve been rather busy with other things and b) an order of components has gone missing in the post. The order contains some 4mhz crystals and therefore my server controller firmware testing has been on hold as I’d like to remove the potential clock instability as a potential cause of the controller jitters before continuing my debugging.
I’ve just spent a little too long trying to track down a bug in a mixed mode DLL that I’m building. The DLL exposes a set of entry point functions that are defined as taking a single pointer argument and lies to the application that hosts it so that the application can call it with various numbers of arguments. The arguments could change from call to call or from ‘session’ to ‘session’.
I’m currently wrapping a server’s client side API in an ATL COM object for a client. The COM object will be used to communicate with the server from managed code or VB or other COM compatible systems. It’s a fairly straight forward process as the original ‘C’ DLL interface client API was built with this kind of thing in mind and I’ve done enough C++ objects wrapping a ‘C’ API conversions in the past to make the whole process relatively painless and straight forward.
Well, I’ve finally done something that I’ve been meaning to do for a long time. I’ve written some non-trivial assembly language code. Up until recently I wasn’t expecting this to be embedded assembly, but it actually seems like a sensible way to get into this low level stuff. Programming an 8bit RISC microcontroller in assembly is considerably easier than trying to do something with a PC. The chips are cheap (as chips), the tools are free, there’s an active user community and the electronics required is relatively simple.
