Category Archives: Sandbox

JSON over Stdin/Stdout for small local components.

I’m looking at adding a local control capability to my little C++ based file and volume identifier tool. I’ve run into a number of small functions that would be well served by tools written in specific languages that have access to specialized APIs but would benefit from a local interface with somewhat decent performance.

Unix style text in/text out is limiting as the command/response format lacks structure and the performance (with one process start per request) is potentially unacceptable.

Adding in a command line switch that sets the tool into ‘json in/json out’ mode and keeps the program alive until the pipes drop or an exit command is received should address these issues.

Ideally, the stdin and stdout would transport UTF-8 data containing complete JSON entities…one as a request and one containing the complete response. This can continue until the hosting program sends an EOF or drops the pipes.

I’m wrapping together a very lightweight JSON generator/parser to support this effort and will be following that up with some testing of C++/Java/C# (and perhaps others) sub-process and pipe management coding. If all goes well, I should have a nice little approach for wrapping small pieces of code that need to run in a particular language but must be hosted elsewhere with decent performance and a robust communications format.

Taking a quick look at Mbed

A friend at work pointed me at Mbed devices for real-time end of line work. I’ve been involved in work that used 68hc11 processors for that sort of thing (getting very long in the tooth) and I’ve looked at using AVR parts (cheap, dip packages and decently capable). PIC controllers also seem to show up frequently (but the small look I’ve taken at the PIC architectures doesn’t make me happy).

These are ARM Cortex-M0 devices with what initially looks like pretty decent support. As an outbound, real-time controller and a back-end in something like an RPi (for home stuff) these might be a better solution than the AVR chips.

I’ve had good results from building systems with the ‘quick twitch’ responses pared down to the smallest size reasonable and baked into small controllers and keeping the higher level control (that doesn’t have the real-time response requirements) back on a linux or windows based system. This keeps the complexity in a location where powerful development tools and more capable processors reside and makes development much simpler.

I’ve been looking at CAN as an intermediate communications bus for this sort of work as well. The SPI and I2C options work well for tightly coupled peripherals in the same voltage/signalling family but don’t extend well.

Ethernet is wonderful for larger scale coordination between components that are running relatively complete operating systems.

CAN splits the difference with a defined physical layer running differential signalling that provides common mode noise resistance and (probabaly…haven’t looked in detail) avoids ground reference issues. It is still low level enough to code directly to (unlike TCP where the stack gets a bit involved to do things right). It supports quite a few devices on a single connection and has a decent access arbitration mechanism.

I haven’t bought any parts to try playing with this yet, but it seems promising.

System Level Design and FPGA Options

Reading a few things last night there seem to be new tools that work at a more abstract level than VHDL out there. Mentioned were System Verilog, SystemC and Handel-C. I’ll have to take a look sometime in the future. For the moment I suspect that VHDL will more than meet my immediate needs.

I’ve also been looking at FPGA choices a little bit. The Spartan-6 on the breakout board I’ve got looks about right for my initial sandbox work. I’d like to find smaller, larger and newer options for ongoing things…ideally something that is inexpensive enough to use as glue/support logic and can be worked with without needing a custom PCB. It is also clear that the Spartan line is getting old and that Xilinx is shifting FPGA focus towards newer designs such as the Artix

I’d like to look a bit at the CPLD end of the spectrum as these seem to promise smaller, cheaper glue options, perhaps even with less demanding packaging choices. Wondering if Altera has interesting options there…

VHDL and CAN books…

Looking at books on VHDL and CAN bus. My Xilinx Spartan 6 board arrived a couple of days ago and now I need to get to the point where I can make real use of it. I’ve been looking for books to give me more depth in VHDL and a bit more context on CAN and here’s what I’ve come up with…

I’ve found two basic types of books in this area. There are those aimed at  people with little or no digital design experience that spend lots of time explaining the basics of digital logic design and synchronous systems and those that work at taking someone with significant digital design experience and getting them up to speed on how to realize designs in VHDL.

I’ve done enough digital design in SSI/MSI/PALs back when I was doing that sort of thing for work that I’m looking for the latter sort of books and my list below reflects that.

Seems like a decent book on logic synthesis in VHDL. Less expensive than the other broad based book I located but seems a bit narrower in scope.

.

.

.

This book looks more comprehensive than the one above, but it is also more than twice as expensive. I’m thinking that I may get VHDL for Logic Synthesis for now and buy VHDL for Engineers later if I find I’m looking for more information.

.

.

This looks like the best CAN bus book I’ve seen so far. Another rather expensive text, but if it can give me a decent feel for how to best use the facilities CAN provides then it will be worth the money.

I can see a number of different ways to implement a protocol using the functionality that CAN makes avaialable but getting advice on what has worked for others will make it more likely that my first shot is sensible and effective.

.

I ran across this book after I saw the earlier ones (and in the context of the following volume that appears to provide more advances style and implementation approaches). I suspect this is likely a decent book…perhaps with more introductory digital design content than I’d generally prefer though. I may look closer at this one at some point.

