About Second Valley Software

We are based in McLaren Vale, south of Adelaide, in South Australia. When the company was registered in December, 2010, we had over thirty years of embedded- and Unix experience. We are interested in any real-time embedded software for industrial applications on ARM targets for contracting, rebadging or prototype manufacturing. We cannot accept consequential damages, so your production would need to cover that.

Our previous embedded projects always required a decent HMI, something not readily available. We believe that tablets will end up in industry as replacements for expensive industrial terminals that cost much more—each with their own unique development software. Any display more than US$500 will probably become endangered. Tablets are no longer science fiction, but programming them with SCADA applications is going to take a bit of effort.

Previous language efforts were predominantly C, but shell scripting, TeX, SQL, JavaScript and a host of others were picked up to help ourselves. Our aim is to integrate targets with a Linux server; for visualizing process data or productivity, and for small project teams to save/ access the volumes of documents that are created in any design projects. We currently use an Apple server for our internal work, however, for a local cloud or cluster, Linux would be a lower cost option for customers.

We will move to structured publishing after almost ten years of LaTeX. We would like to migrate to a more portable format between web- and print output, but to maintain control over bibliographies, cross-referencing, and output that looks better than a thesis. Web-based storage with the option of high quality printed reports would also be handy. Over the following months we’ll put up content using the converted output. Whether we go thin- or thick client for a tablet will depend on how much OpenGL will be required for visualisation.

Take a look around this site—if anything is of value, contact us, particularly in any of the following areas:

Bare-metal embedded

We have close to thirty five years of embedded programming experience on a variety of targets; most recently ARM from Freescale and Texas Instruments. We have also started to dabble with the TI C28xx DSP for digital power supplies and LED lighting applications. Still early days for that though.

We have purchased test equipment this year as we moved back into hardware development. Targets will be ARM and DSP for deeply embedded devices. We will start with simple Freescale Kinetis and Texas Instruments Luminary Micro parts for uni-processor work where we have plenty of flexibility for I/O, and then use the Concerto or Hercules ARM/DSP devices for motion control or more interesting projects. We have a Concerto board, but have not had enough time to test the ARM and DSP interface, however, it is a very interesting product for any distributed power application or machine builder design. It will be programmed in C, so unfortunately for end-users, it will not have ”point and click“ software for configuration. It also means that you can do complicated things like compensate for gravity for empty return bin loads and self tuning. The ARM will be used for communications and scheduling, as well as debugging. In all our targets, a certain amount of processor overhead is dedicated to debugging, as there are certain things an oscilloscope or logic analyzer cannot see in an industrial setting. End-users are not interested in learning how to debug at the bits-and-bytes level anyway, and definitely not when their production is standing. The little SD cards in each target will tell us the path that was taken before the terminal one (hopefully we can read the card!).

Structured Publishing

For structured publishing, we want to take test results or acquisition data and put it into a format that can be printed. This will involve XML, TeX and a host of open source tools. We dabbled with Scribus, but the LaTeX input was really for a single page, and did not want lots of format files in front of the content. We also could not bring in partial table of contents, or spill pages of TeX content over the document. This is going to have to wait until someone wants to fund it, or when we have to generate decent manuals for our boards.

We want to easily convert between printed and web-based output using CSS plus XML to modify LaTeX input; database development for tracking bibliographies, acronyms, and cross-referencing across documents. We have dabbled with Photoshop, GIMP and Illustrator. We had plans to migrating to Abobe tools (InDesign) or Scribus at some stage, but LaTeX will be used for our documentation for the rest of 2012. Previous graphic output was in LaTeX which looks good but takes too long to generate. Lua, XeTeX and several other developments are gaining some traction, but the XML side has sadly taken a back seat with LaTeX. Programming in TeX is simply too painful for a casual user, and trying to do things like partial bibliographies is out of the question in TeX if you don’t have a sabbatical. Adobe’s Framemake does not look like it is getting a lot of development either, but from the bottom of the planet, things do look different.

Legacy Documentation

For legacy documentation we mean the unstructured text files lying around in numerous directories that are not cross referenced or indexed. We take as much as we can and convert it to LaTex, which then gets converted to PDF. We use BibTeX, GlossTeX and some custom written tools to split out items of interest for formatting (revision tracking etc.).

We would like to develop a Web front-end to collections of legacy documentation on a local server. We have enough to help ourselves, but the product is a bit raw and not ready for prime time, and certainly not for any casual end-user. A lot of work is required here, which involves XML and a database with replicated disks.

Apple Mac

We did a fair amount of programming on the iPad. The API is a couple of thousand pages long, and there are several thick manuals that need to be read. It was fine for simple projects, but our target market is industrial automation. Getting an app approved to download onto an iPad connected to one of our custom controllers for each two week job does not suit us. The Mac has a superior graphical interface to Linux and Windows in our opinion, and due to the OpenGL base, we are happy to invest in displaying automation data in a logic analyzer or oscilloscope format. Anyone familiar with expensive SCADA packages will be pleased to see that open source will become the norm, and standard platforms will be cheap. There is no nead for the embedded targets to cost as much as automation vendors charge, and that is where we hope to help our customers.

We used Objective-C and C on an Apple MiniMac server. We also like the Unix style tools and file system on the Mac platform. For end-users, the Apple platforms ship with full development software, so there are few surprises later on compared to Windows PCs. At US$999 for a server, the price is not bad. We are not sure what the Apple product line will look like for servers, as the blade server range was discontinued in 2011, and the large boxes are not that attractive to the company with over $100 billion in cash from iTunes, iPhones and iPads.

We will stick with C/C++ and Linux for future software intensive projects. Although the software is tested and debugged on the Apple Xcode platform, we make sure the same code runs under Linux. A short journey through this site and you will see how many hardware platforms were abandoned by their creators with us holding the baby. All these companies who want to own some language when C/C++ are really fast, are looking after their own interests (Oracle with Java, Microsoft with C#, Apple with Objective-C and Swift, etc).