Comparing "Modern" embedded chip programming languages? - Page 1
Forum section: electronics / general

author: westfw
author_rank: Super Contributor
timestamp: July 08, 2016, 12:13:11 am
content: I think I mostly understand the differences between "modern" programming languages like Python, and old languages like C.But I'm finding myself clueless when it comes to differentiating the "modern" languages. Would anyone like to compare:luamicro-pythonJava EmbeddedC#Other?These are all things that I've seen aimed at relatively small embedded systems (Ie ARM, ESP2866, etc.)

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 08, 2016, 12:34:31 am
content: looking at the reason of why a language is created may give some light. but in general modern language = managed language.

author: Signal32
author_rank: Frequent Contributor
timestamp: July 08, 2016, 12:45:25 am
content: What differences are you looking for ?The biggest difference is that lua & micro-python(which is python minus some libs) are scripting languages, whereas C# and java are compiled to binary bytecode that then executes on a VM. And recently MicroSoft has made it possible to compile c# programs to fully native, so you get a full native image ( like C generates ).Here is how compiling source code generally happens:1.Source code(text form, this can have syntax errors, etc) --->2.Intermediate binary format(some optimizations are done,there are no syntax errors here, needs to be interpreted in order to run) --->3.Native code(can be run directly by the processor, fully optimized).Yes, almost always C also goes through an intermediate step in order to simplify code generation on multiple platforms, but of course it's not going to be the same intermediate format as C# and Java.So basically lua and micro-python programs are at step 1 above, c# and java at step 2 and C at step 3.Between them are trade-offs of portability / speed / memory usage / ease of development and other things such as automatic garbage collection, better security, lower level access etc

author: ataradov
author_rank: Super Contributor
timestamp: July 08, 2016, 01:23:00 am
content: Quote from: westfw on July 08, 2016, 12:13:11 amAll are pretty pointless toys, unless you actually need user scripting in your product. Using them as a primary development tool is like using Arduino for real products. It may work in some cases, but not in general.You'll basically need more flash and RAM, so your cost will go up. You may save on development time, but it is highly unlikely since you will still need to bridge all the capabilities of your MCU into the virtual machine.EDIT: And finding people fluent in "embedded" LUA or Python is not and easy task. And you can't really explain to a typical Python developer why allocating a 1 MB temporary array is not going to work hereAnd if you actually need scripting, LUA is more suited for that application, if your platform has hardware floating point (double precision) support. Otherwise LUA will be super slow, since there are no integers, only floats.

author: Rasz
author_rank: Super Contributor
timestamp: July 08, 2016, 01:35:00 am
content: those were adopted for embedded for people with no understanding of underlying architecture of a platform they are working on (and often _any_ hardware platform whatsoever), basically web developers

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 08, 2016, 02:25:10 am
content: Is there such a thing as embedded Javascript yet? If not, then someone will invent it soon.

author: asgard20032
author_rank: Regular Contributor
timestamp: July 08, 2016, 03:11:18 am
content: I think there is a need for a new more modern language for microcontroller and for low level programming like kernel.This "new language" would of course be type safe, have smart pointer, not interpreted..... (add lot of other nice feature here).And I already see at least one candidate for such language : Rust. If only it could go more mainstream and be adopted. It is basically a language build for the same purpose that C currently fulfill.Other language mentionned, like python and lua and etc... could still be useful on a microcontroller, only if that microcontroller is one of those cortex 4 or cortex 7 (or insert other behemoth microcontroller here), and its running an RTOS, and that said language is only used in some thread that only manage logic, and not input/output. Of course, that said task (thread) should not use heap allocation, and should only allocate memory on its stack.

author: ataradov
author_rank: Super Contributor
timestamp: July 08, 2016, 03:13:04 am
content: Quote from: asgard20032 on July 08, 2016, 03:11:18 amYes, there is.Quote from: asgard20032 on July 08, 2016, 03:11:18 amDisagreeQuote from: asgard20032 on July 08, 2016, 03:11:18 amRust has a ton of overhead in a standard library and some language features.

author: asgard20032
author_rank: Regular Contributor
timestamp: July 08, 2016, 03:16:58 am
content: Well, i was not saying to use rust as it, but use it as a base/concept to get to what we need. My main point was that it is possible to get a modern low level language, and rust is one of the few that took that step. There is many thing in Rust that could be the foundation of other modern language.

author: ataradov
author_rank: Super Contributor
timestamp: July 08, 2016, 03:20:22 am
content: Quote from: asgard20032 on July 08, 2016, 03:16:58 amI absolutely agree. There is a number of features that are used daily in the embedded development, but are not standard.I'd really like to see language-level packed structures for interfacing external devices. Bit-fields with predictable/controllable behavior would be nice as well. Eliminating C headers nightmare would not hurt eitherBut creating a new language and pushing it into industry is really hard and I doubt it will actually happen. Banking industry still uses COBOL.

author: zapta
author_rank: Super Contributor
timestamp: July 08, 2016, 04:36:41 am
content: Quote from: ataradov on July 08, 2016, 03:20:22 amIIRC this is available in ADA. See the other thread regarding ADA in embedded environments.

author: ataradov
author_rank: Super Contributor
timestamp: July 08, 2016, 04:41:04 am
content: Quote from: zapta on July 08, 2016, 04:36:41 amNope, I'm not going to a marginal language for 1 or 2 features it may have implemented better than C. Especially given that all compiler let you do this with compiler extensions.The problem here is that none of the MCU peripheral will be described in ADA. It should be possible to generate those descriptions based on SVD files, but no such generator exist at the moment.

author: sleemanj
author_rank: Super Contributor
timestamp: July 08, 2016, 04:55:48 am
content: Quote from: Signal32 on July 08, 2016, 12:45:25 amErr, I dunno about micro python, but python itself is compiled to bytecode - admittedly on the fly, but it is, that's what the .pyc/o files are, compiled bytecode versions of the .py source.I have no real love for python, the tab/space centric syntax sucks ass, but anyway.( I think Lua is also compiled to bytecode and executed by a VM, but don't quote me on that, I'm only very loosly aware of lua's existence and that's about the extent of it, it kinda seemed like a language implemented because somebody wanted to make their own language to me, solving a solved problem )

author: rstofer
author_rank: Super Contributor
timestamp: July 08, 2016, 05:36:04 am
content: Look at Ada if you want a type-safe language suitable for embedded programming.http://libre.adacore.com/Oberon is derived from Modula 2 which is derived from Pascal. It is available for ARM.Pascal is available for 8051 and variants.I'll stick to C but I am looking at Ada as a language for my grandson should he want to work in an environment where it is used.In my view, none of the listed languages are anywhere near suitable for embedded programming.

author: Rasz
author_rank: Super Contributor
timestamp: July 08, 2016, 07:24:38 am
content: Quote from: Sal Ammoniac on July 08, 2016, 02:25:10 amsure, there are masters of IoT building stuff with nodejs on rasPeeover one minute to boot your 'app' is just a start of a long feature list

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 08, 2016, 08:12:34 am
content: Quote from: rstofer on July 08, 2016, 05:36:04 amwhich is pascal is suck. its syntax is a hybrid between <insert any modern language> and C with a pointless ";" havent seen oberon or modula but general rule is anything derived from imperfect will always be imperfect.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: July 08, 2016, 09:12:19 am
content: Quote from: Mechatrommer on July 08, 2016, 08:12:34 amThat would explain why C++ is a massive pile of shit then

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 08, 2016, 09:30:00 am
content: Quote from: donotdespisethesnake on July 08, 2016, 09:12:19 amno because ";" in C has a specific purpose, pascal tried to implement it in sporadic way. pascal is not derived from C but a random mix of a recipe from various languages. and C++ is not derivative of C, but an extension to it, imho.

author: ddm
author_rank: Newbie
timestamp: July 08, 2016, 09:52:31 am
content: Quote from: Sal Ammoniac on July 08, 2016, 02:25:10 amThere are several embedded JavaScript implementations available:V7 by Cesanta:https://github.com/cesanta/v7JerryScript by Samsung:https://github.com/Samsung/jerryscriptEspruino by Gordon Williams:https://github.com/espruino/EspruinoMuJS by Artifex:http://mujs.com/Duktape:http://duktape.org/I have had success running V7 on ESP8266 using mongoose-iot (aka. Smart.js) and Espruino on STM32. I find them nice for fast prototyping.To my knowledge, none of them work on 8bit MCUs.Espruino is being ported to nRF52 (Cortex M4F) in the context of the Puck.js kickstarter.

