I am new in MbedOS.
I am so confused about following questions.
1. What's the difference between yotta and CLI?
2. How do I port the MbedOS to my board?
3. What's the difference between Mbed 2.0 and 3.0?
Thank you..
Answers inline
What's the difference between yotta and CLI?
Yotta is the build tool used to build mbed v3 projects. mbed CLI is the tool used to build mbed v5 projects. The breif history is v3 was not backwards compatible with v2, aka mbed classic, so we took the best parts of v3 and the best parts of v2 and put them together to form mbed v5. In mbed v5, just like in v2 you can use the online compiler (https://developer.mbed.org/compiler) or you can compile offline. The tool known as mbed CLI is the same tool that sits behind the online compiler, its just been wrapped up so you can use it on your machine if you prefer. (ie you can run mbed compile on your machine instead of clicking the compile button on the online compiler)
How do I port the MbedOS to my board?
Vendors are in the process of adding mbed OS 5.0 support to most of the mbed boards on the website. If your board isn't supported yet then hold tight, it will be soon. If you want to add support for a board you have created then you can apply via the mbed enabled program (https://www.mbed.com/en/about-mbed/mbed-enabled/).
What's the difference between Mbed 2.0 and 3.0?
mbed 2.0, also known as mbed classic, was an abstraction layer that made it easy to use traditional microcontroller peripherals. mbed 3.0 introduced an interrupt driven OS along with some really awesome improvements for low power and full stack IoT development. mbed 5.0 takes the best parts of both and combines them in a way that is backwards compatible with mbed 2.0. The biggest difference between 3.0 and 5.0 is the underlying thing in 3.0 was interrupt driven while the underlying bits in 5.0 is the Keil RTX v5 RTOS.
Related
Can ios apps be compiled on the new M1 chipset?
Is there any schedule for official support?
The short answer is yes.
The latest version of XCode (version 12) is compiled as a universal app. This means that it runs on both Intel-based and Mac Sillicon machines natively. From Apple's website:
Xcode 12 is built as a Universal app that runs 100% natively on Intel-based CPUs and Apple Silicon for great performance and a snappy interface.* It also includes a unified macOS SDK that includes all the frameworks, compilers, debuggers, and other tools you need to build apps that run natively on Apple Silicon and the Intel x86_64 CPU.
This means that you should be able to compile iOS with the latest version of XCode without a problem. It would be kind of crazy for Apple to release professional hardware (MacBook Pro) without this capability.
Keep in mind that a number of third party applications may not work well on the ARM machines yet. VSCode is not currently supported on M1 devices (although Microsoft have said that it's coming). VSCode is an Electron based app which currently can't be emulated with Apple's Rosetta II platform. You might not use VSCode, but keep in mind that any Electron based apps that you use may not work straight away.
If you exclusively use XCode and don't critically rely on any third-party apps you should be ok.
EDIT: I just noticed that you tagged your post for react-native. Information is pretty slim for compatibility at the moment, so I would be cautious. If you need a Macbook Pro to do commercial work or school projects right now then you run the risk of things not working as intended. The M1 MacBooks will undoubtedly support everything that you need as a developer in the future and they're particularly great candidates for iOS development because of the parallels made possible by the shared ARM architecture.
If you're relying on a new machine to get work done right now, going with an Intel-based machine is probably the best option. For reference, I recently got an Intel-based 16" MacBook Pro with work because I need to get things done right now without any issues. The commercial value far outweighs the potential benefits that an M1 machine might bring in a year or two. If you're ok with running into some issues over the next few months, I'm sure that the M1 machines will provide plenty of value for years ahead.
While there are problems that do not allow compiling the application.
brew and cocoapods are installed in the console with rosetta enabled.
pod install / update fails because flipper and some parts of RN are not supported by the platform
if you use expo - without cli then everything is ok
updates: now cli working (after update all - homebrew, cocoapods and other to last version)
from what I know, iOS app only compiles on Mac os, so it should work with whatever macOS uses.
It was old challenge for me but I have succeed to build my own embedded system based on a 80188 INTEL ( like 8086). I am using the compiler C 4.5 from Intel. As I want to go further I would like to integrate the 8087 coprocessor.
This technology is older that 40 years...
Before spending time to wire the 8087 on by board I am trying to use the 8087 emulator given by the compiler. IC-86 version 4.5 from INTEL.
I cannot find the way to link the E87.lib and relocate the library in my project.
Does someone could share examples of link/relocate using a 8087 on an embedded system?
Sounds that the libraries given for the 8087 can't be relocated in the 20-bits addresses?
If Mbed OS is open source then why do you have to use a cloud compiler to compile the software? Is the source code for Mbed OS open but the the cloud compiler is closed source?
Just looking for clarification amongst marketing jargon.
SW
There seems to be some confusion here between Mbed OS which is a open source project and the Mbed Compiler Service, which is a tool that makes getting started with Mbed OS super easy.
Mbed OS is open source, you can find it here : http://github.com/armmbed/mbed-os, i encourage you to contribute by submitting a Pull Request.
The online compiler service is run by the Arm Mbed team to provide an easy way to get started with compiling your programs (there are some assumptions and sensible defaults in place so everything 'just works'). You can export your programs to a 3rd party compiler like Keil, IAR, or GCC / Eclipse for debugging if you need it. You can also use Mbed CLI offline to compile your code using GCC. (Fun fact, Mbed CLI is the same set of command line tools the online compiler uses).
Additional fun fact, the online compiler is using armcc (the same one that comes with Keil) where as GCC is the default for Mbed CLI (though if you have a liscense for armcc or iarcc you can use those with Mbed CLI as well.
Mbed OS is completely open source. There are various options to compile. So far, there are 3 toolchains that are supported by ARM mbed:
GCC ARM
ARMCC
IAR
Out of these 3, only GCC ARM is free while others have free evaluation versions with limited features unless you buy them.
In short, you can download mbed OS and then compile it for a target using any of the toolchains which may or may not be open source.
Question 1
If I want to build an application with OpenCL support, do I have any guarantees that the OpenCL.lib implementation from my vendor is able to work with all devices from other Vendors? If yes what's the difference between the implementation?
Question 2
Is it possible to use different OpenCL versions in the same application? For example AMD has released a preview driver for OpenCL 2.0 support. On the other hand the lovely company called Nvidia is still trying to ignore everything past OpenCL 1.1. It would be nice if I could write platform specific code in different versions.
1: On Windows, OpenCL.lib is a static wrapper around OpenCL.dll, which is the ICD loader, and exposes all of the available platforms. It is provided by Khronos and redistributed by the OpenCL platform vendors. So go ahead and link to it; it will work with whatever is installed (although if nothing is installed your application won't run because it can't find OpenCL.dll; this is solved other ways).
2: Yes. As long as the ICD loader is the latest, you can get at the newer API on newer platforms / devices. Just don't use new API on old devices; that will crash or worse.
It used to be that the beta 2 SDK couldn't run on the same computer as any other Kinect hacking software. Is this still true? Can I incorporate OpenNI and the SDK in the same project now?
That's a tricky one. Theoretically yes. The practical problem, however, is that when working with OpenNI, you need an OpenNI-compliant driver. The usual choice for that is SensorKinect. The Kinect for Windows SDK requires Microsoft's own driver, which is incompatible
with OpenNI. Having two drivers operate at the same time is not possible.
So, Kinect for Windows SDK and OpenNI are mutually exclusive. Exchanging the driver is necessary when switching between libraries.
One possible way to make the SDK and OpenNI work at the same time would require you to write a OpenNI-compliant sensor module, which uses Microsoft's Kinect driver. Nobody has done this before, to my knowledge, and I'm not entirely sure that it would work. Check the OpenNI Programmer Guide for more information on OpenNI's architecture, if you intend to pursue this path.