I'm working on MPSOC, specially STM ST40 (SH4 base) and ST231 and I'm wondering which OS i can use on these to port a parallel application, I already had a look at STLinux which is the STM distribution of a Linux platform for their MPSOC (which unfortunately doesn't work well for ST231 coprocessors) and I also had a look at OS21 which is a task based OS.
Any information about other RTOS are warmly welcome! (specially those with libc and pthreads :)
Those 4 came to my mind:
MicroC/OS-II: Its free and simple, but i think there are too few good resources available
LibeRTOS: I can recommend that. I used it several times for different projects. It's good it's fast and the dual kernel concept is really well done.
RTLinux: Can't tell you much about that one. Only used it once for a very small project and didn't get deep "behind the scenes" But it was fast and reliable. (and very expensive)
VxWorks: Awesome OS... From Wikipedia:
multitasking kernel with preemptive and round-robin scheduling and fast interrupt response
Memory protection to isolate user applications from the kernel
SMP support
Fast, flexible inter-process communication including TIPC
Error handling framework
Binary, counting, and mutual exclusion semaphores with priority inheritance
Local and distributed message queues
Full ANSI C compliance and enhanced C++ features for exception handling and template support
POSIX PSE52 certified conformance
File system.
IPv6 Networking stack
VxSim simulator
Supports: C/C++/JAVA
If money is no problem: Use VxWorks! You can do anything: Upgrade your fridge, built a war machine or fly to Mars ;-)
Otherwise check out LibeRTOS...
If you really want ot use an RTOS, be prepared to use a native API that is way more efficient and streamlined than pthreads...
I have used Micrium's µC/OS-II on several projects, on SH4 and a couple of different ColdFires. I continue to recommend it for new projects today.
Micrium has just announced a major upgrade to be called µC/OS-III that will add unlimited preemptively scheduled threads, as well as a round-robin scheduler for equal priority threads. It doesn't appear to be for sale yet, however.
If you need the capabilities, they also have a FAT file system, a PEG graphical UI library, USB device and host, and TCP/IP available for additional license fees.
Source code to everything is included in the price, and I've always found their support to be friendly and knowledgeable.
With the processors you mention you seem to be into set-top boxes.
You have the choice between the ST Linux distro, which is not very stable and the OSXX distro, which is proprietary for ST, but much more stable and with nice tools for debugging and the like (I'm not so sure about OSCC and libc/pthreads)
Barebones/AMP - because it allows 100% control and it allows the lowest latency.
Using Linux or FreeRTOS is very comfortable but it comes with a price tag.
Related
I worked with smalltalk as hobby when Pharo born. A lot of years passed without touching it, and I'm sure a lot of things happened in smalltalk world. Now I have some projects in my mind and my main idea was to develop using python but I'm thinking to retake this enviroment I loved. One of this projects is about using opencv for recognition from a Webcam, recognition of screen changes in other windows, and painting specific things on screen (a board game).
My idea is to develop on Linux and Windows, and release on Windows/Linux/Mac. Right now which ST flavour fits the interaction I need? Right now what's the main difference between Pharo an Squeak?
Thanks.
I'm sure there are more qualified people around to answer this question. I'll try to be as objective as possible, but these are only my opinions others can see it otherwise. I will write only short description for each.
The interaction would have to be done via FFI.
I also don't know every dialect there is. For example, I haven't heard of trufflesqueak before.
To fit your picture windows/linux/mac:
These smalltalk(s) have the VM support you require (in random order): GemStone, Pharo, Squeak, Cuis-Smalltalk
GemStone/S - is a distributed Smalltalk system with a massive, persistent memory. Offers free usage and also has a commercial support. Very nice Smalltalk with many platforms supported. Windows is supported only as client.
Pharo is a open-source implementation which was originally forked from Squeak. Nice environment, which you know, but it needs to cleanup the code. It has very fast development cycle. In my eyes, the newest VMs have stability issues. The description here on SO.
Squeak the original Smalltalk-80 implementation with plenty of legacy code, but the VM is quite stable and lately it works very nice. The description here on SO.
Cuis-Smalltalk is a multiplatform Smalltalk-80 implementation. Cuis shares the OpenSmalltalk Virtual Machine with Squeak, Pharo and Newspeak. I did not see any projects created in Cuis, maybe somebody can correct me.
Other interesting smalltalks:
Dolphin (windows only) - nice smalltalk for Windows. Supports integration with Windows and calling windows code.
Smalltalk/X - for Windows and Linux VM (there is MacOS VM port for Smalltalk/X but it is not public yet, maybe it will appear on Smalltalk/X-jv later on). Developed by eXept mainly by Claus Gettinger. There is an independent branch Smalltalk/X-jv - list of features and the description on SO.
Commercial Smalltalks
You can try these out, but you for commercial use you have to pay license fee.
VAST owned by instantiations - they are working on MacOS support but it is not there yet. Very mature Smalltalk with commercial support.
Cincom's VisualWorks - The development is somewhat lacking lately but still Smalltalk with company behind it.
Pharo Spec (the widget library) has a Gtk3 backend that can be used to develop application in any platform (there are a few targeting windows), and I know there was work done using OpenCV, but you will have more luck asking that in our discord channel (https://discord.gg/QewZMZa) or any of our mailing lists (check links here: https://pharo.org/community).
What are the differences between the different Rebol 3 branches, especially with the new REN branch?
Is it the platforms they'll run on, the feature set, code organization, the C standard compliance?
This is an answer destined to become outdated, hence set to Community Wiki. This information is as of Sep-2015. So if updating this answer after some time has passed, please modify the date as well.
Binary download of Rebol3 from rebol.com
Last build was 5-Mar-2011 and pre-dates the open source release.
No GUI support, no HTTPS support, no serial port support, no UDP support, no smart console...
No 64-bit builds. Binaries are for Windows x86, OS/X (PPC or x86), Linux (x86 or PPC), FreeBSD x86.
While Rebol2 binaries are archived for many "esoteric" systems (BeOS, AIX, Windows DEC Alpha, QNX, Solaris...) similar binaries were not provided for Rebol3. The only "weird" build is for Amiga, and only an OS4 PowerPC Amiga. No successful builds of Rebol3 for Amiga emulators have been reported.
Open source release of Rebol3 on Github rebol/rebol
Open-sourcing was on 12-Dec-2012.
The rebol.com binary downloads were not rebuilt as part of this release. However, a community member (#earl here on SO) created a build farm at rebolsource.net that follows this GitHub master whenever it updates. Given that GitHub's rebol/rebol master hasn't been updated since March 2014, this dynamism is currently underused.
Building the source at time of release got an executable not distinguishable (?) in functionality from the builds on 5-Mar-2011. This suggests few changes to the source were made besides some cleanup and Apache-licensing edits to prepare for publication.
Minor patches and bugfixes were integrated sporadically, with most PRs sitting idle. Last PR accepted at time of writing was Mar 3, 2014, which is over a year ago.
The most noticeable "breaking" PR that did get approved was to repurpose the FUNCTION name. It was considered to be worth breaking the old arity 3 form to let the word be taken for the much more useful implementation as locals-gathering FUNCT. (This also brought Rebol in alignment with Red, whose FUNCTION is arity 2 and acts similarly.) FUNCT was kept around as-is for legacy code.
The most major non-breaking PR that was taken is probably not requiring blocks around IF, UNLESS, or EITHER bodies. This has been received well among those who know it's there, as fitting the freeform and non-boilerplate philosophy of the language. It allows some code constructs to get "prettier" and gives programmers more choice, while it doesn't seem to cause any more problems than anything else. It's certainly less of a speedbump than if [condition] [...], in fact it seems almost no one knows this feature got added, so it must not be biting anyone. (If anyone can bend ears over at Red to make sure it gets IF and IF/ONLY then that would be ideal.)
RETURN/REDO was removed. Rationale was that it permitted functions to effectively behave with variable arity, and that this was unnecessary and took terra firma away by no longer being able to predict a function's arity from its spec. Perhaps this stance warrants a second look...as Lisp users who are pressuring for the addition of Lisp-style macros seeming aren't worried about that very much. (Here in the StackExchange universe, this provoked a Programmers.SE question Would Rebol (or Red) benefit from Lisp-style Macros?, which hasn't gotten much in the way of answers yet.)
The fork by Saphirion: "Saphir"
Prior to the open-sourcing of Rebol, Saphirion AG had a special relationship with Rebol technologies. They had access to the source and were taking responsibility for most of the development work for Rebol3 GUI features. They also added several other things like HTTPS.
Saphir is available as a binary download from their website, but only provided for 32-bit Windows. There was at one time an experimental .APK for Android from Saphirion.
Some (but not all) of Saphir's source was released after the open-sourcing. Notable omissions were the android build and some Rebol3 code for encapping...a way of injecting compressed scripts and resources into binaries of the interpreter without needing to recompile it.
(Note: Under Apache2 license there is no requirement to release source code for one's derived work.)
"Community" Integration at Rebolsource on GitHub
With the GitHub rebol/rebol being held up on integrations, a fork at rebolsource/r3 was established to be a "community build" where work could be staged.
Rebolsource changes were conservative, seemingly aimed toward showing process for how GitHub's rebol/rebol might adopt changes "in the spirit in which Rebol was conceived" should that repository be delegated to the community. (For that spirit, see this.) Hence it integrated non-controversial bugfixes and tweaks, instead of large third-party cryptography libraries for implementing HTTPS. Also: no allowance for adding build dependencies besides a C compiler (no GNU autotools, for instance).
Binaries for the community build were produced on an as-needed basis for those requesting them who could not build it themselves.
Atronix Engineering's Rebol "3.0" at Github zsx/r3
Atronix is an industrial automation solutions provider that uses Rebol. How they do so is described in a video here by David den Haring, director of Engineering, and their ZOE software is built on their version of Rebol.
After the open sourcing, Atronix partnered with Saphirion to port the GUI to Linux. Atronix publishes their source publicly as it is developed, and David den Haring notes in the video above that they have only one proprietary component they developed (an industrial control driver). Other than that they are happy to share the source for all Rebol development they do.
Atronix integrated the 64-bit patches from Rebolsource, created a Windows 64-bit target, and offer up-to-date binaries of their development branch for Windows and Linux x86/x64, as well as Linux ARMv7.
Besides having the features of Saphir, the Atronix build added support for CALL with /INPUT, /OUTPUT, /ERROR. It also added a Foreign Function Interface, implementing LIBRARY!, ROUTINE! and STRUCT! for communicating with non-Rebol dynamic libraries. It brings in encapping support as well on Windows and Linux.
Rebol's "religion" was at times at odds with expedience, so the Rebol-based build process was replaced when needed by hand-edited makefiles and Visual Studio projects. The FFI library introduced a dependency on GNU autotools to build.
All Atronix builds include the GUI, so there is no "Core" build. And again, only Linux and Windows.
Ren-C
(Bias Note: This fork is the initiative #HostileFork started, knows the most about, and will speak most enthusiastically about.)
Ren-C started as an an extraction of a Core build out of Atronix's codebase. That gave it features like HTTPS, the enhanced CALL, and Foreign Function Interface to essentially all the platforms that Rebolsource was able to build for. Updates Jul/Sep-2015 Ren/C supports line continuations in the console, user infix functions, several bugfixes...
Ren-C makes large-scale changes and fixes fundamental issues in R3-Alpha, which are tracked on a Trello that provides more information. There is a new FAQ as a GitHub wiki. Critical issues like definitionally-scoped returns have been solved, with continuous work on other outstanding problems.
Though Atronix's R3/View required some additional dependencies, Ren/C pushed back to being able to be built with nothing besides a C compiler, and eliminated all handmade makefiles/projects.
Beyond Windows, Linux and Mac in both 32-bit and 64-bit variants, Ren/C has also been built for smaller players like HaikuOS and yes, even Syllable. This is interesting more for the demonstration of how broadly turnkey builds of the C89 code work (simply as make -f makefile.boot) as opposed to there being a particularly large userbase of those particular OSes!
From the point of view of language rigor, Ren/C is pushing on modern techniques. Although it can still build as C89, it can be built as C99 and C11 as well. It has also been verified to build as C++98 through C++14, and with some strategic modifications under #ifdef __cplusplus it can take advantage of modern C++ as a kind of static analysis tool over the C code. Warnings are raised, type errors all fixed up, and it's "const correct". The necessary changes were carefully considered to make Rebol's baseline C code not just more correct but cleaner and clearer source across the board.
From a point of view of C developers, Ren/C should be stable, organized, and commented enough for anyone who knows C to "modify with confidence" and try new features. That means being able to implement definitionally scoped returns (actually written, but not pushed), or try developing features like NewPath.
From a point of view of architecture, Ren/C is intended to not have an executable at all...but to be a library for embedding a Rebol interpreter into other programs. It is now the basis for Ren/C++, which was designed to anticipate working with Red as well.
From a point of view of testing, Ren/C intends to whip everything into shape for engineering rigor and zero bug tolerance. This means avoiding practices like zero-filling memory to obscure uninitialized memory accesses, using Address Sanitizer, Valgrind, and a test suite that can pass the highest settings on both.
While enabling all the extra functionality has made Ren/C's executable nearly twice the size of Rebolsource's, there's not yet been any audit to see how this can be brought down. It has been confirmed that there are duplicate copies of Zlib and PNG encoding/decoding--for instance (Saphirion included LodePNG, likely to work around a bug in the existing PNG because it was easier than fixing it...yet did not mothball the previous code). Also, being able to do a build which selectively integrates only the codecs you want to use is on the agenda.
Ren/C currently has the stakeholders from Atronix and Rebolsource participating in its development and direction, which strengthens the likelihood that it may evolve into "the" Rebol Core. It is now being linked in as the code backing Ren Garden, and using a similar approach it may be set up as the library used by Atronix's R3/View...then Rebolsource...and perhaps ultimately rebol/rebol itself.
The fork by Oldes
(Bias Note: this edit is added 28-Feb-2019 by Oldes himself)
Forked from the community branch. Main focus on keeping the code close to the original Carl's release without blindly taking everything from Atronix/Saphirion but still trying to pick-up the good things from these branches slowly.
Not like Ren-C, this version is not trying to introduce new syntax, but rather be closer to the original Rebol2 and new Red language
Is there any software that helps me to implement GUI in LPC2478 microcontroller?
Is embOS compatible with LPC2478?
NXP LPC24xx is an ARM7TDMI core part. The question of whether Segger embOS is supported for this target is best answered by consulting the vendors support information (the answer is "yes" BTW).
However embOS is an RTOS not a GUI and while that may be helpful in presenting a GUI on a real-time application, it does not in itself provide a GUI. Segger do however have a GUI product - emWin - which can be used with or without an RTOS, and independent of embOS. The issue there perhaps is whether your particular display device is supported, although it is possible to develop your own or use the microcontroller to control the LCD directly.
Either way embOS and emWin are commercial products with good documentation and excellent vendor support - you would do just as well to ask your questions at info#segger.com.
Note that if you use Keil MDK-ARM Professional, then Segger emWin is included royalty-free.
We have a business logic that works with the file systems on OS that we want to implement on both Linux and Windows platforms. The language we have selected is Python for Linux and C# for Windows. GUI is not a priority for now. We were looking for ways to abstract the business logic in a way that we dont have to repeat the business logic (ofcourse I understand since it is related to file system, some code will differ from platform to platform).
Any ideas on how to implement it? Is C/C++ the only option. We dont want to use Java.
Thanks,
Pranz
yea, pick a common language for the logic first. Punting down in to C/C++ pretty much eliminates any of the real values to development that the Python and C# languages provide. Done write, MOST of your logic will be "Business Logic" with the rest glue to external services (i.e. databases, etc.).
So, you should pick a portable environment from the get go. Dropping down to C/C++ and linking it in is a viable alternative, but most likely not worth the time.
Mono is an option you'll probably want to look into.
Quote from the site for easy explanation:
Mono is a software platform designed to allow developers to easily create cross platform applications. Sponsored by Novell, Mono is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime. A growing family of solutions and an active and enthusiastic contributing community is helping position Mono to become the leading choice for development of Linux applications.
Either use Mono or Python.
Mono allows you to run C# .NET code on both platforms. Python can be executed on both platforms already.
Qt has cross-platform libraries for all sorts of things, including UI and file system. It does, however, use C++.
A project is looming whereby some code that I will be writing may be deployed on any hardware that potential clients happen to have. Its a business application that will be running 24/7 so I envisage that most of the host machines will be server type boxes but smaller clients might, for example, just have a simple PC.
A few more details about the code I will be writing:
There will be no GUI.
It will need to communicate with another bespoke 'black box' device over an Ethernet network.
It will need to communicate with a MySQL database somewhere on the network.
I don't have any performance concerns as a) the number of communications with the black box will be small, around 1 per second, and the amount of data exchanged will be tiny (around 1K each time), b) the number of read/writes with the database will be small, around 5 per minute, and again the amount of data exchanged will be tiny and c) the processing that needs to be performed is fairly simplistic.
Nothing I'm doing is very 'close to the metal' so I don't want to use languages that are too low level. Ease of development and ease of deployment are my main priorities.
I'm not expecting there to be a perfect solution so I can live with things like, for example, having to have slightly different configuration files for Windows machines than for Linux boxes etc. I would like to avoid having to compile the software for each host machine if possible though.
I would value your thoughts as to which development language you think is most suitable.
Cheers,
Jim
I'd go with a decent scripting language such as Python, Perl or Ruby personally. All of those have decent library support, can communicate easily with both local and remote MySQL databases and are pretty platform independent.
The first thing we need to know is what language skills you already have? This is likely to be a fairly big determiner of what choice you would ideally make.
If I was doing this I'd suggest Java for a couple of reasons:
It will run almost anywhere and meet the requirements you've outlined.
Its not an esoteric language so there will be plenty of developers.
I already know how to program in it!
Probably the most extensive library ecosystem of any of the development platforms.
Also note that you could write it in another language on the JVM if your more comfortable with Ruby or Python.
Sounds like Perl or Python would fit the bill perfectly. Which one you choose would depend on the expertise of the people building and supporting the system.
On the subject of scripting languages versus Java, I have been disappointed with developing command line tools using Java. You can't directly execute them, you have to (1) compile them and (2) write a shell script to execute the jar file, this script may differ between platforms. I recommend Python because it runs anywhere and it's got a great SQL library, mysql-python. The library is ready to use on Windows and Linux. Python also has a lot less boilerplate, you'll write fewer lines of code to do the same thing.
EDIT: when I talked about JARs being executable or not, I was talking about whether they are directly executable be the OS. You can, of course, double click on them to run them if your file manager is set up to do so. But when you're in a terminal window and you want to run a java program, you have to "java -jar myapp.jar" instead of the usual "./myapp.jar". In Python one just runs "./myapp.py" and doesn't have to worry about compiling or class paths.
If all platforms are standard PCs (or at least run Linux), then Python should be considered. You can compile it yourself if no package exists for your version. Also, you can strip the standard library easily from things that aren't available and which you don't need (sound support, for example).
Python doesn't need lots of resources, it's easy to learn and read.
If you know Perl, you can try that. If you don't use Perl on a daily basis, then don't. The Perl syntax is hard to remember and after a week, you'll wonder what the code did, even if you wrote it yourself.
Perl may be of help to you as it is available for many platforms and you can get almost any functionality by simply installing modules from CPAN.
Python or Java. They both are easy to deploy on both the server environments and the desktop environments you mention - i.e., Linux/Solaris and Windows.
Perl is also a nice choice, but it depends on how well you know Perl, how well other people that will maintain your code know Perl, and number of desktop users that are savvy enough to handle an install of the Windows Perl version(s).
As Java supports Python via Jython, I'd go with a JVM requirement myself, but I'd personally go with a Java application all the way for such a system you describe.
I would say use C or C++. They are platform independant, though you will have to compile for each platform.
Or use Java. That runs in a Virtual Machine so is truely cross platform and not a slow level as C.