author: sleemanj
author_rank: Super Contributor
timestamp: July 08, 2016, 10:58:52 am
content: Quote from: Mechatrommer on July 08, 2016, 09:30:00 amAt best you can say that PASCAL derives from ALGOL, in so far as all the Wirth languages do.From memory, PASCAL requires a semicolon as a statement terminator except for the last statement in a block, where it's not necessary since the block end forms the termination. But you can add one if you want.It's been a long time since I've written anything in a Wirth language though.NB: PASCAL and C were both initially developed around the same time, late 60s early 70s.

author: nctnico
author_rank: Super Contributor
timestamp: July 08, 2016, 11:19:58 am
content: Quote from: ataradov on July 08, 2016, 01:23:00 amActually LUA is compiled into bytecode as well. Also LUA is widely used in games to let users extend functionality of elements of the games. All in all there are millions of kids out there who started programing in LUA at the age of 10 to 12. Don't underestimate that!Trying to do some with eLua has been on my list for a couple of years now because it takes a lot of problems away. Also increased hardware costs are not a big issue unless you run really big volumes (>10k units). People still focus too much on the cost of hardware and too little on the development costs because the costs of the latter are way more difficult to understand or predict.

author: timb
author_rank: Super Contributor
timestamp: July 08, 2016, 12:02:18 pm
content: Quote from: nctnico on July 08, 2016, 11:19:58 amExactly. People think "scripting language" and they immediately think slow and bloated. But that's really not the case with Lua. In fact, in some cases it can be nearly as fast as C! Then, there's alternate VMs like LuaJIT, which is normally *at least* twice as fast as the stock Lua 5.1 VM; sometimes over 64x as fast!eLua is actually really fast based on some tests I've done. Keep in mind, it's running bare metal, so aside from the small overhead of the VM, execution would be comparable to compiled C in a lot of cases. And for the cases it's not? Well, Lua allows you to use C as well (you write your code in C and compile it as a Lua module, basically) so I don't really see a downside so long as you've got enough Flash space to deal with the overhead of the VM (or an MCU that supports an EMIF and code execution from external flash/ram).

author: Kalvin
author_rank: Super Contributor
timestamp: July 08, 2016, 12:07:59 pm
content: You can make the Forth as modern as you want.

author: rstofer
author_rank: Super Contributor
timestamp: July 08, 2016, 02:31:14 pm
content: Quote from: ataradov on July 08, 2016, 04:41:04 amI have spent the last day or so dealing with Ada and how it is used to describe hardware. It's pretty verbose but packed, named bits seems pretty useful. In the GNAT package, there are several board support packages from which is should be possible to create a description for just about any hardware. It's just records and fields...I haven't gotten interrupts figured out as yet but I see where they initialize the vectors in assembly code. But that's pretty typical for ARM code anyway. The vectors and some small fragment of the interrupt handler is written in assembly and the bulk of the driver is written in C.I don't know how far I will take this adventure with Ada because I am quite comfortable using C. I would like to get "Hello World" working but, at the moment, it seems that I have some confusion in which library to use and where the USART registers are located.

author: ataradov
author_rank: Super Contributor
timestamp: July 08, 2016, 04:40:41 pm
content: Quote from: rstofer on July 08, 2016, 02:31:14 pmSo if I want to switch to a new MCU, I need to spend days describing bit fields? No, thanks.Quote from: rstofer on July 08, 2016, 02:31:14 pmNo its is not. With ARM Cortex devices one of the design goals was to not have any assembly at all. All my interrupts are described in pure C and it is such a pleasure that I'm not going back to writing them in assembly no matter what other benefits are.Quote from: rstofer on July 08, 2016, 02:31:14 pmExactly. And try to work with something more complicated, like USB.

author: dferyance
author_rank: Regular Contributor
timestamp: July 08, 2016, 04:57:38 pm
content: I don't see a practical point of a language beyond C++ or something designed quite similar (e.g. D) for embedded systems. I have played around with python and one of the crazier things I have done is compiled F# to JavaScript to run on the Espruino.My main experience with a scripting language on embedded was the Bluegiga one. Kinda like BASIC but their own language. But it was horrible for debugging and ran really slow. The thing would freeze if I toggled a pin too fast. The nice thing is I didn't need to pay for expensive bluetooth stacks or compilers but that was the only good thing.I think those languages are interesting both for getting people who aren't used to embedded started as well as a fun way of experimenting. It is sorta like the O.S. kernels written in C# or Java. They aren't practical, but just plain fun to mess around with.

author: hans
author_rank: Super Contributor
timestamp: July 08, 2016, 05:28:44 pm
content: I think one big issues with exotic languages is the huge amount of bootstrapping code we take for granted. The device declarations, startup code, RTOS, device drivers (CMSIS), protocol stacks, etc. This is kinda a chicken and egg story; as long as there are no applications written in said languages there is no demand for said software.Although I'm comfortable writing C, I think some of it's language features are abused to the max by it's "optional type system":https://twitter.com/mariofusco/status/696296466831298560The way you can cast objects or pointers is absurd really, and there are plenty of type violations that just generate a little warning or info that can be ignored. I wouldn't shed a tear when the day comes that is behind us. I think Rust is a good candidate (although constrained by that it has decent optimizations for embedded and toolchains); because it can interface with legacy C code. This could solve the "legacy" problem, although initially it would still appear like a hackjob when combining both facets.In my experience C is all you need for writing ARM applications, except when you're messing around with the CPU context in for example a RTOS or a bootloader. But still the amount of ASM lines is fairly limited; probably not more than 50 or 100 for a fully functional RTOS. The startup code can be written completely in C; it consists of a const array that can be placed at the vector position via sections, and the reset vector can be a naked C function that initializes the C runtime and calls to main.Most scripting languages I have programmed with (python, PHP, some Lua) have arguably even worse type systems; but IMO these languages are designed for "quick and dirty" code that's productive to write. Javascript is a infectious disease and I always have a feeling I lose some braincells when I wrote some.

author: C
author_rank: Super Contributor
timestamp: July 08, 2016, 06:34:28 pm
content: What I see here is a lot of one sided comparisons.Bytecode is bad, very bad!!!No thought of the good side of bytecode to justify this one sided comparison.A good bytecode program should have lower memory requirements as the program gets larger. A slower program that can do more then native code in same memory size.Make a fair comparison of bytecode that has some error checking to a C program that has the same error checking.Their are a lot of possible steps between a bytecode interpreter and native code changing the speed vs space requirements.Adding a non verbose requirement to a language removes the choice of what step you want. With verbose you can have a mix of any in one program.I see Pascal is Bad because ................Again how is comparing a poor Pascal compiler against a good C compiler a fair comparison of Pascal vs C?Quote from: ataradov on July 08, 2016, 04:40:41 pmSo instead you spend days creating defines?I see a lot more chances for errors in bad defines then a structure or record. How can a compiler catch a bad define?QuoteIn 1982 I was programming in pascal using an operating system written in pascal and the interrupts were in pure pascal.If you want to use a new language you need to use the new language properly to gain it's benefits.

author: ataradov
author_rank: Super Contributor
timestamp: July 08, 2016, 06:37:10 pm
content: Quote from: C on July 08, 2016, 06:34:28 pmNo, I take manufacturer-supplied ones.You can preach using Pascal or any other language all you want, I personally won't even bother looking at then until there is significant part of the industry already doing so. Too much of a risk.

author: vodka
author_rank: Frequent Contributor
timestamp: July 08, 2016, 06:47:09 pm
content: Quote from: ataradov on July 08, 2016, 03:20:22 amWhy ? Simply , my father ,a neolithic programmertold me, the problem that had had the colombian with the recount system of votes .The colombian had modernized the system ,changing the Cobol for other modern language program. And when they used the new system , it didn't terminate to recount votes.After 12 hours ,the new system hadn't yet counted . Then , they stopped the machine and returned to old system(Cobol) , it terminated to count on less of the 10 minuts .

author: dferyance
author_rank: Regular Contributor
timestamp: July 08, 2016, 06:49:17 pm
content: Quote from: C on July 08, 2016, 06:34:28 pmWhat kind of bytecode system are you talking about? Is this applicable for a JIT? An interpreter? Or pre-compiling the bytecode to native?A JIT is too big to run on a lot of systems. Interpreters can have their merits. As you mention it can reduce code size at the expense of speed. However a lot of embedded processors have so little RAM that the RAM is more precious than code-size. When doing JavaScript on embedded I found it was way too easy to run out of RAM without really being careless. In the case of limited RAM an interpreter makes things way worse. Pre-compiling to native is fine, that is no different than the internal architecture of a lot of compilers anyway.Quote from: C on July 08, 2016, 06:34:28 pmI've done plenty of Pascal work but it was almost entirely in the Delphi / ObjectPascal style. It is pretty comparable to C regarding performance and being able to map closely to the machine architecture. There are things I both like and don't like about it. It is nice to be rid of the ugly #includes but is verbose and too picky about other things. However sometimes you just gotta use what is popular. C compilers are everywhere and Pascal is far less less common. There are good arguments that Pascal is better than C but the best of them doesn't make a huge amount of difference. They are close enough to each other; I have to default to C.

