| ??? 08/11/08 16:21 Read: times |
#157402 - It's probably best to check with the maintainers Responding to: ???'s previous message |
I'm sure they'd be glad to hear from you! Tell 'em I sent you.
Per Westermark said:
I do have a current ARM7-based (LPC2366) hardware that is currently in production.
The firmware contains a huge amount of configuration options to allow different actions to be performed depending on different stimuli. But I can't teach the current firmware all kinds of logic actions, filtering and data analysis, so I want a customer (normally not an end user, but someone who buys 100-1000 volume or more) to be able to specify their own actions. Maybe it's just a question of choosing the correct ARM. If it was just logic, then I could implement PLC ladder logic or similar, but I don't want just logic but want the user to be able to add filter logic, numeric analysis of ADC data etc. TI once made an ARM7TDMI with a built in DSP. By now, I'd bet they make many different ones. Maybe that deserves a look. I do not have the slightest need for emulating any existing processor. Just to have access to a good GP programming language that is reasonably commonly known, and that is very frugal with RAM. This includes quite a lot of procedural languages, but excludes most object-oriented languages. Java, for example, can consume huge amounts of RAM even for very tiny applications.
Having the host processor run with a MMU would protect its data from being overwritten, but would leave a lot of other problems open. If run with an embedded RTOS, the customer extensions would need to run in individual low-priority tasks, and the main application would have to export quite a lot of internal symbols, requiring the need for dynamic linking. The host processor is not meant to be big enough to run Linux or any other full-blown OS, where the customer just adds one more stand-alone application to run. It is - and is expected to continue to be - a single-chip I/O processor, where all processor pins are spent connecting to existing hardware. It's just that I want to give it the ability to be configured with advanced filtering/decision making. It should be noted that the processor needs hard real time, and not all RTOS supports dynamic linking or running of free-standing processes. The currently used processor is a LPC2366 (in total 58kB RAM), which is the reason why a major criteria is a small RAM footprint. The processor may potentially be changed into a LPC2387 (98kB RAM) or possibly, but unlikely, a LPC24xx chip. But only if it can be shown that such a component switch will result in a very wide acceptance to pay more for the unit. Besides the redesign costs, it takes huge amounts of money to certify a unit in a large number of countries. An in reality, customers are expected to pay less for new products, or to get more features for the same price. The possibility to run plugins should be seen as an optional extra, not as a primary feature that may have a significant priority when it comes to the hardware design. If the target machine had been running Windows or Linux, I would probably have looked at Java, JavaScript, Lua or something similar, but this is a quite small guy that may in some situations spend a significant amount of time trying to sleep, to conserve power. I don't know much about JAVA. How frugal is it with its memory resources? A software-only solution means that the production costs are not affected, and that licensing costs for the extra capability can be negotiated with an interested customer.
The I2L interpreter sounds very promising, since it is likely that it was designed for ease of porting and for a good execution speed in the host hardware. That not too many existing customers (probably none) knows XPL0 is a bit of a gotcha, but the advantages may win over the disadvantages. The XPL0 home page didn't mention anything about I2L, and you had to more or less know what to look for in the language manual. It's my guess that the I2L fell away when CPU's became larger than the intermediate architecture, as the I2L instructions became a subset of 68020 or Pentium. If you contact Loren Blaney (or any of the other "actives") of the Denver Area 6502 users' group, he can fill you in. There may even be a tool for translating between 'C' and XPL0, though I'm not sure it goes in both directions or in which direction it translates. In my view, it would be useful to be able to translate in either direction, so code can be written i 'C' and converted to XPL0 for final debug, and written in XPL0 and then converted to 'C' for informal verification or whatever. It "sounds" to me as though this might be an avenue for you to pursue, as the I2L code is normally quite compact, and the I2L interpreter is said (by others) to be quite straightforward to generate. I mention this because there was an earlier mention of BASIC, which has often come up in discussions regarding XPL0, and XPL0 has always "come out on top." BTW, the purpose of the XPL0 compiler, in its day (1978 or so) was to allow a larger machine to be emulated on a small machine (6502 in this case), making the generation of powerful and useful programs easier without demanding huge resources. An OS for the 6502 was written in XPL0 and published (sold, though I don't know how widely). I found it very useful and effective, myself. The I2L code was quite compact, and the compiler apparently was pretty good. Some decades have passed since the compiler was written, and it has surely evolved considerably. I've never been a fan of HLL's for small systems, so I am not a good source of information about the details. I did write in my original post "unless someone can point at any good C compiler that can generate code for an abstract machine", thinking about this kind of solution, even if I would have preferred a C compiler. RE |
| Topic | Author | Date |
| Virtual or existing architecture for emulation | 01/01/70 00:00 | |
| Additional info about host/usage | 01/01/70 00:00 | |
| How about MIPS? | 01/01/70 00:00 | |
| VHDL | 01/01/70 00:00 | |
| take a look at the content | 01/01/70 00:00 | |
| I think 8 or 16 bit is optimum | 01/01/70 00:00 | |
| Maybe you should start with an ARM chip | 01/01/70 00:00 | |
| I2L sounds interesting | 01/01/70 00:00 | |
| It's probably best to check with the maintainers | 01/01/70 00:00 | |
| Doesn't seem to be a C to I2L | 01/01/70 00:00 | |
| The LLVM Compiler Infrastructure | 01/01/70 00:00 | |
| Since there's help available ... | 01/01/70 00:00 | |
| With the low price of 8-bit single chip MCUs... | 01/01/70 00:00 | |
| Slave processors not an alternative | 01/01/70 00:00 | |
| Users | 01/01/70 00:00 | |
| Probably debugging on PC | 01/01/70 00:00 | |
| Are you really going to do that! | 01/01/70 00:00 | |
| Existing building blocks helps | 01/01/70 00:00 | |
It hasn't been done for you but ... | 01/01/70 00:00 | |
| When I was in school ... | 01/01/70 00:00 |