.

.

I find myself frequently looking for books that go beyond the basics of syntax and function to discuss best practices and effective usage (and books with ‘effective’ in the title often seem to offer this sort of advice). This looks like an interesting book on the VHDL front from that perspective. I’ll likely buy one of the more general volumes above and read it through first, but once I’ve covered the basics, I’ll likely wind up here to try to refine my understanding and usage.

Just ordered an FPGA breakout board

I was reading a book on VHDL (I’ve had some contact, but long ago and somewhat tangential) last night.

I just ordered a Mojo v3 FPGA Development Board  from SparkFun so that I can do some more tangible experimentation with soft hardware 🙂 

It appears that Xilinx has a new version of their toolchain for the Spartan 6 FPGA that is on this board that works on windows 10. I’ll have to download the software and follow their instructions tonight or tomorrow night. I don’t have any specific project plans related to the board at the moment but for $75.00 or so it presents a great opportunity to play with VHDL on a real target.

I’ve been running into a few cases lately where it would be helpful to be better versed in VHDL and for home projects I can see many places where programmable logic would be superior to an embedded controller.

Looking at CAD Options for 3D Printing

Watching some training sessions for Fusion 360. I’m probably going to finally try to commission a RepRap this winter at some point. A co-worker has a prusa i3 and recommended Fusion 360 in start-up mode (free to use as long as you’re not making significant money) as a good tool so I’m going to see what I can learn about putting things together with the tool.

FreeCad has also been recommended and I’ve grabbed a copy. Fusion seems more capable and so I’m inclined to start there. Blender is also something I’ve played with…more for artistic than engineering work though. It is also on the list, but likely behind a practical cad tool at this point.

As a software engineer, the open source tools appeal quite a bit as they’re a possible place to make enhancements to the tooling over time and a way to look at the internals as well as the UI side. They’re on my list and I’ve grabbed the git repos for both tools but at the moment I’m looking more for an overview of the state of the art rather than internal details and I need to understand what current practice looks like before thinking about new features.

I would love to enable use of my HTC Vive with these tools at some point. Being able to walk around a shape or assembly in three-space and manipulate it would be pretty interesting. I suspect it could make some of the manipulations that are of interest much easier for less experienced users.

Full file ID API in Win32

In order to get the full ID of a file in Win32 the GetFileInformationByHandle  returning a BY_HANDLE_FILE_INFORMATION which contains 64 bits of file ID (and the volume id where the file resides) is a start.

The GetFileInformationByHandleEx  with FILE_INFO_BY_HANDLE_CLASS of returns FILE_ID_INFO which provides the full (potentially) 128 bit file id as required for ReFS.

I’ll likely provide support for both of these shortly, likely using C++/CLI to simplify the interface.

Given these two pieces of information it should  be much safer to clear out duplicate files as various sorts of links and mount points will still show the ultimate file identity properly and avoid deleting apparent duplicates that are really just aliased paths to the same file.

 

More progress on the controller front…

I’ve picked up some representative AVR based boards to supplement the ARM based RPi board I have around the house. Between the two, I expect that a pretty capable solution can be put together. The ARM running Linux and providing high level business logic and user interface while the AVR boards provide hardware level control and real-time ‘fast twitch’ capability.

The ATMega2560 is a high-end device with generous resources in pretty much all relevant areas. It is quite a bit more expensive than the lower tier parts and I’m inclined to look at a finer grained approach initially.

The ATmega328 is the ‘common’ controller in this line. This is the part that powers most of the Arduino line of boards. It has relatively limited resources but with multiple timer/counters and an I2C link should suffice for most of the sorts of tasks I’m looking at. This is a fully featured board, but I have a package of five free-standing boards on the way. These boards run less than $5.00 a piece but have no integrated USB capability and thus need either an ISP programmer or a separate USB to RS232 converter to load with code.
The last three small boards I picked up for sandbox purposes are ATmega23U4 boards. These use the AVR controller that has built-in USB capability. I’m very interested in what can be done with this support as it should allow coding of various sorts of USB devices using the native hardware on the parts.

I’ve had these pololu stepper controller break-out boards sitting around for some time now. They’re destined for a RepRap machine (assuming I ever find the time and budget to finish buying components). They’re H bridge, step and direction style stepper controllers with an Allegro A4988 device. I’m expecting to push these together with a stepper motor and at least see it responding to commands in the near future.

Once I’ve got a stepper running at least a bit, the next step needs to involve more mechanical parts…probably makes sense to get the real RepRap implementation rolling at that point.

I am a bit curious about ARM based possibilities…something like a cortex M0 with a free/open source RTOS running on it. This would certainly allow for more to be done with fewer independent controllers…though the relevant pieces remain to be worked out. I’m suspicious that the RPi SOC is too poorly documented to work here…would need  a lower end, more dedicated part with a board support package for something free and capable…more to come.