author: ataradov
author_rank: Super Contributor
timestamp: July 08, 2016, 06:52:54 pm
content: Quote from: vodka on July 08, 2016, 06:47:09 pmIt has noting to do with speed of execution. They just have a ton of code that no one wants to rewrite and debug again.The same reason why lots of mathematical libraries (LApack and such) are written in Fortran. Those libraries are used in lots of mission-critical applications (aerospace, civil engineering) and no one wants to rock the boat.

author: autobot
author_rank: Regular Contributor
timestamp: July 08, 2016, 07:24:26 pm
content: Quote from: ataradov on July 08, 2016, 03:13:04 amThe potential of Rust(with the right framework, and maybe small improvement to the language) to offer higher quality, more reliable software is there. The question is can you turn that into money, either by faster development(maybe), or by convincing customers this has value.Maybe we're not there yet, but a lot of the pieces are there.With the right platform you could make sure peripheral initialization is safe at compile time(Zinc), That no data races happen including in interrupts(RustyGecko talks about it), Almost no memory errors happen(Rust), That your communication protocols are protected from hackers(Nom), And other libraries that are possible in C but might occur in rust first because poeple like it because a safety culture may be created around it.spw15.langsec.org/papers/couprie-nom.pdf

author: rstofer
author_rank: Super Contributor
timestamp: July 08, 2016, 07:46:12 pm
content: Quote from: ataradov on July 08, 2016, 04:40:41 pmUnless somebody gives you the #defines, you have to do the work anyway.QuoteThere are still vectors to populate (97 of them?). The big difference is in eliminating the preamble and postamble. The Cortex is a great improvement. The Ada approach is to use assembly language to populate the vectors, set up the operating environment, start up the FPU and the I/D caches. It may just be for convenience because underlying Ada is the same GCC compiler that works for C.Although I haven't tried it (obviously), there is some linkage between Ada and C or Fortran. I kind of like Fortran so maybe I'll play with it one day.QuoteThe library confusion is strictly on me. That, and my board probably isn't the one the example code was targeted for. More to follow when I get an older board some time next week. I don't know much about USB but code is code. Whatever the algorithm is that works in C it will also work in Fortran. It might not be pretty but I'll bet it could be done.I'm far from sold on Ada. I don't really know why I am messing with it except that I am bored and looking for a project. I have a STM32F746G-Disco board that might make a nice display for one of my FPGA projects. I was thinking about writing the code in Ada just for the experience. But first I have to get "Hello World" to work...

author: ataradov
author_rank: Super Contributor
timestamp: July 08, 2016, 08:02:08 pm
content: Quote from: rstofer on July 08, 2016, 07:46:12 pmMost manufacturers give you header files. And all of them also give SVD files that can be used to generate your own headers. There is no real problem to create a converter from SVD to Ada-style definitions. But no one did it so far.Quote from: rstofer on July 08, 2016, 07:46:12 pmNumber of vectors depends on the specific MCU, but you can do that from pure C. Here is example of such pure C startup filehttps://github.com/ataradov/mcu-starter-projects/blob/master/samd21/startup_samd21.c

author: vodka
author_rank: Frequent Contributor
timestamp: July 08, 2016, 08:09:54 pm
content: Quote from: vodka on July 08, 2016, 06:47:09 pmAnd you have reason,but this code will have to upgrade according the new machines sooner or later somebody have to get source ,read,debug and modify.Quote from: vodka on July 08, 2016, 06:47:09 pmI believe that the prehistorics programmer haven't too faith and the youngs with his new programming methodology(POO). Furthermore, must have many valor for ordering to young that convert an old aplication.As the colombian case ,a little ,fast and working cobol application versus a big,slow and unworking modern aplication.

author: zapta
author_rank: Super Contributor
timestamp: July 08, 2016, 08:15:19 pm
content: Quote from: sleemanj on July 08, 2016, 10:58:52 amThat's called 'statement separator', similar to enum separator in C.

author: C
author_rank: Super Contributor
timestamp: July 08, 2016, 08:27:24 pm
content: Quote from: ataradov on July 08, 2016, 08:02:08 pmSVD to ada donehttps://www.eevblog.com/forum/microcontrollers/'make-with-ada'-competition/msg971184/#msg971184edit to correct SCD to SVD above

author: ataradov
author_rank: Super Contributor
timestamp: July 08, 2016, 08:29:24 pm
content: Quote from: C on July 08, 2016, 08:27:24 pmWell, that's awesome. I did not know about this.Not that it will make me use Ada

author: C
author_rank: Super Contributor
timestamp: July 08, 2016, 11:27:00 pm
content: dferyanceThink of what JIT is really for.JIT lets a program run on many different processors and act the same on all. For a PC that is one program to i386 or x64 code for example.Where is the need for JIT on a small embedded processor?

author: timb
author_rank: Super Contributor
timestamp: July 09, 2016, 02:58:19 am
content: Quote from: C on July 08, 2016, 11:27:00 pmThat's only one of the small advantages of JIT. There are many more advantages, speed being one of them.Edit: For embedded systems, there's also the case of being able to write once and deploy on several different targets just like you mentioned. Like ARMv7 vs ARMv6. The JIT VM would take care of optimizing statics at run time, for example. I would say that's a bigger advantage on embedded devices due to the plethora of different architectures!Remember back in the day you had MIPS, SH3, PPC, ARM, Xscale, etc. Now it's mainly come down to different flavors of ARM cores, though various routers still use MIPS and friends.On the PC side, it's all basically x64 now. Aside from legacy applications, x86 is dead. (Embedded x86 use notwithstanding.)

author: C
author_rank: Super Contributor
timestamp: July 09, 2016, 04:45:26 am
content: Quote from: timb on July 09, 2016, 02:58:19 amThink of the steps1. Run a Program.2. Use JIT to change JIT source to a program in RAM.3. Run the Ram program.4. Delete the Ram program.Need to ask how much computing power do you want to waste?How much longer startup time?Is the program going to change each time it's run?Go back a little more, 8080, 8085,Z80,6502,6800,6809,8051.A JIT on these would probably cripple them.If you change #2 from RAM to storage, Flash or something like this, then you have a compiler not JIT.

author: vodka
author_rank: Frequent Contributor
timestamp: July 09, 2016, 06:00:56 am
content: Quote from: C on July 09, 2016, 04:45:26 amI amn't only ,there is an other heretic on the forumCarefull ,i commented a thing seem to yours an other post, almost somebody sent me to bonfire

author: george.b
author_rank: Frequent Contributor
timestamp: July 09, 2016, 06:21:42 am
content: Maybe I'm just a bit dense, but... it's embedded electronics, what do you need more than ASM and C/C++ for?

author: ebclr
author_rank: Super Contributor
timestamp: July 09, 2016, 06:36:33 am
content: For me Pascal is the most readable language, and forces clean coding, But I'm forced to use this shit C, because is the industry standard, But anywhere a Pascal compiler is available is my 1st choice

author: chris_leyson
author_rank: Super Contributor
timestamp: July 09, 2016, 07:34:45 am
content: I'm a hardware guy not a programmer, but why the hell do companies like Microchip have to abstract everything into some half baked C++ sort of language with missing library support, I gave up trying to use their latest C compiler and went back a few versions and used the old PLIB libraries. Spent a few days trying to figure out how to turn global interrupts on and off, tried at least two function calls only to find that the compiler hadn't generated any code whatsoever, not even a warning message for the unsupported and badly documented function call. I'm thinking what the hell they can't even get plain vanilla C compilers right, next time I need a small embedded microcontroller it won't be from Microchip. 20 or 30 years ago companies like Intel, Microsoft and Motorola would properly document their C library functions. Next time I need to use an embedded microcontroller the choice will probably come down to the compiler and not the hardware. Peripheral library support is crucial in any embedded application and if you can't even get C right..

