True enough, but ... why not use a keyboard encoder rather than an MCU?


Yes, there are things that aren't on THIS board, but, generally speaking, it's not likely a board with CAN will, after designing a board, and after omitting the GLCD, cost less than this one.


Not quite ... that may be trial, but it's certainly not testing.


Firmware issues can be worked, to large extent, on a PC. Hardware and hardware/firmware integration issues, well, not so much. Please understand that I don't disagree with much of what you say, Per, but there's a distinct limit to the relative usefulness of PC-based tools. They may work fine for debugging your 'C' code, and for debugging your ASM, but, they unfortunately lack the ability to exercise firmware in an environment wherein there are actual external signals that occur at timings not readily simulated in a PC. I wish it weren't so, but the simulators are just to primitive, and the debugging tools are too limited in scope. The simulations are typically based on instruction cycle timings rather than hardware timings, and I've seen no simulators that do nanosecond-level timing analysis on MCU simulations. Just give ModelSim a try with an MCU core in FPGA sometime with external peripheral logic generating asynchronous signals to the core. There will be problems, not all of which are with the design of your system, that you'd never encounter in a PC-based debugging environment, yet you'd quickly encounter them in a hardware environment.


If you want to give your code a trial on the "real" hardware, e.g. if you want to use SEEPROM, or any other feature specifically included on the development/trial board, you can do it on that board, patch it on that board if need be, and stimulate it with external signals. You can't do any of that on a PC in simulation. I wish that weren't the case, but, sadly, the folks who provide simulators generally aren't very thorough. PC-based debugging tools are pretty limited in scope, i.e. they don't really support debugging the hardware. How can you build confidence in hardware that has only been debugged in a simulator on a PC? I submit, a low-cost board like this one, and I'm sure there are others just as capable, allows you to do that. If you examine the available 805x, AVR, or PIC boards of the same sort, you'll find them wanting, and more costly, too.


The majority of the published "reference designs" I've tried didn't even work properly. Often they're designed to demonstrate one specific feature and completely neglect the remaining functions. That was one of the problems I encountered with early ARM circuits.


I think you're missing my point. I agree that an OS like LINUX is inappropriate for the majority of embedded tasks. However, it's not inappropriate for hardware/software integration trials. I'm not convinced that this particular board is the ideal, and I'm still not convinced that it will replace all the benefits one can derive from PC-based tools, but it allows one to do things no PC environment can do. In that sense, it's just a means to an end, and LINUX, because it's open-source, provides not only the means to perform trials on the various hardware features and the underlying code, just to ensure their suitability for a given task, but also the means to develop confidence in the specific interactions between those hardware/firmware interaction problems no PC simulator can emulate.


Likewise, it enables one to do things no PC tool set alone can do. Cross-compilers do work, but the debugging/simulation tools are generally provided as an afterthought, doing crude simulation of a core based on instruction cycle timing rather than actual hardware timing constraints.


I understand why you find this curious. I'm not advocating that one should deploy the larger ARM in a target application. The board to which I referred is interesting to me because I use boards like that to perform proof-of-concept, which is one thing I often do. My emphasis on using this sort of board rather than PC-based tools is not because a PC-based simulator couldn't do what's necessary to simulate the hardware/software interactions, but because a PC-based simulator, as provided by various vendors of PC-based development tools, wouldn't do it, because the developers of that software don't approach the problem from the proper perspective. They're building an add-on for a cross-compiler, not an MCU-specific simulation suite that actually simulates the low-level behavior of the hardware. That would require a modification of their simulator for each and every MCU version, and they're just not that interested in providing such a tool.

The developers provide a tool capable doing some simulation because the marketing guys told them they have to have that feature. The marketing guys aren't smart and sophisticated enough to realize what a difference it makes having a real, low-level simulation of the core on which the code will be expected to run.

For companies like KEIL, the simulation and debugging are just a means of putting a check in the box on the list. They see it as a way to get past the purchasing department, and couldn't care less whether it is really helpful in getting the job done. Once deployed, management won't let the programmers "fix" it, since it's already "out there" and generating sales. The tech support guys, then, are doomed to spend the rest of the product's life either apologizing for, or lying about, the product.

RE