Dear All,

I'm working with openembedded for sam9263, I can build the image and then I'm adding some application to the system, I'm create the recipes and putting the source file as described in the manual and everything seems ok.
The problem is that during the dubug cycle, change the souce code, building the image, download to the target for debugging ...a lot of time is spend on build process by bitbake ...maybe my pc is slow but really it takes a lot of time.
I have tried also to compile the single receipes with my application: $ bibake -b recipes/testgpio/testgpio_1.0.bb ...it takes time too.

I'm wondering if there is a best practice for speedup development cycle (change-compile-build image)

thanks

If you are simply doing user space applications, wouldn't it be simpler to put the GNU/GCC tool chain, make, pico/whatever on the target and edit/compile/run there from the terminal?

If you like windows, you could use a samba share.

thanks,
I'm not only developing application on user space, but also some drivers.
Putting the native arm toolchain on the target can be a solution, but maybe there is something else to speed up the development.
Only to compile one recipe with my application (1k c code), my pc takes 1 hour...
I have read somewhere that for developing (once you have selected the target) is more useful using a SDK generated by openembedded....

thanks,
I'm not only developing application on user space, but also some drivers.
Putting the native arm toolchain on the target can be a solution, but maybe there is something else to speed up the development.
Only to compile one recipe with my application (1k c code), my pc takes 1 hour...
I have read somewhere that for developing (once you have selected the target) is more useful using a SDK generated by openembedded....

issue close, I have identified a pretty good way to go ahead
Thanks

can you share your method with us?
Why was it taking so long for a small amount of code?
I usually just use

bitbake small_recipie.bb -f -c clean
bitbake angstrom_image_recipe.bb

OAC

He was making the entire kernel from scratch each time, as best I can observe.

Another classical method of debugging drivers is to use loadable modules along with insmod, modprobe, and rmmod. Along with building and testing foundation code outside of Linux so that when you integrate it, it has a good chance of working/mostly-working first time around.

Then again the Linux guys I've worked with actually "own" the make process, and were comfortable patching, editing, debugging and integrating changes, rather than just script kiddies.

Agreed. Whatever works best for you.
I tend to do my boot loaders and the kernel +modules manually but let OE handle the file system and initramfs if applicable.

Once I get to a stable patched kernel etc, i just move my patch set into OE and let it complete the full system.

OAC

Hello,

You have a lot of ways in order to not compile all your rootfs and your kernel :

- As said, using modules instead of built-in when you are debugging a driver
- Use nfs (you can only compile one package with bitbake and then add the new binaries to your rootfs)
- Use ssh to get your binaries
- Use opkg tool: copy the package file generated by OE to your target, or better, setup opkg to use your host machine as a package server