author: Howardlong
author_rank: Super Contributor
timestamp: July 09, 2016, 08:13:05 am
content: <rant> The last thing we need is yet another f***ing language! </rant>In the past few years it seems like world+dog has to come out with yet another language, and when they're not doing that, they apply an existing language inappropriately to a platform it was never designed for.The lifetime of the vast majority of these next-big-thing languages is a few years at most. Flash. Ruby. Perl. Those are the well known ones, most don't even get as far as they did, but you get the idea.Furthermore, if you want to produce medium to long term maintainable code, then it makes little sense to adopt some new random language fresh off the boat, you choose one appropriate to the task at hand, and that enjoys a reasonable pool of skilled individuals available to write and support it.Only rarely does a "new" language bear longevity. C# and Java are examples, although even Java has a somewhat rocky road, with recent questions over Oracle's commitment to some facets such as Java EE.Although it's certainly worth being aware of various programming languages, it's far, far better to be a master of two or three established ones than it is to try to be a jack of all trades. Particularly as a young player, the temptation is to fanny about with the next big thing, which changes on almost a monthly basis. While expanding one's knowledge and exposure is to be applauded, indeed by doing so you will realise this next big thing is rarely that big at all, it's a super risky strategy to commit your career to, say, node.js without also being reasonably competent in the far more established languages and frameworks.Apologies for the rant-like comments here, I've just seem so much of this nonsense over the years that I've become rather cynical about it!

author: Rerouter
author_rank: Super Contributor
timestamp: July 09, 2016, 08:33:10 am
content: So as another young member, for embedded on things like a small ARM (96K ram), without digging into assembly are there any reference guides or similar to compiling and running these tiny native snippets most seem to be describing, or a preferred way to running scripts or similar, my current thoughts have been using an interpreter with a limited version of C, but was wondering if there are any better ways?

author: Boomerang
author_rank: Regular Contributor
timestamp: July 09, 2016, 08:35:21 am
content: Any language can work for microcontrollers if it is able to:1. read from specific locations2. write to specific locations3. get addresses of functions/procedures

author: Kalvin
author_rank: Super Contributor
timestamp: July 09, 2016, 10:36:34 am
content: For those who are interested in software robustness, correctness and safety, and still want to use C as the implementation language of their choice might find the Frama-C and the ANSI/ISO C Specification Language (ACSL) quite interesting in addition to the MISRA C guidelines:https://en.wikipedia.org/wiki/Frama-Chttps://en.wikipedia.org/wiki/ANSI/ISO_C_Specification_Languagehttps://en.wikipedia.org/wiki/MISRA_CHere is an interesting paper "Program Verification in SPARK and ACSL: A Comparative Case Study":http://haslab.uminho.pt/jsp/files/2010_rstae_10.pdfQuoteNote: "In SPARK83/95/2005, the contracts are encoded in Ada comments (and so are ignored by any standard Ada compiler), but are processed by the SPARK "Examiner" and its associated tools. SPARK 2014, in contrast, uses Ada 2012's built-in "aspect" syntax to express contracts, bringing them into the core of the language."https://en.wikipedia.org/wiki/SPARK_(programming_language)** It is fully possible to link SPARK (ie. subset of the Ada) and C code in the same application thus be able to call the C functions from the Ada and the Ada functions from the C.

author: legacy
author_rank: Super Contributor
timestamp: July 09, 2016, 11:37:41 am
content: Quote from: C on July 08, 2016, 06:34:28 pmwhich platform? which compiler?

author: Buriedcode
author_rank: Super Contributor
timestamp: July 09, 2016, 12:21:15 pm
content: Interesting topic. After years of 8-/16-bit "true embedded" apps (portable, low power, sensors, buttons displays, the bread and butter of 8-bit devices) lately I've been using ever larger devices for slightly more complicated projects. Being more complicated the general setup code for a blinky is of course going to be larger, with more settings/configuration so makes little sense to use these for simple projects - but that is often what we see on instructables or hackaday.Different people will side with different languages - scripting, managed or just raw C - depending on what they generally do, and what devices they use day-to-day. If someone works with ARM devices, and wants to say, make a 433MHz remote control receiver - chances are they'll reach for an ARM even though a small 8-bitter or even an Arduino will do nicely. As for language, scripting languages are nice for quick testing of something - say you need to debug some serial output that has different hex codes, something you probably only need to do once - but whilst they may be robust enough for some... I wouldn't be comfortable providing that to a customer for a product, or industrial setting.Also, many who promote such languages, often use the grunt of a larger micro (which in terms of cost is probably on par with an 8-bit AVR!) for the horse power, but this comes at a cost - power. It also doesn't perform as well as it could when written in C - but often this doesn't really matter as the time saved writing it trumps performance losses, unless it is meant to be blazingly fast, few apps require that. I haven't seen many portable applications - if someone uses a wall wart then they probably don't care about it, but if its portable? Oh we just need a larger battery...On the flipside, I do get annoyed when I just need to test something out on an 8 (or 32) bit device and writing the basic logic of what it should do takes minutes, but the setup, interrupt code, and faffing about with C takes a lot longer, even though it produces something I would consider reliable, neat and fast. And there's the basic different we all know - scripting is generally for quick prototyping, conversion, and definitely has its place. Where-as if you're making something that has to be reliable, the interpreter, even using a much larger device than required can end up costing more time and causing more headaches - and that is why we love C.My long-winded point is... Without pointing out the many specifications/restrictions on the exact application, comparing any of the modern languages - interpreted, managed, or otherwise - quickly becomes a pissing contest about syntax, 'its used in this so it must be good', and compatibility with specific devices.You could have one person who generally uses 8-bit AVR's to control coloured LED's based on buttons, and someone else who writes RTOS's for ARM9, to the speed fiend who writes FFT's on 16-bit devices and the Arduino user who writes 9 lines of code for checking that an SPI chip spits out the right bytes. And what about those who make wearables/portable devices? surely current consumption is a key factor there? Without providing a context or even a hint to the final application, who can say what is best in terms of development, cost and reliability?The variation in the embedded world is far greater than on desktop computers. So comparing languages on a desktop is just about development time (which depends on how well you know the language) and syntax preference (pretty much C-like vs anything else). But on embedded - you need to point out what the project is.

author: nctnico
author_rank: Super Contributor
timestamp: July 09, 2016, 02:18:22 pm
content: Quote from: Buriedcode on July 09, 2016, 12:21:15 pmThat is a common misconception. A bytecode program executes just as fast. If you look at a C program from a functional view you'll notice the compiler links blocks of code (functions) together. This means some overhead. Also the functions themselves may not be as optimised as you'd like. In a bytecode executed higher level language you also have the call overhead but the blocks of code which are executed are more rigid and thus can be optimised much better. Over 2 decades ago I took on a challenge to program something in Powerbasic and someone else would program the same in C. It turned out the Powerbasic program was much faster.Either way: programming using managed languages is the way into the future for projects with increasing complexity. It is not about making the programmers dumbers but reducing the chance of errors due to buffer overflows. It is not going to happen today but it will in the coming decade.

