I was reading about the language "Lua" and I was confused with the three following lines :
Lua is designed primarily for embedded systems and clients .
The only competitor to Lua back then was TCL which was meant to be embedded into applications .
Lua is intended to be embedded into other applications,
So , what is the difference between the meaning of word "embedded" in the first line and the word "embedded" in the second and third line .
What does it mean for a language to be embedded into other applications ?
According to Wikipedia
An embedded system is a computer system with a dedicated function within a larger mechanical or electrical system, often with real-time computing constraints.
Typical examples include cars or coffee makers, where computers are embedded into the system to fulfill certain tasks.
The typical constraint is that embedded systems are often less powerful than a typical desktop computer due to cost and energy constraints. Therefore, languages to be used on embedded systems should allow for a lightweight execution. This is how "embedded" is used in the first line.
The second and third line refer to the usual application of Lua:
It is meant to be used to extend the functionality of existing programs. For example think about a coffee maker where you can specify your own coffee recipes. Then the actual control program of the coffee machine is written for example in C, while you can specify the coffee recipe in Lua. In this way, your coffee recipes that you write in Lua are embedded in the C application.
Application of Lua in embedded systems
Due to a comment that questions the use of Lua in embedded systems, here some examples taken from Wikipedia's list of Lua applications:
The Canon Hack Development Kit (CHDK), an open source firmware for Canon cameras, uses Lua as one of two scripting languages.
Cisco Systems uses Lua to implement Dynamic Access Policies within the Adaptive Security Appliance (ASA), and also SIP normalization in Cisco Unified Communications Manager (CUCM).
Custom applications for the Creative Technology Zen X-Fi2 portable media player can be created in Lua.
Lego Mindstorms NXT and NXT 2.0 can be scripted with Lua using third-party software.
LuCI, the default web interface for OpenWrt, is written primarily in Lua.
NodeMCU uses Lua in hardware. NodeMCU is an open source hardware platform, which can run Lua directly on the ESP8266 Wi-Fi SoC.
Sierra Wireless AirLink ALEOS GSM / CDMA / LTE gateways allow user applications to be written in Lua.
The Perimeta session border controller from Metaswitch Networks uses Lua as a scripting language to manipulate SDP data on the fly.
Rockbox, the open-source digital audio player firmware, supports plugins written in Lua.
The Squeezebox music players from Logitech support plugins written in Lua on recent models (Controller, Radio and Touch).
TI-Nspire calculators contain applications written in Lua, since TI added Lua scripting support with a calculator-specific API in OS 3+.
The use of the term "embedded" here is not the the same meaning as the [embedded] tag, in SO, or even the term "embedded systems" as it is conventionally used.
The link in the Wikipedia page is erroneous and misleading - the link is to "embedded systems", but the citation refers to it being an embeddable language - which is not the same thing.
Don't confuse these things - I have been developing embedded systems for many years and don't see Lua featuring anywhere. It could of course be used an an embedded language in an embedded system (for end user customisation for example), but it is not an embedded systems language as such.
1 states that Lua is for devices which have a certain purpose instead of many.
2 and 3 states that Lua may be implemented in, for instance, a C++ application to do a function.
For instance, a part of an application can use Lua, but it can also mostly use C++.
Related
I'm interested is it possible to install and use Android Things(former Brillo) on custom produced hardware?
I can see from the official documentation there is preselected and certified SoMs listed, but I'm interested in using my own hardware.
Is it possible to have best of both worlds - use the familiar to me Android & Android Things but run it on proprietary hardware?
If not, what other options do I have - I researched about micropython, but apparently it seems it also comes with designated board(pyboard).
So my question is what are options to not thinks too much about the firmware on the device(and write C code), but focus on more higher-level business logic and programming languages(Java, Python).
Android Things isn't open source, so you can't put it into that isn't officially supported.
If you're looking for custom options, you will need to find a compiled language like C that works for that board. While C may be a bit intimidating, you may be able to find languages that compile to similar machine code. Rust and Go may work on microcontrollers too if you check.
I'm not too familiar with micro python. It says that it compiles to bare metal/machine code, so I believe you should be able to use it on other boards. While they may officially support the compiler for one board, the community may have support for additional microcontrollers.
We are developing an Application which runs on various plattforms (Windows, Windows RT, MacOSX, iOS, Android).
The Problem is how to manage the different localizations on the different Platforms in an Easy Way. The Language Files on the different platforms have various formats (some are xml based, others are simple key-value pairs and others are totally crazy formats like on MacOS)
I'm sure, we aren't the first company with this problem, but I wasn't able to find an easy to use solution o achive the possibility to have one "datasource" where the strings are collected in different languages (the best would be an User Interface for the translators) and then can export it to the different formats for the different platforms.
Does anybody has a solution for this problem?
Greetings
Alexander
I recommend using GNU Gettext toolchain for management and at runtime use either
some alternate implementation for runtime reading like Boost.Locale,
own implementation (the .mo format is pretty trivial) or
use Translate Toolkit to convert the message catalogs to some other format of your liking.
You can't use the libintl component of GNU Gettext, because it is licensed under LGPL and terms of both Apple AppStore and Windows Live Store are incompatible with that license. But it is really trivial to reimplement the bit you need at runtime.
The Translate Toolkit actually reimplements all or most of GNU Gettext and supports many additional localization formats, but the Gettext .po format has most free tools for it (e.g. poedit for local editing and Weblate for online editing) so I recommend sticking with it anyway. And read the GNU Gettext manual, it describes the intended process and rationale behind it well.
I have quite good experience with the toolchain. The Translate Toolkit is easy to script when you need some special processing like extracting translatable strings from your custom resource files and Weblate is easy to use for your translators, especially when you rely on business partners and testers in various countries for most translations like we do.
Translate Toolkit also supports extracting translatable strings from HTML, so the same process can be used for translating your web site.
I did a project for iPhone and Android which had many translations and I think I have exactly the solution you're looking for.
The way I solved it was to put all translation texts in an Excel spreadsheet and use a VBA macro to generate the .string and .xml translation files from there. You can download my example Excel sheet plus VBA macro here:
http://members.home.nl/bas.de.reuver/files/multilanguage.zip
Just recently I've also added preliminary Visual Studio .resx output, although that's untested.
edit:
btw also my javascript xcode/eclipse converter might be of use..
you can store your translations on https://l10n.ws and get it via they API
Disclaimer: I am the CTO and Co-Founder at Tethras, but will try to answer this in a way that is not just "Use our service".
As loldop points out above, you really need to normalize your content across all platforms if you want to have a one-stop solution for managing your localized content. This can be a lot of work, and would require much coding and scripting and calling of various tools from the different SDKs to arrive at a common format that would service the localization needs of all the various file formats you need to support. The length and complexity of my previous sentence is inversely proportional to the amount of work you would need to do to arrive at a favorable solution for all of this.
At Tethras, we have built a platform that alleviates the need for multi-platform software publishers to have to do this. We support all of the native formats from the platforms you list above, and can leverage translations from one file format to another. For example, translate the content in Localizable.strings from your iOS app into a number of languages, then upload your equivalent strings.xml file from Android or foo.resx from Windows RT to the system, and it will leverage translations for you automatically. Any untranslated strings will be flagged and you can order updates for these strings.
In effect, Tethras is a CMS for localized content across many different native files formats.
I would like to write some applications involving IP cameras. AXIS has a greatoverview on their pages. They provide API for their cameras called Vapix and they also indroduce Open Platform SDK, which is supposed to be some form of SDK that enables developers to write code specifically for the devices. E.g. communication with server over your own protocol.
The problem is - they require registration and an entrance fee to enroll in the developer program. My question is, though, WHICH language do they support? Is it C, Java?
Note: I am not talking about the Vapix API, I am talking about the Open Platform SDK.
It is written in C/C++. Note that they have their own compiler based on GNU Linux.
I've been searching for some information regarding microcontroller programming but the info I find is either way over my head or doesn't appear to exist. I'm looking for something easier to digest! I'm relatively new to programming and come from an SQL DBA background and decided that it would be quicker for me to learn some programming fundamentals and then teach myself Delphi than it would to get some changes implemented through my company's insane design change note system!
After a couple of years of Delphi programming I can cope with writing database applications without too much bother and I want to be able to move on a level.
We use PIC microcontrollers on our PCBs; mainly the PIC18F family. The software on the PICS is written in C but there are parameters values that are written to by a Delphi application that interface with the PIC using an ActiveX control.
Basically, SQL Database holds parameter info, Delphi client app retrieves those values, passes them to the ActiveX controll which does all the low level stuff on the PIC. For example the internal EEPROM will have a map and within any particular address a value will be stored to switch something on or off or hold an integer value etc.
I've gotten hold of an MPLAB kit which has an ICD2 device that can read and write values to the internal EEPROM and I understand how to change these hexadecimal values using MPLAB software.
My hope isn't to learn embedded microcontroller programming; rather that I can write a Delphi app that will do something similar to MPLAB software. E.g read and write values to certain memory addresses within the EEPROM.
I'd be very gratefull if anyone can point me in the right direction of any libraries or components that may already exist for bridging this gap between simple Delphi form application and writing low level PIC EEPROM. I doubt such any easy interface exists but I thought I'd ask. To summarise I want to be able to have a simple form app, with some edit boxes that the user types in or selects from dropdown boxes, parameter values, to click on a button and to assign those parameter values to specific EEPROM memory addresses. Thank you for reading and any comments would be gratefully received.
Regards
KD
I'm a big fan of MikroElectronika and have used their Pascal tools for pic16 series MCU with great success (touch screen interfaces, ZigBee, ...).
http://www.mikroe.com/
Updated 2015 Answer:
Why not a Raspberry Pi with FreePascal and Lazarus? The boards cost from $5 to $25 US, as of this date, and the development tools are free.
Original 2012 Answer:
If you like to use Pascal, you might find Free Pascal useful on small embedded systems, but the minimum I believe you will find it can compile on is a Linux-based ARM embedded system. The fact that you use pascal on both sides is very unlikely to help you accomplish anything major.
If you want to go all the way down the the smallest PIC microcontrollers, you'll find that it's almost always a variant of C that you'll be using. Frankly, at that level, the differences aren't that much. If you can write Pascal, you can learn enough C in a day, to use with microcontrollers.
Don't be scared to use the native language that most microcontrollers support. My personal favorites are the Rabbit microcontrollers, formerly from Z-World, now from digi -- I think I paid about $100 US for the first board and development toolkit.
Interfacing such an application with delphi is pretty easy, usually these days, I would interface using TCP/IP over either wired Ethernet, or wireless (Wifi). But if you really want to you could use RS-232 or RS-485 serial links. (RS-485 has the advantage that you can wire it up to 5 miles long.) If I was using a serial link, I'd probably implement something like Modbus on both sides, if I just wanted to send some numeric data back and forth, and if I was doing something text-oriented, I think I'd write a mini HTTP web server on the embedded controller, and most boards these days come with enough HTTP server demos to make that drop-dead easy.
Delphi outputs Win32 and Win64 native applications you can write software that can interact with certain devices if the PCB has serial comunication or I2C you can write software that in Delphi that it will interact with the physical device.
But if you want to programm the devices yourself , write software that will run on this devices you can't do it in Delphi. I suggest you buy an Arduino it's an excellent envoirment for beginners in microcontroller programming.
If you have the source code of your pic microcontroller then you can implement the code in C to read from Serial, USB or some other interface available in your hardware and write it to the eeprom. This way its easy to write the app in any high level language like delphi, c++, etc.
Or you can write your PIC application using the mikropascal compiler from mikroeletronika that its very good and I've been using for a long time, but as you can see you will have to implement some mecanism to read from the interface and write to your eeprom as I've mentioned before.
This compiler comes with a lote of librarys to work with many devices. You should take a look on it, its not free but the price is low and in their site you can find samples and sample boards to test it.
One option, if you want a simple interface to write to the PIC EEPROM, is to use the ICD command line utility. Unfortunately it is not available for the ICD2, but the PICkit 2 and 3 (which are cheap), ICD3, and RealICE have command line utilities that give you the ability to write to the EEPROM (google pk2cmd). In Delphi, you could just wrap a very simple set of command line calls to pk2cmd.
We have a range of PC demonstration programs for our microcontroller products. The programs typically connect to a USB HID chip on the microcontroller board. The USB chip acts as a communications bridge, allowing the programs to communicate with the micros over SPI/I2C/UART. The programs can configure the micros, and get back status information to display to the user.
We are now looking to build some standalone demonstrations using single board PCs. We would like to reuse as much as possible of our existing demo app source code. Ideally, we could just run them as-is.
Does anybody have any advice on the best way forward? The basic options seem to be WinCE or XP Embedded boards. WinCE boards seem to pull less power, which would be an advantage from a battery life point of view.
Our existing demos are built either in C++ under Borland Builder, or in Delphi.
Thanks in advance.
EDIT: see my answer below with info from a board vendor.
Free Pascal/Lazarus can compile some forms of Delphi apps to WiNCE/arm. Even visual ones.
There isn't a Delphi version for WinCE, so you would need to rewrite the applications. The same applies for the Borland Builder's control libraries. Only if you have used plain Win32 API, you would be able to port your application to WinCE easily. You may also encounter problems with the hardware access part. The Serial Port driver may not work as is. Also, you need to find a WinCE board that can act as USB host and provides HID drivers (this isn't very common).
In conclusion, I believe that you would be better of with Windows XP Embedded boards. These should run your applications as they are.
As an update, and for future reference, I thought I'd post the results of our discussions with a WinCE board vendor here. Caveat: I haven't actually tried any of this.
The bottom line is that there isn't a straightforward way to do what we were hoping for (i.e., re-compile our existing demo applications to run under WinCE). The reason is that the generic HID drivers and standard APIs that exist in desktop flavours of Windows just aren't there in WinCE.
To talk to HID devices in WinCE you need to implement a custom HID driver. This needs to support an interface allowing user mode applications to communicate with the driver, and to construct HID reports to be sent to the physical device. As this interface would itself be custom, application code needs to be updated accordingly.
WinCE application development is generally done using Visual Studio and the Microsoft compilers. The approach recommended to us was:
Create a custom HID class driver. This could be based on, for instance, the Microsoft keyboard HID driver.
Create an API for talking to the driver.
Use .net to create our GUI applications, and use PInvoke to actually talk to the API.
The end result of all this head-scratching is that to avoid the time and learning curve associated with this approach, we're going to go for a board running XP. We can then use our existing demo applications straight out of box. The trade-off is that we'll have to live with substantially reduced battery life.