This is the first time I am building yocto images. I first read this list of images in the documentation and selected core-image-sato-dev, since I wanted to have some image where I could do some hello world .
The doc says
core-image-sato-dev: A core-image-sato image suitable for development
using the host. The image includes libraries needed to build
applications on the device itself, testing and profiling tools, and
debug symbols. This image was formerly core-image-sdk.
Something that I misunderstood was that the development is using the host
Yes, I cannot find gcc in /usr/bin. So this image does not have the c compiler (it has make though)
So what should I do? Is there a way to add it? Or should I go for core-image-sato-sdk??
What exactly does this imply?
core-image-sato-sdk: A core-image-sato image that includes everything
in the cross-toolchain. The image also includes development headers
and libraries to form a complete standalone SDK and is suitable for
development using the target.
GCC or any other compiler is not meant to be part of that image. As the quote from the docs you've provided says, The image includes libraries needed to build applications on the device itself.
All core-image-sato-dev does it inherits core-iamge-sate and adds dev-pkgs to IMAGE_FEATURES which ships development packages.
What you're looking for is tools-sdk in IMAGE_FEATURES.
Related
This question already has answers here:
CMSIS & STM32, How to begin? [closed]
(2 answers)
Closed 1 year ago.
As I want to write an efficient program to use minimal RAM & Flash, I want to remove HAL library completely from my project & program only in registers.
I want to use cubeIDE for compiling & Debugging but I do not know how to remove HAL library from my project(It seems that HAL library created and attached to project by default when generating project).
Is there any practical way?
Best!
There is an option in STM32CubeIDE project generation which allows you to create empty projects.
The empty project comes with the following:
main.c : Mostly empty
syscalls.c : I don't know what it is for but probably useless.
sysmem.c : Implements _sbrk() function, which is used by malloc() & new()
startup_stm32[xxxxxxxx].s : Startup file in assembly. You can leave it as it is
[xxxxxx]_FLASH.ld : Linker script file. Most of the time, this can be left unchanged.
But you need some additional libraries & files.
CMSIS Library : This includes some core functions common to all Cortex M devices. The core library is header only, and it's the only one you need to get started. There are some additional CMSIS libraries, like the DSP library which you may need depending on your project requirements. I suggest downloading it from its official repository.
Official STM32 headers from ST : This is actually called STM32Cube[xx] (STM32CubeF4 for example) and includes the Cube & HAL framework you want to get rid off. But we're interested in CMSIS compliant device headers. You can delete the rest. It also includes a version of CMSIS which lags behind the official one. Since you can download the latest CMSIS from its official repository, you don't need the one included in Cube package. You can download the relevant package from ST. For example, this one is for F4 series.
Once you have the needed packages, you need to configure STM32CubeIDE such that your project uses the newly obtained libraries. Basically, you need to add some additional include directories and symbol definitions. And there is an additional system_stm32[xxxxx].c file, which can be found in STM32Cube package and needs to be included in your project.
Here you can find a somewhat related answer.
Here is an example STM32CubeIDE blinky project I've created for the Blue Pill board (STM32F103C8). It may be somewhat outdated but it's probably still useful.
The method I've described probably isn't very practical. Some people suggest creating a normal Cube & HAL project and than pruning the unused parts.
im using a script in my project and in this script for solve a simple math equation same "1+2-2+1" from string input i use
ExpressionEvaluator.Evaluate
but this is in unityeditor class and when i build my project i reach an error that is say
"The name "ExpressionEvaluator" does not exist in the current context."
i handle this error with using Platform Dependent Compilation https://docs.unity3d.com/Manual/PlatformDependentCompilation.html but when i try to install apk i reach an error on android device and device say the application is not install.
now my question is that,is there any alternative for ExpressionEvaluator.Evaluate or any suggestion that you can helm me with.
thank you so much.
I doubt the installation failure has anything to do with conditional compilation. I can't say much about that, but regarding ExpressionEvaluator, there is a lot of code in UnityEngine. If you were to bundle all that code with your game, you'd get a multi-hundred megabyte apk on your hands; not to mention that most of the code is probably native and they don't/can't build it for all target platforms, only editor platforms (Windows, MacOS).
You really shouldn't use UnityEditor code in your game logic, not even in the editor. If you use UnityEditor it should only be in editor code. If something's in UnityEditor and you need to support it at runtime, you should find a library that does the same, or write it yourself. You can search for one online or on SO. Here's the first result from a Google search:
I need a fast runtime expression parser
I've just read this paper which presents the BSDiff tool as a method to diff-and-patch binary files. I wonder whether these types of tools are good and suitable in systems which can't afford any kind of error in this process.
I'm working in an embedded project and we are looking for ways to update the bootloader image without transferring the whole new version, but only small pieces. The binary image that we want to update, encompasses not only the application we've developed but also the OS (FreeRTOS) and third party libraries.
Try this implementation of BSDiff:
https://github.com/Cheedoong/bsdiff
Cross-platform, and with no dependency on other library.
My phone’s Android has under /system/lib/hw the following files among others:
sensors.exynos4.so
sensors.smdk4210.so
Those dynamic libraries are somewhere in the chain for sensors like compass, gyroscope and ambient light.
The first file (sensors.exynos4.so) comes from the the distribution itself (running CyanogenMod 10.1 for i9100), the second (sensors.smdk4210.so) is what I fished out of the stock ROM for my phone (SHW-M250S, “Korean S2”, a variant of the i9100) and copied it there.
Question1: What is using those files?
Doing an ldd (actually a readelf or objdump) over all binaries and libraries in the system did not reveal any users of those files. My conclusion: someone has to load them like plugins during runtime after dynamic linking! But who/what? (source code file name or link to a code browser, please)
The users of those libraries switched from the first to the second without any configuration (after I placed it there). I would like to dig into this mystery.
Question2: Where is the source of those files?
The files contain (at least) the configuration of the sensors (like it’s positioning on the board, value ranges and steps). I want to generate a correct one for my phone. If I have the source of both, it would be easy to do so. – With only the CyanogenMod version, I can at least guess the necessary corrections.
Notes:
No guesswork answers.
If part of your answer is “binary”:
point me to the blobs in the CyanogenMod source or the script that pulls them.
follow the chain to the first open source library/program which uses them.
The questions are not really device specific. – Answer with any device in mind, the situation should be similar (AOSP, AOKP, CyanogenMod, ...).
They are binary blobs.
Has the sensors.exynos4.so and other proprietary blobs
https://github.com/chris41g/proprietary_samsung_epic4gtouch/tree/master/proprietary/lib/hw
The blobs can be pulled from a running device with the extract-files script which reads a list of the proprietary files from proprietary-files.txt in the project for whatever device you are building CM for.
Try googling the files maybe or looking through the CM tree or their wiki.
The HAL is the Hardware Abstraction Layer is the interface that is used to get sensor data from the kernel/device drivers back to userspace.
Found this pdf which discussed building the Android HAL but for a different device and the output described there is
After having successfully downloaded and compiled the Android sources, the user can compile and add/substitute the sensor HAL library.To do this, copy the sensor HAL library folder in the android sources path, usually located in:
[Root Android Sources]/vendor/[vendor name]/[boardname]/
Before the build operation of the library, the user must initialize the Android environment:
[Root Android Sources]$ source build/envsetup.sh
[Root Android Sources]$ lunch [target board]
It is now possible to build the library; just launch the “mm” command in the HAL folder. The result of this process is a dynamic library located in:
[Root Android Sources]/out/target/product/[board name]/system/lib/hw/sensors.[board name].so
In the case of the sensors, the SensorService loads the HAL so it can talk to the sensors.
HAL
Building HAL
Update:
Did some more digging around my CM tree
device/samsung/i9100 contains an Android.mk file that builds sensors.exynos4.so.
The .mk file specifieds the module as
LOCAL_MODULE := sensors.$(TARGET_BOARD_PLATFORM) which is set in
device/samsung/galaxys2-common/BoardCommonConfig.mk.
There is source in device/samsung/i9100/libsensors for this device. Looking at device/samsung/i9100g however there is no libsensors and that device requires running the CM scripts to pull the blob from a running device so the availability of source still varies based on device.
Also just an observation that the BoardConfig sets some values to smdk4210.
I can’t answer yet what uses those files, but the source for sensors.*.so is nice to navigate to in CyanogenMod:
Each supported device has a wiki entry which points to the github repo (e.g. i9100 source). There you find additional repositories in cm.dependencies which together cover what you need to build CM for the device in question (e.g. the kernel, common files shared among a group of devices, ...).
In case of the i9100, we can stay in the root repository. In libsensors/Android.mk we see that sensors.<ro.product.board>.so is produced by the files in this directory. The source is all there (for the i9100 device), except libakm.so (binary, according to ../proprietary-files.txt), which is dlopen()ed in AkmSensors.cpp. libakm.so is used for enabling and disabling some sensors, but also creates /dev/input/eventX, a virtual input device reflecting three of the sensors available (compass, acceleration, orientation). (I don’t know how the kernel “runs” virtual devices.)
(sensors.*.so is the Hardware Abstraction Layer. – For the i9100 it handles some /dev/input/event* devices. I didn’t check the kernel for details of those...)
I'm trying to write an SSH client for the iPhone, and I'd like to use the libssh2 open source library to do so. It's written in C.
How should I include this C library for my iPhone app? Should I compile it into some binary that I include into the my app, or do I add all the source to my project and try to compile it along with the rest of my app?
I'm interpretting this question as:
"Should I compile the C library code once, and include the binary library in my project? Or should I include all the source and compile it every time I build my app?"
It depends. One of the projects I work one depends on several external libraries. Basically, we have a simple rule:
Do you think you will need to change code in the C library often?
If you will be changing the code, or updating versions often, include the source and build it with the rest of your project.
If you're not going to change the code often or at all, it might make sense to just include the pre-built binary in your project.
Depending on the size of the library, you may want to set it up as a distinct target in your project, or for even more flexibility, as a sub-project of your main project.
If I was in your place, I would build libssh2 ahead of time and just include the binary library in my iPhone project. I would still keep the libssh2 source around, of course, in case it does need to be re-built down the road.
I have an iPhone app that is 90% c. I have had no problem adding 3rd party sources to my project and compiling. I am using Lua, zLib, and libpng with no modifications. I've also included standard libraries like unistd and libgen and they just work™
The Three20 iPhone library has a great howto on adding their library to your xcode project. Give that a shot.
I think you will find in the long run you will be better off building it into a standalone library and linking it with your application. This makes it easier to integrate into future apps. Another benefit is that it encourages code separation. If you feel pretty confident with the library, you can link your debug exe to the release build of the library and get some extra performance.
I can't really think of any downsides to creating a library, after the initial cost of setting it up, and having an extra project to modify if you have some changes that need to be made to all your projects. Even if you don't know how to make a library for the iPhone, this is a good excuse to learn.
Just adding the source to you project should work fine as well.