author: timb
author_rank: Super Contributor
timestamp: July 10, 2016, 04:02:42 am
content: Quote from: nctnico on July 09, 2016, 02:18:22 pmExactly. As I mentioned before, languages that "pre-compile" to bytecode and use a JIT VM to run it, can be as fast--and in some cases faster--than a traditionally compiled program. However, these programs will in a lot of cases be larger than their traditional counterparts, at least for an embedded program. This is because you have to include the VM in addition to the program. Now, this becomes less of a problem as flash sizes increase on embedded devices.You know, I think the reason people have a hard time accepting that a bytecode based language can be fast is because it goes against common sense. Compiling a program to machine code just feels like it should be faster than something that works on the fly. I think a lot of people assume the resulting performance would be the same as running a C program *as it was being compiled* (which wouldn't work anyway due to the nature of compilers, but I digress).People hear bytecode and they think interpreted language, like MS BASIC.

author: zapta
author_rank: Super Contributor
timestamp: July 10, 2016, 04:55:47 am
content: Quote from: timb on July 10, 2016, 04:02:42 amIt may be faster over long computations but slower in worst case analysis due to its non deterministic nature (imaging having to compile an ISR once it's invoked).A more realistic approach for small embedded systems would be doing the final compilation on firmware installation rather than on-demand during execution.BTW, all programs run using byte codes and interpreters. Arduino for example compiles to the AVR byte codes and runs it using the AVR hardware based interpreter. Compilers translate and interpreters execute.

author: hamster_nz
author_rank: Super Contributor
timestamp: July 10, 2016, 06:16:16 am
content: Running a non-native byte code has been around for half a century, and has been used for Pascal compilers since - references:https://en.wikipedia.org/wiki/P-code_machine- p-code (1966)https://en.wikipedia.org/wiki/Joel_McCormack#P-machine_Theory- running Pascal (1977)https://en.wikipedia.org/wiki/Java_(programming_language)#History- Java 1.0 was released in 1995Can anybody suggest anything that has actually changed this decade that make the technique any more or less suited then running native code on an smallish embedded system?

author: Muxr
author_rank: Super Contributor
timestamp: July 10, 2016, 06:29:43 am
content: I wouldn't mind seeing Golang on MCUs personally.. while I am not a huge fan of its syntax I do like some of its inherent features.for scripting on MCUs lua has had a long history in embedded.. but there are only a few cases where I would use it.. (UI or providing scripting capability to the user/customer).Haven't tried micro-python yet.. and while I quite like Python for automation (non embedded stuff) not sure it's well suited for embedded.

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 10, 2016, 06:31:22 am
content: Quote from: zapta on July 10, 2016, 04:55:47 amyou are in some sense correct. but language compiled to native machine code only has to pass one interpreter, ie the hardware interpreter. where the (soft) interpreted language as we usually understand it, has to pass at least two. if those precompiled "bytecode" is talking about translating the "machine independent code" into "machine dependent native code" at runtime and then executing it, then probably it can be just as fast (ignoring time required in housekeeping task interpreting), esp if the translator is efficient enough at translating some significantly complicated logic, such as that i can think of, translating search algorithm in tight loop of millions to billions of specialized "user defined" data type member.

author: nctnico
author_rank: Super Contributor
timestamp: July 10, 2016, 06:37:11 am
content: Quote from: zapta on July 10, 2016, 04:55:47 amAFAIK that is exactly what eLua does: run the VM with precompiled bytecode. That way you don't need the compiler on the embedded device. But you can still choose to include the compiler on the embedded device to allow for user scripting although this would be more suitable for the prototyping phase.@Mechatrommer: bytecode isn't translated into machine native instructions. That would be slow indeed. Think about a level higher like adding 2 variables into a third. That would require an ADD function which is called with 3 parameters (memory locations).

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 10, 2016, 08:12:54 am
content: Quote from: Howardlong on July 09, 2016, 08:13:05 amThis is an important point that's often missed, whether it's a language, or choice of an oddball architecture, or even just a less-than-mainstream MCU manufacturer.Long-term availability of people who know it is one of the most important considerations for long-term maintainability.If you want something "better", look at using things like MISRA guidelines for C, and maybe in-house style guidelines.Increased availability of CPU power and memory does give some options for using more PC oriented platforms for embedded - Linux being the most obvious example, though there is still quite a big learning curve for PC programmers to be able to efficiently work on embedded stuff.There are specialist areas like medical, aerospace and other safety-critical applications where there is scope for taking advantage of specific features in languages like ADA, but otherwise it's hard to justify using anything non-mainstream.

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 10, 2016, 11:10:51 am
content: Quote from: nctnico on July 10, 2016, 06:37:11 amso it run based on "virtual machine" or "runtime environment" type of architecture? how people dare to say its as fast as native code? explaining with proof then i will be entertained.

author: Jeroen3
author_rank: Super Contributor
timestamp: July 10, 2016, 12:20:36 pm
content: I've not yet seen the key reason for using higher level languages.Testing.You can run complete software validation before the hardware is even build, on computer simulation, if you can make simulation layers.Sometimes it does not need to be fast, because it takes too long to develop it fast. You want it reliable. If you have 100+ developers on a project, you don't want every one of them having hardware on their desk to test the software. Especially if the hardware is very expensive, or very big, or destroys itself on wrong code. Or is not even capable of debugging, like security devices.

author: legacy
author_rank: Super Contributor
timestamp: July 10, 2016, 01:23:59 pm
content: Quote from: Jeroen3 on July 10, 2016, 12:20:36 pmavionics, expensive hardware, not reliable (one, two fly-units every four testing team), simulator? never seen

author: nctnico
author_rank: Super Contributor
timestamp: July 10, 2016, 02:57:26 pm
content: Quote from: Mechatrommer on July 10, 2016, 11:10:51 amYou are thinking at the wrong level. The bytecode doesn't do load register this with that and then add register x with y. It does add these numbers, append these two strings, convert this string into a number, output this array to a peripheral. If you want to compare with machine code then imagine machine code which runs on a processor which can execute al the functions from the standard C library, math library, STL library, etc as single instructions. Ofcourse a virtual machine to execute bytecode isn't emulating a CPU!

author: Kilrah
author_rank: Unknown
timestamp: July 10, 2016, 03:11:27 pm
content: Quote from: nctnico on July 10, 2016, 02:57:26 pmBut the point is that it has do actually do this using the host machine's processor, so it does have to "translate" the high level concept to low level ones that can run on the machine, either by compiling or "running small pieces of code that do the subtasks" in the host machine's native instruction set, which can only be slower than straight using native instructions i.e. precisely the "load register this with that and then add register x with y"...

author: zapta
author_rank: Super Contributor
timestamp: July 10, 2016, 03:28:44 pm
content: Quote from: Kilrah on July 10, 2016, 03:11:27 pmThat's exactly what the JIT compilers generate "load register this with that and then add register x with y". One potential advantage that they have is the ability to instrument the code and collect stats, e.g. about branch statistics, and then recompile to an even more optimized code."JIT code generally offers far better performance than interpreters. In addition, it can in some cases offer better performance than static compilation, as many optimizations are only feasible at run-time:..."https://en.wikipedia.org/wiki/Just-in-time_compilation

author: diyaudio
author_rank: Frequent Contributor
timestamp: July 10, 2016, 05:10:25 pm
content: Quote from: nctnico on July 08, 2016, 11:19:58 amEven modern game engines use it for animation scripting, angry birds uses it as well.

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 10, 2016, 05:46:34 pm
content: Quote from: nctnico on July 10, 2016, 02:57:26 pmbut a "bytecode" is somehow like a "virtual machine opcode" right? that needs a translator (runtime library) to which function a bytecode is suited to run with right? and the translator, or the JIT, or the VM or "The Engine" or however you prefer to call it.. will run on a hardware right? and that hardware has specific "machine dependent" opcodes right, to which the JIT/VM/Engine is executed from. are you still reading me? that was my argument. I have no objection if someone says JIT is faster than interpreter, but JIT or bytecode or whatever is faster than native machine code? thats unjustifiable. and how can you possibly try to analogize a "bytecode" is similar to an "opcode" for any functions in C library, says a JIT has an opcode for strcat, that you claimed run in one single instruction? thats a "soft" or "virtual" opcode you are talking about, not the real hardware opcode. i'm pretty certain your atomic "bytecode" in JIT is many many atoms in native codes execution. except on a special machine that supports all bytecodes natively in hardware.

author: tggzzz
author_rank: Super Contributor
timestamp: July 10, 2016, 06:13:13 pm
content: Quote from: Mechatrommer on July 10, 2016, 05:46:34 pmYou will no doubt be surprised to learn that it isn't as simple as that. Seehttp://www.hpl.hp.com/techreports/1999/HPL-1999-78.htmlIn some cases interpretersincreasethe execution speed.The key point is that a static compiler has toguessthe code/data execution patterns at compile time, and - especially with C/C++ - has to makepessimising assumptionswhich are reflected in the generated machine code. In particular the data access patterns greatly influence the overall speed where the system has L1/2/3 caches and NUMA memory. OTOH an interpreter/runtime can inspect what'sactuallyhappening, and optimise that.Hence in the Dynamo project, they used a C compiler to generate code for a machine X, and measured its speed. They then took anemulatorof machine X running in machine X, observed what was happening, and changed the machine code on the fly. They found thatwhen running in the emulatorof machine X, the optimised code was sometimesfasterthan the compiler's outputrunning directly on the bare metal machine X.Of course it is unlikely that an embedded system will have NUMA memory, but many do have caches.

author: Kilrah
author_rank: Unknown
timestamp: July 10, 2016, 06:22:04 pm
content: I can understand it'ssometimesfaster, but it must also be slower in other circumstances. Since JIT compilation on its own obviously requires executing instructions to do the job any improvements only appear in cases where the optimizations exceed the additional overhead, if they match there's no gain and if nothing can be optimized you did work for nothing and lost time.Would be interesting to have decent profiling of how it stacks up in a number of real-world situations... because unsurprisingly the only thing you see talked about is "it can go faster in some cases" but no mention of the opposite, which strongly smells like typical marketing where all it takes is for someone to find a single fringe case where it did to say so and try to make everyone believe it's the duck's guts...

author: rstofer
author_rank: Super Contributor
timestamp: July 10, 2016, 06:25:08 pm
content: Many years ago, I spent a lot of time with the run time interpreter for the UCSD Pascal system. Pascal, on that system, used P-Code but it was still pretty fast considering the hardware of the time. A 6 MHz Z80 was pretty much top of the line.Each P-Code was dispatched to a handler and this dispatching operation was 'overhead'. But the handler itself was no different than if the same operation was coded in assembly language (which it was). It takes just so many machine instructions to move a string and the interpreter was as fast at moving a string as any other implementation. The difference between interpreted P-Code and machine code was in the dispatch. So, if the dispatch was fast as a percentage of the entire operation (say moving a string or a floating point operation), the overhead wasn't objectionable. Yes, it was slower than running native code where the linker handles dispatching but only by a few percent.The nice thing about the interpreter was the ability to extend it to add other devices. It was also the only machine specific part of the system given the limited choices of floppy drives at the time.I used Embedded Pascal a dozen years ago to create a control system for a battery powered boat using an 80251. Not a toy boat, this thing was 12' long and had a 24V DC drive similar to a golf cart. I remember thinking at the time that this code was just plain pretty. It just looked good on the listing.If there was a version for the ARM processors, and if I could afford it, I would be using Pascal instead of C. It would be a mistake, of course, because the GCC toolchain is the most used system in the world. If there was a problem with code generation, it would be fixed long before I would run into it.Ada has many of the features of Pascal and for that reason, I am willing to spend some time looking at it. Oberon is another language worth considering and it is available for ARMs.http://www.astrobe.com/default.htmI'm not clear on whether it has any support for the STM32F boards.

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 10, 2016, 06:35:08 pm
content: Quote from: tggzzz on July 10, 2016, 06:13:13 pmfair enough. so the actual debate here, or proper thread title should be... "advice me on best/fastest compiler/emulator/VM" regardless of how the "language" formed. this has nothing to do with "language specific", language usually close coupled to its "syntax", otoh its "features" or "bell and whistle" compiler/libraries/engine, is another thing, thats from my perspective. if one want the most "featured language", not what a "language capable of", then i can agree with most people here.

author: tggzzz
author_rank: Super Contributor
timestamp: July 10, 2016, 06:47:02 pm
content: Quote from: Kilrah on July 10, 2016, 06:22:04 pmShrug. You can say the same thing about caches.Of course in many cases execution speed isn't an important attribute.Time to answer is often important (=> use any relevant very high level language).In embedded systems,predictabilityof execution time isfarmore important (=> no malloc, no caches (hardware nor software), no random-access networks, etc).Note that jitting isn't the only optimisation tool, and hasn't been for at least two decades.QuoteThere are many many such studies.

author: tggzzz
author_rank: Super Contributor
timestamp: July 10, 2016, 06:49:56 pm
content: Quote from: Mechatrommer on July 10, 2016, 06:35:08 pmIn many embedded systems execution time is only of secondary importance. More frequentlypredictabilityof execution time is paramount. Hence no malloc, no caches, no random-access networks etc.

author: C
author_rank: Super Contributor
timestamp: July 10, 2016, 07:06:02 pm
content: Looking at a small part of the problem with out looking at the big picture is a fail.The sad thing is that a lot of language failures were found and fixed back in the 80's for some languages.The Editor is a part of the ProblemThe CPU is a part of the ProblemThe IO devices attached or built in is a part of the Problem.The Linker is a part of the ProblemThe Make is a part of the ProblemThe _______ is a part of the Problem.The lower you go the less problems a programmer has with the language.The lower you go the greater the chance of errors.The Higher you go the less errors and faster you can create a program.It's simple, each option or change you gain something and you loose something. Not having the option or being able to control it is a fail.Look at all the very dumb languages. How many know of the binary that exist to the right of a decimal point. Easy to leave out of a language and the programmer can still work with the bits. But by leaving this out also means no error checking for this. Your Volts and your MicroVolts just became the same thing when your using integers. Extra load on programmer and chance of errors.A simple choice of put the work on the programmer and less on compiler creator or put some of the work on the language to assist the programmer.So if you have an Object based language you need choices. My object could be that device connected by SPI.Like wise a simple change in order from what is in source to something else can be a fail.As for what output a language should have, the answer is "ALL"From dumb simple bytecode that you can hand assembly an interpreter with all possible steps to pure machine code for any CPU, even a CPU that you create. Interpreter, compiler, virtual machine and JIT all should be options for output. In fact, all should be options while in the editor for the language.

author: C
author_rank: Super Contributor
timestamp: July 10, 2016, 09:17:53 pm
content: Quote from: rstofer on July 10, 2016, 06:25:08 pmYou may not have heard about thisPascal MicroEnginehttps://en.wikipedia.org/wiki/Pascal_MicroEngine

author: C
author_rank: Super Contributor
timestamp: July 10, 2016, 10:22:46 pm
content: Quote from: rstofer on July 10, 2016, 06:25:08 pmYou might want to look atvishap oberon compilerfree portable oberon-2 compilerOberon-2 in and C for GCC outputhttp://oberon.vishap.am/https://github.com/vishaps/vocAnd when you can compile Oberon-2 parts of theOberon (operating system) could be a handy addhttps://en.wikipedia.org/wiki/Oberon_(operating_system)You would then have the Source for all parts.I know nothing but what I read for vishap oberon compilerYou can try the Oberon_(operating_system) with full source in a VM.

author: rstofer
author_rank: Super Contributor
timestamp: July 10, 2016, 10:30:10 pm
content: I had the Oberon operating system running a while back. It seemed kind of minimalist as I recall. My only interest in Oberon would be for embedded programming and that most certainly wouldn't require much of an OS. A little RTOS perhaps but that's about all.In looking at Astrobe (Oberon), I noted that there doesn't seem to be library code to use TCP/IP with the LPC1768 (mbed) and that's a huge problem. I most certainly do not want to rewrite the TCP/IP stack.

author: filssavi
author_rank: Frequent Contributor
timestamp: July 10, 2016, 10:45:56 pm
content: Quote from: tggzzz on July 10, 2016, 06:13:13 pmI'd really be glad to se which MCU has 80 to 512 MB of RAM to work with (the ammount that the workstation using pa-8000 series processor used in that that paper had), even if the memory footprint is quite low in workstation terms 280-300ish KB it is not in MCU terms just to have the jit (and not even a modern one) is huge to put it into perspective it would occupy more than half the memory of the biggest stm cortex M7, so it could technically work but that a lot of practically wasted RAMIn general terms JIT (or vm's or runtimes or any other name you have) are not a magic kind of cure-all-evils panacea, as always in engineering they can guve you speed and safety but you are paying them in terms of RAM, latency and predictability (a jit does't just compiles and optimizes all the application at startup, it start as a pure (dog slow) interpreterà and then by profiling the code compiles and gradually optimizes (thats right usually they arent going from -o0 to -o3 directly) the most utilized code paths, you have to take into account that when the JIT is compiling/optimizing your code slows down significantly, than we have the issue that if while running optimizes code your code branches to a previously unrun part of the bytecode the JIT falls back to "dog slow" mode (aka interprete) and if this code path is not getting hit frequently enough it wont ever be optimizes so wou will have essentially random slowdowns and spedups.In summary this technology is not that well suited for embedded use, where predictable timing and execution,knowing that startup will always take 5 ms, not 5 ms most of the times, but if te Ethernet cable is attached it will take 50ms because the network code has to be jitteed is kind of more important than a 10% boost in mean execution speed sometimes

author: tggzzz
author_rank: Super Contributor
timestamp: July 10, 2016, 11:13:09 pm
content: Quote from: filssavi on July 10, 2016, 10:45:56 pmTypical matchbox-size Zync systems consist of an FPGA, a dual core ARM processor, cache, and 512MB ram, and are used in scopes, and many highly specialised embedded systems. That's the way the world is going.If you look elsewhere you will see I state that frequently timing predictability is more important than speed. That also means any interpreter overhead is not critical.But overall my point is to dispel the mistaken belief that jits and hotspot techniques are slow. In many important cases, they aren't.

author: C
author_rank: Super Contributor
timestamp: July 10, 2016, 11:39:50 pm
content: Quote from: rstofer on July 10, 2016, 10:30:10 pmTCP/IP and other nice things are in the Oberon operating system.

author: hamster_nz
author_rank: Super Contributor
timestamp: July 11, 2016, 01:57:15 am
content: Quote from: tggzzz on July 10, 2016, 11:13:09 pmOne thing which slips past me, and I am failing to grock...JITs and so on are useful when your target architecture changes (e.g. Java on ARM vs Intel), or you don't know what code you will be running in advance (e.g. dynamically linking large class libraries, SQL queries, stored procedures, packet filters, graphics shaders...).If you know the target platform (after all this is in the context of embedded systems), and you know pretty much exactly what code you will be running and how it behaves, then why not just compile the machine independent byte-code to real op-codes before you push it into the device? (i.e. just what the backend of most compilers does). Do it once and do it well - take your time and optimize it.Unless the JIT has information that is not available at build time (or can be gained during profiling within the development cycle) then how can it do a better job?The only reasons I can think of is that it might improving code density, or it may provide a sandbox

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 11, 2016, 02:28:43 am
content: Quote from: hamster_nz on July 11, 2016, 01:57:15 amwell you heard it. runtime monitoring, probably sandboxing way, and then optimize for code behaviour. probably in the same parallel of time hence its not slow. how? its anyone guesses but the runtime environment designer. (ps: optimize for code behaviour: machine to machine basis, even on 2 exact same machines may produce different code signatures if one user is a pothead and another one is not.)

author: rstofer
author_rank: Super Contributor
timestamp: July 11, 2016, 02:37:14 am
content: Quote from: C on July 10, 2016, 11:39:50 pmTrue but the Oberon OS doesn't target embedded processors. I don't know if it will port easily. I wandered all over the Astrobe site and there is mention of trying to get Ethernet working but I couldn't find anything about TCP/IP. I would want a minimalist stack like lwIP.

author: westfw
author_rank: Super Contributor
timestamp: July 11, 2016, 05:33:18 am
content: QuoteNo!First, some apologies. I entered the original question just before going on vacation, hoping it would go in useful directions.But it's not...I don't particularly care about the footprint or performance hit caused by going to this "new" language. Im more interesting in "why do python and lua both exist; aren't they very similar?" Good answers would be "lua has a smaller footprint because most of its high level functionality is aimed at strings, while python has more features for dealing with float math." (note: entirely made-up answer.)I'll settle for "Java uses a VM that is tightly speced to avoid security issues" (oops) while "pyhton bytecodes are designed for easily addable user functions." or similar as well.The conversation so far HAS raised some questions:Whats the difference between a byte-code-interpreted language, and one that uses a VM?Which languages fall into which categories? Java and C# use VMs, while python and lua use BCIs, right?JIT compilation is a pretty deep heuristic, still characterized by vert large VM footprints? Yes or no?QuoteSure. At the same time that security and code quality have become big issues, the price for a chip that will run some kind of VM or BCI while still leaving me "enough" performance and user code space has come down to the same price as a smaller micro that couldn't, making me think that such a thing doing HL memory management, runtime range and type checking and so, might not be an unreasonable idea. I amassumingthat the HLL will run fast enough and small enough for some tasks - how do they compare OTHER than that.

author: filssavi
author_rank: Frequent Contributor
timestamp: July 11, 2016, 06:24:38 am
content: Quote from: tggzzz on July 10, 2016, 11:13:09 pmI didnt think the zinq was an object for this thread, sure it can be used in embedded devices, bur a 600MHz to 1 GHz dual core processor with external ram and rom is by definition a General purpose processor, running a general purpose OS (i used the zynq to do image filtering belive it or not so i'm very familiari with it, and i was running a stock Linux kernel on it) so there is no need for embedded lua or micro python here, there are so much resources that you can use full fledged lua and CPython, the really time critical part of the system would be put in FPGA anyway (or else why are you using a Zynq?)

author: filssavi
author_rank: Frequent Contributor
timestamp: July 11, 2016, 07:05:44 am
content: Quote from: westfw on July 11, 2016, 05:33:18 am1) byecode is by definition an intermediate rappresentation of your program, in between source code and macchine code, as such you can have VM's with bytecode (Java's JVM for example), interpreterà with bytecode (Cpython) JIT compilers that use bytecode as input (CLR and .NET) and AOT compiles that use bytecode ad an input (LLVM)2) it is not that clear cut Java uses a VM but is also JIT compilers on the fly the same goes for C#, python depending on what you use can be purely interpreted (Cpython) jit compiles (pypy, pyston) I don't know lua enogh to speak about it3)yes of course it is, after all you are asking the JIT to do an equivalent work as a normal AOT compiler does just in much less time, so the JIT isn't run on all the program at the start (if that was the case what would be the point of JIT's you could AOT compiler everything) just the hot paths are compiled and optimized, so there is a huge ammount of heuristic going on in the choice of which code paths to optimizes and how muchHere the WebKit developers are describing indetail theis JavaScript execution stack composed of a baseline interpreter and 3 different JIT's differently tuned for performances or runtime , and you can se how to get dynamic interpreted languages (such as JavaScript or python) to executes at only 2x the execution time of a equivalent C program you have to go pretty far and use a lot of resources in jitting and optimizing

