Hi Guys,
Any updates on how its going with the GCC port of the toolchain that was referenced in other threads a few months ago?
Thanks,
–Ed
Hi Guys,
Any updates on how its going with the GCC port of the toolchain that was referenced in other threads a few months ago?
Thanks,
–Ed
Hi Ed,
A version of the Pixy firmware compiled with the gcc port can be found in the repo “here”:https://github.com/charmedlabs/pixy/tree/master/device/gcc. In short, we’re able to compile and deploy the firmware with the port, but it still crashes due to a few bugs. Overall I’d say it is going really well and hopefully it won’t be too long until we get to share it with all of you!
Scott
Hi guys. I noticed that the repo has moved from the link here; where should we get the latest, greatest attempt?
There are definitely use out here who appreciate you going through the extra work of porting the firmware. I really look forward to it.
Hi,
The gcc-compiled files are now “here”:https://github.com/charmedlabs/pixy/tree/master/src/device/gcc. Even if the link changes, the gcc files will be in there somewhere. Enjoy!
Scott
Hi,
I’m trying to build the firmware with gcc. Any instructions? I found the makefiles in the release directories but they refer to …/makefile.init and …/makefile.defs which I couldn’t find in the repo. Have you been able to build from the repo? I also noticed a lot of eclipse files - before I go and install eclipse, wanted to know if this is needed.
Thanks,
Shari
Scott Robinson wrote:
The gcc-compiled files are now “here”:https://github.com/charmedlabs/pixy/tree/master/src/device/gcc. Even if the link changes, the gcc files will be in there somewhere. Enjoy!
Thanks for the link. Out of curiosity, which parts are working? If the code was stripped down to just reading from the camera, doing a bit of processing, and spitting out some serial, do you think it would work?
We brought in an outside contractor who previously worked at NXP to do the heavy lifting with this. We’ve solved a long list of the harder problems with memory alignment, inline assembly, linker scripts, dual core issues, debug environment and flash memory — it’s a bigger chunk of work than expected mostly because GCC and ARM Realview have lots of incompatibilities.
We have video streaming over USB, but the code as it stands is pre-release. Someone who’s familiar with LPCXpresso can probably get it working, but we don’t have the resources to support it at that stage. A real release is expected in December. It’s stuck behind another large release that improves the color tracking algorithm.
I want to get more familiar with the UART routines. Sadly, i don’t have a Keil IDE running. For STM32 programming, i use gcc on OSX. I simply want to ask how far the development status with free software is.
Thanks
Joerg
We’re still where we were a month ago— expecting the first official release for GCC support in December.
That you for the update. I too am very interested in the GCC support and hope with all that is going on you are able to keep the goal of December.
Thank you for your efforts to have a far more accessible firmware dev environment than Keil IDE. Thanks All.
Just putting in a vote for support of GCC firmware make support and hope this can come about.
Thanks Everyone,
mark johnston
Yes, I’m also excited about it! Is the plan still this month?
The firmware SDK is delayed and won’t be released this month
It’s caught behind a big firmware/PixyMon release expected around Christmas. (The July customer survey told us that improving the robustness, decreasing false positives, etc was most important.) We’re pretty excited – the new firmware has taken forever to develop — 4 months! — but it’s a big step forward in performance… and it has pushed everything back…
But after it’s released we’ll focus on the firmware SDK and we expect a beta in January.
Sorry… we’ll get there
Any chance for a version that compiles, even if it doesn’t have all the features? I thought it was that far along at some point, but the current version on github doesn’t compile.
dude!
so… afaik everything compiles.
Please be more specific…
If it’s the code here https://github.com/charmedlabs/pixy/tree/master/src/device/gcc
it’s under development. We hesitate to make any claims… please be patient… thank you.
Oh, maybe I’m missing things? ‘pixy_m4’, ‘pixy_m0’, and ‘m0’ all compile, but ‘video’ gives the errors:
cannot find -lfalcon_m4_spifi_drv
make: *** [video.axf] Error 1
I can’t find anything about “falcon_m4_spifi_drv” so I wasn’t sure how to progress. I’m using LPCXpresso. Any help would be greatly appreciated.
If the effort has been mostly towards making detection more reliable I am all for that as a priority over gcc toolchain.
My focus is use of 3-color bands being recognized over as broad of a difference in brightness as you can possibly handle. I was going to myself vary your ‘brightness’ and sample at 3 levels basically to get as many tries to find object as possible. Pixy today is so very highly sensitive to precise environmental (lighting) that I have almost given up on it so I applaud efforts to better it’s detection. Would be great if Pixy could sort of rotate between a few brightness settings internally to better it’s detection (this slows effective frame rate but would be highly desirable from my point of view and I am certain MANY customers of Pixy would benefit). Sorry to digress on this thread.
Thanks and of course I still await GCC toolchain in the state you are working towards. Nice to hear it can make now, nice progress. Thanks.
Yeah, we need to modify gitignore — here is the missing file.
Hi Rich. Thanks a bunch for the file. Can you tell me where it’s supposed to go, or if I’m missing something else? I’m getting new errors:
Description Resource Path Location Type
final link failed: Bad value video C/C++ Problem
make: *** [video.axf] Error 1 video C/C++ Problem
undefined reference to __aeabi_memcpy4' video line 0 C/C++ Problem undefined reference to
__aeabi_memcpy4’ video line 0 C/C++ Problem
undefined reference to __core_m0app_START__' pixy_init.cpp /pixy_m4/src line 211 C/C++ Problem video.axf: hidden symbol
__aeabi_memcpy4’ isn’t defined video C/C++ Problem