We have relocated from McLaren Vale to Dayboro (Brisbane). We are available for subcontracting and will be developing a testbed to use for the upcoming flood of multicore devices inbetween contracts.
Our previous projects on Freescale, NXP and Energy Micro hardware are complete. We bought some Atmel boards a few months ago, but did not have a chance to open the boxes during a rather ambitious renovation. That is now also complete!
Basic investment. Software and hardware test platform for future debug infrastructure. This is about as much as you need to be able to run most of the software we plan to write to assist in debugging multi-processor hardware which includes built-in instrumentation. The host will be Apple for the graphics, which for some is unfortunate, however, we cannot support everything or all flavours of Linux and still expect to be able to drive all your colour printers.
Always the start of a bitter debate that degenerates into the realm of politics or religion. We have a logic analyzer and digital oscilloscope, but don't expect all our customers to buy what we also struggled to justify. JTAG is essential to debug all processors where the address and data busses are no longer externally visible, or where a processor runs out of cache. The problem with most of the lower-cost tools, or the ones we run is that the link is not active while the core is running at full speed. So, if you want to debug a running system, anything real-time or multiple devices, you will require some form of instrumentation and another to capture the data. Once you have data, you need to display this as a timeline. Yes, there are tools, but do you own any of them, or did you purchase any of them at the quoted list price? If you have an academic licence, you don't need to reply to any of this. We have a few more years left in this game, but not the money to divert into tools, so we will migrate to free or low-cost tools, readily available hardware, devices without complex anti-copy schemes, and something that hopefully has mass appeal to spread the load.
For architecture, the choice is simple — ARM. You will need some compelling argument against this choice. We have been through the PowerPC, MIPS, M68000 and a host of others, but the performance of ARM devices is sufficient for what we intend to do. There are unfortunately differences between 32-bit and 64-bit ARM devices, but most folk will not have to delve that deeply or write assembler. For microcontroller work, 32-bit is convenient with thousands of devices based on the various Cortex cores. We have programmed many of these, but will move to Atmel for all our own work for the foreseeable future (until the next one comes along!). For 64-bit, the choice can only be made once silicon is actually shipping. From a debug viewpoint, that seems to favour one with a FPGA alongside. The two choices are Altera and Xilinx, neither shipping actual devices yet. Altera looks better on paper as they have a lower cost version of the ARM DS software, while Xilinx has their own version of compiler and debugger.
In summary, for 32-bit or 64-bit, we are choosing ARM.
Freescale and NXP have merged, as have Spansion and Cypress. Energy Micro was acquired by Silicon Labs, Texas Instruments lost us with the Sitara software debacle, and so the list goes on. We are a small player, and suspect you might be the same, otherwise why bother to look further from a “one-man-show”? Atmel has been consistent for the last ten or more years that we have been using their devices, and their software offering is a free download which is as good as the commercial software we have access to. It only runs on a Windows platform, but we do the major editing and cleanup (or printing) on an Apple Mac. Unix-like tools are readily available and the printer works, even if you have to print from Xcode. Most time will be spent on the debugger during development, so the Windows platform is fine. Debuggers are normally supplied with Atmel boards, but spend the extra $100 and get a rebranded Segger probe. If you don't like the 0,1 inch pinout connector, make a small interface card or buy one. Be aware that the rebranded probe is designed to only work with Atmel devices.
For our 32-bit work, we are going with Atmel as function is more important than price at our volumes. The devices are competitively priced anyway, and small quantities can be purchased. The evaluation boards are roughly the same price as other vendors, but you get full datasheets, unlike Broadcomm which is used on the Raspberry Pi. We will also be writing bare-metal code. To toggle outputs on a Linux platform involved getting too much other stuff running. For Ethernet connectivity, the new microcontrollers are fine without a full Linux stack. Plenty of open-source stuff is available.
The initial requirements will be no more than the two Atmel V71 Xplained Ultra boards. We will not be doing much in the way of wireless, as we do not have that background or test equipment. We have a simple LeCroy logic analyzer that understands some of the serial protocols, has 16 channels and runs at moderate speeds. There is a graphical display via a PC, but we cannot access the waveforms in software for our own trace display software or putting into a spreadsheet for validating real-time schedules. For testing software on the V71 boards, we write snapshots of a timer into an array in memory that can be examined over the debug interface or written to the SD card when the buffers are full. We also intend sending the data out over SPI to similar boards if the SD card is a problem on a particular target (due to timing). Atmel has example code for SPI which assumes two boards back-to-back — one a master and the other the slave. Testing out this infrastructure can use two boards in the above configuration. For multiple targets, multiple SPI ports will be required, and here the upgrade can be a FPGA. The idea of using minimal pins for debugging constrained targets was taken from Measuring Execution Time and Real-time Performance: Part 1 and written by David Stewart (PhD in real-time systems). There are several articles which he wrote for Embedded Systems Conferences and papers, so none of it is under threat of patent infringement. You simply write out some marker via a serial port that is captured by an external device for analysis later.
We have used many commercial kernels in the past — each with a steep learning curve, expensive instrumentation options and the customer unwilling to pay for climbing the learning curve. The next project is always the same. We have written several small kernels ourselves, but there is little to gain from such an exercise when you need to generate documentation or testing schedules against freely available kernels. There are a lot of free kernels and we used to not say what we were using to avoid possible lawsuites, but FreeRTOS seems to have solved the infringement problem with bloodthirsty legal beings on their doorstep (many came to Australia on trivial punishments under the English legal system). We will take our chances with FreeRTOS, who supply source code for free (charge small amounts for documentation). Atmel often integrates FreeRTOS with their example code. For commercial trace over FreeRTOS, see Traceanalyzer.
For more information on FreeRTOS, see their home page.
Trace collection varies from a snapshot on every branch instruction (roughly every six instructions) to a leasurely 1ms sample over a serial interface. In highspeed logic analyzers, watching a continuously updating screen at target speed is impossible. You need to be able to scroll through captured data at a pace that you can identify behaviour. If the data is encoded, which is most likely with embedded instrumentation, a host will have to present that in a format that makes sense to a developer. This is essentially a database (perhaps a flat file of sequential records) and graphics exercise. While the screen graphics is not too hard, being able to move the channels around or extract portions for documentation purposes is difficult. Here, we would like to be able to generate LaTeX graphics for eventual inclusion in documentation as opposed to a screen capture. The chosen platform is an Apple device. We have a laptop and a small server (plus outdated phone and iPad) so will start with those. The Apple Developers' membership in Australia is A$149 a year, which has been worth it. Xcode is a very good environment for testing and even printing other source code. Distribution of software will be in source form where allowed, and not through iTunes. If there is any non-distributable code, we will advise how you can get it. We have not even started, but will flesh out some specs later. You can also have a look at a rather dated document I wrote some time back — Trace and Profile Survey (PDF) 684 kBytes.
The “Tales From the Woods” are about to be retired. Future news postings will be about progress on the debug infrastructure. This will hopefully all be open-source. It is an additional tool to validating your targets, but will not get you out of any legal trouble, even if you tell us how you intend using it. Source code links will appear several weeks after initial testing.
Commodities and China news not for the timid during September, traditionally a jumpy time for brokers. See Miners smashed in market rout, Sydney Morning Herald, dated Sep 29th, 2015.
For embedded developers working on vehicle control units, some cheating can cost your company, particularly when legal folk in the USA have not had much in the way of filling the Christmas bonuses up to now. Another chance to stand up for principles. See Volkswagen to recall and refit up to 11 million cars affected by emissions software scandal, on ABC News, dated 29th Sept, 2015. The share price took a major hit, fines could be in the tens of billions of dollars, plus the CEO left the company amid allegations of fraud.
Always in the fine print at the end! If there is any hardware to act as a small logic analyzer, then that will be where we will take your money in exchange for hardware. The rest of the software will be open-source, and possibly even the hardware. It will also help with our multiprocessor efforts, but we hope to exchange code with other developers in similar fields, or to at least spread the load. We don't have a lavish lifestyle, so the amounts we take will be less than the leakage that occurs unnoticed on many credit card syphons. Pricing much later, but if you are cheaper, then we will rather buy from you as long as we can manipulate the recorded data.
Brisbane South Bank — Riverfire 2015, 26th Sept. Photo taken by Bruce Clark. A really well organised event!
© 2015 — Second Valley Software Pty Ltd. All Rights Reserved