I have created a GRC flowchart that includes a custom OOT module. The flowchart has been compiled, and the resulting .py file copied to my USRP device.
When I try to run this file on the USRP, I get an error: no module named "my_custom_blocks"
Which makes complete sense!
My Question: How do I integrate my custom OOT module onto the USRP device, so that my file will run correctly? Do I need to use gr_modtool on my USRP device (and then copy my code in?) is there an easier way?
Thank you for your help
You need to install that module on your E-series USRP (the fact that you can execute code on your USRP says it's E-Series).
That means either:
If your OOT module is Python-only, the you could copy over your gr-my_custom_blocks, thenmkdir build; cd build; cmake -DCMAKE_INSTALL_PREFIX=/usr ..; make; sudo make install.
In general, the cleaner (even for Python-only modules) and the only way sensible if you have C++ code in your module is
Set up a cross-compilation toolchain on your PC,
Cross-compile your module and
install it to the correct directory structure, finally
copying over the thus generated filesystem tree to your device
The Ettus Knowledge Base Application Notes AN-311 and AN-315 (your module is just like gr-ettus) will help.
Related
I have one ESP-IDF application and two hardware boards. I use a preprocessor definition to control which hardware board version to build. For now, I'm modifying the config in the sdkconfig file via menuconfig. But I would like to build both versions at once from a script, or build only one specific config without the manual process of menuconfig.
I have a header that looks like this, and works when HW_VER is set correctly:
#if HW_VER == 2
#define BTN_GPIO 9
#elif HW_VER == 3
#define BTN_GPIO 10
#endif
And from the a script I would like to build each by selecting a value for HW_VER, for example:
idf.py build -DHW_VER=2
idf.py build -DHW_VER=3
The idf.py build command runs cmake and ninja. I'm new to cmake, so perhaps there is a natural way to do this?
I would also like to build release and debug builds, turn on/off memory debugging etc. from the command line.
I've tried idf.py build -DHW_VER=2 but I've learned that these vars are only sent to cmake and not to the preprocessor. The HW_VER macro remains undefined.
Using add_definitions() in my CMakeLists.txt can set HW_VER, but doesn't help me make different builds from the same files.
Using a config variable like CONFIG_HW_VER in the sdkconfig works to control builds using menuconfig but I don't see a way to automate this.
I've considered modifying the configuration variable, CONFIG_HW_VER in the sdkconfig file programmatically, but this file is under source control, and it is auto generated by menuconfig, so that doesn't seem wise.
Similarly I can modify the CMakeLists.txt file programmatically, but that file is also under source control, and isn't a trivial format.
I use two ways to feed custom configurations into an ESP IDF project.
Firstly, the light weight stuff like preprocessor definitions from the environment are quite simple. You have to configure CMakeLists.txt file (the one in project root) to pass variable values from environment into the build process. For example, to create something equivalent to preprocessor definitions -DMY_NUMBER=123 and -DMY_STRING="abc" add this somewhere before the "project" line:
add_compile_definitions(MY_NUMBER=$ENV{MY_NUMBER})
add_compile_definitions(MY_STRING=\"$ENV{MY_STRING}\")
...
project(myproject)
Assuming you're working in Bash, build with:
$ MY_NUMBER=123 MY_STRING="abc" idf.py build
or (for a slightly more "sticky" enviroment):
$ export MY_NUMBER=123 MY_STRING="abc"
$ idf.py build
You can use cmake to add more advanced logic, e.g. setting default values in case the environment doesn't set anything.
Secondly, the more powerful configuration tool for ESP IDF is the menuconfig target and sdkconfig file. As you've already noticed, playing with sdkconfig directly is not so easy. In my projects I consider this a generated temporary file and I never commit it to git. Instead I delete it. When sdkconfig is missing, idf.py will take file sdkconfig.defaults, copy it into sdkconfig and work with this. That is your best mechanism for supporting different hardware configurations - no sdkconfig and instead different variants of sdkconfig.defaults for each hardware you wish to support.
As an example, assume you have two different HW versions described in sdkconfig.defaults.hw_ver1 and sdkconfig.defaults.hw_ver2 and you wish to build for HW ver2 configuration:
$ rm sdkconfig && cp sdkconfig.defaults.hw_ver2 sdkconfig.defaults
$ idf.py reconfigure
Now you can build for this configuration like you usually would:
$ idf.py build
When you wish to build for the other FW configuration, re-execute the previous commands with sdkconfig.defaults.hw_ver1
All this is rather thoroughly documented in the Build System documentation, so feel free to dig in.
I'm using buildroot to create a linux system for raspberry pi. I want to use the initramfs to enable to system to self-patch. The procedure roughly runs as follows:
Raspi boots, kernel loads initramfs
The initramfs-system (which contains busybox, zsync etc.) connects to a central server and checks if there are boot-file updates available (e.g. a new kernel)
If not, it checks if there is a system update available and downloads that if needed
The downloaded (squashfs) system image is mounted and executed via switch_root
My problem is that I need to compile a secondary busybox (and some more packages) for the initramfs which do not belong in the main system. I currently solved this by manually tinkering with the package files to install into target/initramfs, moving this folder out with pre-build and back in again with post-build, but this seems rather hacky. Additionally, different package types require different types of changes. Is there a better solution to this problem? If one could for example manually overwrite the target directory for each package, this problem would be rather easy to solve.
Create two separate buildroot configurations.
One configuration will have the kernel and the initramfs.
The other configuration only has the squashfs rootfs.
Creating a partial rootfs from a configuration is very tricky, because you have to be sure that you don't miss any shared libraries or other auxiliary files needed by some program.
Note that to speed up the build, you can use ccache and/or use an external toolchain. See the manual.
Recently I just used fsl-community-bsp and meta-qt5 layer to generate the cross toolchain and the rootfs. I used "bitbake meta-toolchain-qt5" and "bitbake fsl-image-multimedia-full". Both fsl-community-bsp and meta-qt5 use jethro branch.
Following are some of my questions:
In the rootfs which I put in the “riotboard”, is qt5 library already in it? Do I need to compile the source of qt5 and copy it to the board
separately?---Now it's clear, the library are inside the rootfs;
I have set up the qtcreator: device, kit, qt version, compiler, debugger, also ssh connection, but when I run the application, qt says
“This application failed to start because it could not find or load the qt platform plugin xcb, available platform plugin are: eglfs, minimal, minimalegl, offscreen”.---It seems the error is fixed by me, modifying the PACKAGECONFIG[gles2]="-opengl es2 -eglfs -qpa eglfs,,virtual/libgles2 virtual/egl";
In the Jethro branch of meta-qt5, the qtbase.inc is missing, correct? I found on the internet, that I can modify the PACKAGECONFIG[gles] value, add –qpa eglfs.---It's into the qtbase_git.bb now;
I also found that in the Jethro branch, the serialport is also missing, but in our application, we need this function to handle the serial keyboard. How can we do now?---I find it now;
If I need to compile the qt5 source and copy all the folder to the riotboard, how can I set the path in the qtcreator to find the relevant library?---No need to do this;
Thank you very much!
To enable EGLFS, in local.conf add: DISTRO_FEATURES_remove = "X11 wayland"
1.You do not need to copy the qt5 library, you could follow this wandboard qt5 implementation here
In your machine, you need to enable Qt to run eglfs platform, in /etc/profile, add export QT_QPA_PLATFORM=eglfs or when you run an application; you need to add -platform eglfs. ie. helloworld -platform eglfs
There is no qtbase.inc; You could add PACKAGECONFIG_append_pn-qtbase = " eglfs xx xxx xxxx" to enable the configuration you need
There is qtserialport_git.bb in Jethro
As said, you do not copy the libraries and sources but instead tell Bitbake to do that for you. They will be moved to the corresponding places.
The WebRTC library getting started guide explains how to compile the library.
The sample programs in ./trunk/talk/examples/peerconnection are not built, however, and there are no make files in those directories to do this.
Can someone explain how to compile this, and perhaps the other Talk example programs on Linux?
I've been able to build them using the ninja build tool. I don't know if building using make is supported as well.
When you've checked out the code, you should have subdirectories trunk/out/Debug and trunk/out/Release. In them, there should be build.ninja files. Just go to one of those directories and type ninja to start the build. The peerconnection executables will be peerconnection_client and peerconnection_server in the Debug or Release directory.
In case the ninja build files need to be regenerated, you can execute gyp_webrtc from the trunk/webrtc/build subirectory
I am working on a project that is using Leopardboard DM368 interfacing with LI-M024DUAL camera board for stereo vision. The camera uses Aptina's MT09M024 as its image sensor.
After spending a lot of time on the web searching for appropriate drivers I asked the OEM to provide me some support. They provided me with the driver source files. The problem is I am not able to include them to the kernel.
I also looked up for the method to build modules and am fairly comfortable with it. But with the current driver I have a bunch of *.c files that use non-existent header files (I am not able to find these linux header files in the /linux directory).
Now my question is if I have the source code for an image sensor driver and want to build it, what is the general procedure followed for the same.
Any help in this regard would be welcome.
-Kartik
There are two ways to build you module:
1. Statically linking to kernel image (inbuilt)
2. Creating dynamically loadable Modules
Statically linking to kernel image (inbuilt)
For this you must find a appropriate place in kernel folder (somewhere in drivers/) to copy your .c files. copy them there. Edit Kconfig and Makefiles refering to other kernel drivers. and enable the support using menuconfig. Compile.
Creating dynamically loadable Modules
You can built without copying them to Kernel source. Just create a Makefile and place rules in Makefile to compile your module. Here you must link your module to your kernel by providing the kernel source path.
For more google should help.