author: tggzzz
author_rank: Super Contributor
timestamp: July 11, 2016, 07:12:42 am
content: Quote from: filssavi on July 11, 2016, 06:24:38 amYour thinking is far too limited. Theonlyreason to use a Zynq is for anembedded systemwhere you need a tightly-coupled FPGA. If you don't need the FPGA then you would simply use amuchcheaper ARM processor!There's no requirement to run a general purpose OS (although it is possible). To ensure real-time operation people often run bare metal code on one processor and a simple RTOS on the other.Just look at the pictures, and you will seenoneof these are "general purpose computers":$99 "ArduZynq" module that is compatible with Arduinoshttps://shop.trenz-electronic.de/en/TE0723-02M-ArduZynq-Arduino-compatible-Xilinx-Zynq-7010-FPGA-module?c=188ONetSwitch: Open Source Hardware for Networkinghttps://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking/posts/1213744$55 Snickerdoodlehttp://www.cnx-software.com/2015/10/07/snickerdoodle-xilinx-zynq-arm-fpga-board-starts-at-55-crowdfunding/PicoZedhttp://zedboard.org/product/picozedRedPitaya oscilloscopehttp://redpitaya.com/

author: filssavi
author_rank: Frequent Contributor
timestamp: July 11, 2016, 08:07:20 am
content: Quote from: tggzzz on July 11, 2016, 07:12:42 amI whink you misunderstood me, I know full well that a zynq (or cyclone v soc or other fpga+arm combos) are usefull where you need tight integration between processing and fpga, and I also know that you could run bare metal on a zynq,that doesn't change the fact that:1) if you have an fpga you might as well use it to implement the time critical part of the work ( control loops, precise sampling etc) the arm cores can then handle comms, configuration, HMI, low priority stuffand there is no doubt that an FPGA (if the designer knows how to use it) is much more deterministic in term of execution time, and more often than not (but that is not always the case) much faster due to the high parallelism and pipelining that can be done2) even if you need the tight coupling between core and fabric that doesn't change the fact that the processors on a ZYNQ are beasts and not by any mean limited to embedded use, if you want to run python or lua on it you can use full python and lua there is no need for micropython and elua, in particular if you can even run an OS (namely linux) on core 1 and get your lua/python/ada/[insert language here] and on core 2 you can run bare metal C or C++ to get full blown determinism (if preempt_rt is not enough)3) are they not? HereYour thinking is far too limited, I see you have carefully chosen only the cheapest boards, where the cost of the ZYNQ is a significant part of the final produt's price, so they could not fit HDMI/DVI connector in, but the soc itself will merrily support HDMI video out (it might not play crysis, but that's not the point) , so you could argue they are not GP computers since they haven't got graphics (mind that by that logic a headless server is not a GP computer since it hasn't got graphics), and else they all have at least USB 2.0, most of the boards have some kind of networking capability (wifi or ethernet based) and they can run a general purpose OSso I ask you (and I'm really sincerely asking, is not a rethoric question) what is the difference between these and a GP computer ( or at least a Raspberry Pi which is undoubtedly a GP computer)?

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 11, 2016, 08:51:39 am
content: Quote from: westfw on July 11, 2016, 05:33:18 amdont take it personally and apologize from my part as well.. its 'not uncommon' that a 'this or that language' thread like this will end up in 'bell and whistle' pissing contest. I personally will flavor on 'what a language' capable of doing or what it can give you power of, at language/syntax level, such as the ability to type cast, non aligned byte or pointer shift etc, and even address spaces beyond boundary if the os permitwhile other prefer to argue on how intelligent and complete and featurefull its 'bundled' library/compiler/re/jit are. The common one is automatic in the background array boundary check. They may well aware how that works behind the scene, but albeit the less likelihood, but still probable, that they are not. Why this eternal pissing contest you ask? from my conclusion its simple. We come in two flavor school of practice. One is being a professional type of coders, they want to accomplish task in tight time budjet, delegate as much problem to others as possible,hence ide developers who took responsibility of managed libraries won their heart. Another school of practise is being a codemonkey lord type, the hobbiests/hackers and such community who want as much power and control from a particular language. No managed library? No problem! We build that in house! This language can do this, others cant..so that type of schools. So what school are you? If you can answer that,then you can make selection easier from plethora of choices. I can understand the rationality of their school of practise,but i'm not sure about them to us..but the best thing is to agree on both and respect the choice each one made that suit best their particular needs.fwiw 2cnt.

author: tggzzz
author_rank: Super Contributor
timestamp: July 11, 2016, 10:55:00 am
content: Quote from: filssavi on July 11, 2016, 08:07:20 amI may well have misunderstood what you wrote, but theprimaryuse-case for a Zynq is as an embedded system, therefore it is (to use your phrase) "an object for this thread".As for "carefully choosing the cheapest boards", they weren't carefully chosen and they aren't the cheapest.If you want a more expensive embedded board or subsystem with a Zynq, look atEUR1500https://shop.trenz-electronic.de/en/TE0782-02-045-2I-High-Performance-Xilinx-Zynq-Z-7045-Modul-ind.-temp.range-8-5-x-8-5-cmor search for "software defined radio", e.g.https://epiqsolutions.com/quadratiq/or search for "software defined networking", e.g.http://www.xilinx.com/products/boards-and-kits/1-411yn3.htmlor many manymanyspecial-purposeboards

author: filssavi
author_rank: Frequent Contributor
timestamp: July 11, 2016, 11:35:55 am
content: Quote from: tggzzz on July 11, 2016, 10:55:00 amAgain I fail to see why these boards are not general computers, they are general computers programmed to do a very specific task so they act as a special purpose board, but there is nothing stopping you (ok crypto if secure boot is used but that is beside the point), from flashing the memory and use the module at least as a server (qhich qualirfies as GP to me), is it a good idea? no, of course not, it is a terrible idea having a 1500$ sdr board do what a 35$ raspberry pi 3+ can do, so i'm not suggesting that it should be done, only that is can be done.than again is funny that you point to me to 3 systems, 1 of which is just a glorified breakout board (the trenz one) so what is it's special purpose? the other 2 just as I said use normal (General purpose) linux kernel on the processor par that handles, for example the web gui (web servers are a very special purpose embedded technology i know) while the real real time embedded stuff (all the DSP and signal processing) is done in the programmable logic not on a embedded lua or micro python interpreter running on bare metal, that is pathetic just to think about it

author: tggzzz
author_rank: Super Contributor
timestamp: July 11, 2016, 12:36:48 pm
content: Quote from: filssavi on July 11, 2016, 11:35:55 amSigh. Playing around with different definitions of "embedded" and "general purpose computer" is a waste of everybody's time. Neither terms are well-defined.

author: captbill
author_rank: Contributor
timestamp: July 17, 2016, 05:40:34 pm
content: Quote from: rstofer on July 11, 2016, 02:37:14 amCongrats on your decision to use Astrobe/Oberon. You won't regret it.There is indeed a learning curve or more a "breaking of old habits" that is learned.Oberon is all about modularization and minimalism and getting the feel of the great freedomafforded by it's virtues takes some getting used to.Writing a "TCP stack library" for Oberon would probably DWARF the size of the full Oberon OS(which is <2mb). Oberon's power is that it avoids overly complex "protocols" like TCP, whichare anything but minimalistic. Oberon has it's own, sleek little network based around the Nrf24l01RF chip.The way to approach TCP, if you just must have it, is to establish a serial-to-tcp-bridge. The ESP8266is a good route. The ESP8266 has a SoC to handle the "network stack" so the heavy lifting is doneby actual hardware and not software. With this arrangement, you talk to the ESP8266 witha standart UART/Rs232 library and any TCP functionality is performed by the ESP8266, whichis purpose built for networking.This is a neat all-around solution:https://github.com/jeelabs/esp-link

author: Kalvin
author_rank: Super Contributor
timestamp: July 17, 2016, 06:20:16 pm
content: Quote from: captbill on July 17, 2016, 05:40:34 pmIf you take a look at the code and RAM size requirements of some of the TCP/IP-stack implementations for the ARM processors written in C, the requirements seem typically vary from 60 KB to 100+ KB and onwards, depending on what services are needed.

author: rstofer
author_rank: Super Contributor
timestamp: July 17, 2016, 07:20:55 pm
content: Quote from: captbill on July 17, 2016, 05:40:34 pmThe thing is, I need a bidirectional server port to which I may make a TCP connection for a console keyboard/typewriter (this 'device' would only be connected when required), a unidirectional server port to which I will almost always connect a card reader and a TCP client port to connect to a printer/plotter. These are all virtual devices for an IBM1130 I built in an FPGA. The entire reason for considering any particular language, in terms of this project only, is the availability of a TCP/IP stack that will support multiple streams at a reasonable data rate. The printer/plotter should be wire speed but the others can be the equivalent of 19.2 kBaud although faster is always better.The way I see the networking going is that the 2 servers are waiting on external requests. They may, or may not, get them depending on the job. The TCP client will make a connection to an existing LaserJet as required. A complicating fact is that the same LaserJet is used for both plotter and printer output. I need some kind of spooler to queue up the jobs - probably to an SD card. It would be better if the printer stream went to a terminal session as well because there is little point in printing a job listing if it didn't compile. So the idea was to spool both streams and have some kind of graphic display and a joystick to select output files and either print them and/or delete them.I had planned to use one of the higher speed ARMs that includes the MAC/PHY. I am currently using an LPC1768 (mbed) to handle the plotter stream but I would like to step it up a notch and get rid of my UART ports.

author: nctnico
author_rank: Super Contributor
timestamp: July 17, 2016, 09:43:49 pm
content: There are also the Wiznet network chips (for wired network) which use SPI. Usually SPI allows the use of FIFOs and DMA.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 17, 2016, 11:39:16 pm
content: Quote from: nctnico on July 17, 2016, 09:43:49 pmI've just been playing with these - starting off from knowing nearly zero about ethernet/TCP etc. I got it running pretty quickly - main issue was the datasheet isn't very clear in some places.The W5500 is pretty cheap, includes the PHY and supports SPI up to something like 80MHz. Because it handles all the low-level stuff, you don't need particularly low latency, just empty the buffer fast enough.I was using it with a PIC32MZ, which actually has ethernet onboard, but needs an external PHY, but the Wiznet chip just made things really easy so was a good solution for what I was doing.

author: richardman
author_rank: Frequent Contributor
timestamp: July 18, 2016, 02:13:42 am
content: Quote from: westfw on July 11, 2016, 05:33:18 amI knew the reason you asked (since we had a few discussions off-the-forum on similar subjects) and hence I did not contribute to this thread so far. Anyway, I think the answer really is that the language designer(s) invent a new language for their own purpose (e.g. Ritchie wanted something to rewrite Unix in), and then the language popularity grow organically because users like them, often beyond the scope of the original designers' parameters.For example, I was pretty surprised to learn about micro-python. Certainly "embedded" and Python don't sound like they should have much in common but there it is. The guy ran a successful KickStarter and seems to continue to have followers and fan. If one asks the micro-Python users why they choose the board, I wonder how many what the answers would be.

author: rstofer
author_rank: Super Contributor
timestamp: July 18, 2016, 03:23:03 am
content: Quote from: mikeselectricstuff on July 17, 2016, 11:39:16 pmI ordered a board with the WZ5500. The board has only the WZ5500 and a bunch of pins in a header. This will allow me to connect it to any of the uCs I have laying around. The Wiznet development board was pretty underwhelming in terms of on-chip RAM.I have a few STM43F boards laying around so I should be able to come up with something.BTW, the WZ5500 can handle 8 sockets. More than enough for my needs.

author: captbill
author_rank: Contributor
timestamp: July 18, 2016, 05:03:01 am
content: Quote from: rstofer on July 18, 2016, 03:23:03 amSince you need high throughput the WizNet sounds like the best route . There is someone at the Oberon mailing list that is working with the WizNet.I specifically remember the "WZ5500" ,as a matter of fact. I would ask around at oberon-request@lists.inf.ethz.ch and you might find what you need.

author: rstofer
author_rank: Super Contributor
timestamp: July 18, 2016, 05:25:04 am
content: Quote from: captbill on July 18, 2016, 05:03:01 am