Has anyone successfully done a Cooja simulation with a Thingsquare Mist application?
I try to compile the hello-world or the mesh-node examples for the various Mote types but most of them failed on missing ip64-conf.h (naturally, since the target is not supported on Mist) but those that has some sort of Mist port (exp2420 for example) failed because the application can't fit in ROM.
I tried manipulating the line on the Compile commands tab to make it build for any other platform but even though the build is ok the Create button never gets enabled.
I'm using the Instant Contiki 2.6 environment and building code from Thingsquare Mist 1.0.1
Though Thingsquare mist code is based on Contiki 2.6 you can't compile thingsquare code inside instant Contiki (cooja) as it is. The current configuration for make file in mist only supports cc1101, cc2420, cc2538 and two or three platform. Please have a look at thingsquare website for details. Things to do.
You need to change the simulation settings for the specific platform. Do n't waste your time in cooja for running mist apps; it 'll not compile. Have a look to this link: https://github.com/contiki-os/contiki/wiki/An-Introduction-to-Cooja#wiki-Create_a_Hello_World_simulation
For minimizing the missing ip64-conf.h. Just create a ip64-conf.h file inside mesh-node folder and paste the following code.
#ifndef IP64_CONF_H
#define IP64_CONF_H
#include "ip64-slip-interface.h"
#include "ip64-null-driver.h"
#define IP64_CONF_UIP_FALLBACK_INTERFACE_SLIP 1
#define IP64_CONF_UIP_FALLBACK_INTERFACE ip64_slip_interface
#define IP64_CONF_INPUT ip64_slip_interface_input
#define IP64_CONF_ETH_DRIVER ip64_null_driver
#endif /* IP64_CONF_H */
3.To minimize ROM Overflow error; you need to install msp430-gcc compile 4.7.0. Have a look to this link: http://wiki.contiki-os.org/doku.php?id=msp430x
Related
It has been a while since I have used XCode, but since Apple revieled XCode 6 and the new Metal API I had to check it out.
They have released examples, e.g. a converted version of their Basic3D example. I am having problems making them compile and run, though. I had to add paths the Quatz and Metal frameworks for compilation and linking to work - thought that should have worked out of the box with build-in libraries?
Also the metal shader compilation step fails, it can not find the metal compiler. Where in XCode is that path setup?
If I ignore the shader compilation step I get an error that the application will not run on any of the simulators. Can metal based 3D applications only run on actual hardware and not in simulator mode?
According to a staff on Apple dev forums, Metal does not run in the simulator.
See: https://devforums.apple.com/message/971605#971605
If you look at other samples/app templates there is no need to explicitly link any framework, indeed everything runs out of the box.
You can't run metal on simulator but you can use this workaround so that it will still compile as long as you have a fallback for the code.
http://medium.com/#jscampbell/bare-metal-working-with-metal-and-the-simulator-70e085e3a45
I started with the hello triangle example they give you to download. It contains all the platform #if's you need to know about. I recommend you get that project and take a look.
https://developer.apple.com/documentation/metal/hello_triangle
#if TARGET_OS_SIMULATOR
#error No simulator support for Metal API. Must build for a device
#endif
I have followed the tutorial here: http://www.hitl.washington.edu/artoolkit/documentation/devstartup.htm
When I try to compile the program, it will compile but the output window will tell me:
DSVLd.dll(tid 774c) 42818982 : Could not access module key
DSVLd.dll(tid 774c) 42818982 : Could not access GLOBAL module key
And then the program will quit.
I have been able to setup the toolkit according to the instructions and was able to run the sample programs just fine. I am not sure whether or not there is some setup steps I missed or need to configure if I am creating this project from scratch.
I am currently running 64-bit Windows 7.
Any help would be much appreciated!
I have a similar debug output when my program is running a linked library using MS directshow (debug version). It seems the debug system is looking for Windows registry keys. But it should not be the reason for a program quitting, at least mine works unaffected.
I solved it just now. Just copy the two files (data and Wrl) from ARToolKit\bin\data and ARToolKit\bin\Wrl to the directory debug under you own project folder, not just copy to your project folder.
I downloaded this project to give it a try (http://www.hatzlaha.co.il/150842/Lucas-Kanade-Detection-for-the-iPhone). It also has a released version on AppStore.
When I downloaded the source and compiled, it gave compilation errors. I changed the compiler to LLVM GCC and it instantly compiled without any errors or warnings.
Further here is what I did:
Downloaded the app Lucas Kanade on personal iPhone. Runs as expected (ie. shows tracked points and video output).
Deployed the above compiled app on company iPad. Here is shows the tracked points (which means the application is getting the video frames) but not able to display the video output.
General app flow:
Grab a frame from the camera.
Process the frame (track points).
Output the frame, so the screen looks like its showing the camera feed, as expected.
Device details:
iPhone: OS 5.1.1 (9B206); iPhone 4;
iPad: OS 5.1 (9B176); iPad 2;
Questions
Is the video output problem occurring because of the different in OS versions or because of the GCC compiler being used?
If it is the compiler problem, would be be appropriate to put the compile errors here for resolution or do I need to start a separate Question?
I know this info might not be enough since there are a lot of unknowns, but trust me, getting into the details of the app would be a really exhaustive problem description. Let me know what more info is needed to guess the solution. I'll update it here.
Like you already said the info is not enough. I can just guess. The projects for tracking points uses generally their own driver for camera access. The reason, why it does not work with llvm compiler, might be that.
Just look in the project if you find any file specific to iPhone. They are mostly dat files. And maybe you find some preprocessor macros in the project like #ifdef target_iphone something like that. In that case you can contact the producer and request the driver for iPad.
I did not download and tried the project, but it is just a guess.
I have a code base which compiles fine in all other NEON compilers, ndk-build, RVDS, etc, but under Xcode I get the error "bad instruction" for every NEON instruction I call. It basically seems like NEON is not detected.
I am attempting to build a static library, I went to New Project, selected Cocoa Touch Static Library, then added my existing files.
Everything I'm reading indicates that NEON should be already enabled. I removed all references to armv6, and am targeting iOS 5.1
Also the code in question is all contained as routines defined in ".s" files -- pure assembly. I am not using the intrinsics method calls.
It seems like the compiler is barfing on the whole file...
Unknown pseudo-op: .cpu
It lists all of the other settings, like .fpu, etc
Here are my current settings:
(source: wasteonline.net)
(source: wasteonline.net)
(source: wasteonline.net)
After the as tool I mentioned in my last answer turned out to be choking on my syntax as well, I realized there must be something else going on.
I followed the guidelines on the bottom of this post http://www.shervinemami.info/armAssembly.html#template
The changes I needed to make were:
converted my instructions to all lower case
use the naming directives to be compatible with mach-o (solved linker problems)
Try to use GCC4.2. I solved a very similar problem switching to the old, good GCC.
In Build Settings -> Compiler for C/C++/Objective-C, select GCC
Actually, if you check the LLVM ARM status page, you'll see that it cannot yet parse .S files.
I have built an iPhone app with SDK 4.2 however I know also want to make it compatible with iOS 3.1.3.
First step was to set the Deployment Target to 3.1.3. It runs fine on the 3.2 Simulator but the app crashes at times since I'm using some methods which are not available in this early SDK.
So my qestion is, is there a straight forward way to locate the offending methods/classes I'm using in my project which are not available in 3.1.3 ? (without manually going through each method call and consult with the docs for the SDK availability?)
Thanks.
UPDATE: I have executed the app on 3.1.3 and attempted to manually test each execution path with the hope of locating all exceptions. This was completed with some level of success. However, what if the application is huge? and there are lots of execution paths? There must be some tool for this scenario. Any thoughts are much appreciated.
I had the same problem and just found a solution.
You should add the following definitions at the beginning of your prefix header:
#import <Availability.h>
#define __AVAILABILITY_INTERNAL__IPHONE_3_2 __AVAILABILITY_INTERNAL_DEPRECATED
#define __AVAILABILITY_INTERNAL__IPHONE_4_0 __AVAILABILITY_INTERNAL_DEPRECATED
#define __AVAILABILITY_INTERNAL__IPHONE_4_1 __AVAILABILITY_INTERNAL_DEPRECATED
#define __AVAILABILITY_INTERNAL__IPHONE_4_2 __AVAILABILITY_INTERNAL_DEPRECATED
#define __AVAILABILITY_INTERNAL__IPHONE_4_3 __AVAILABILITY_INTERNAL_DEPRECATED
Then the next time you compile the app, the methods that are not available in old versions (in this case iOS 3.1) will be marked as deprecated and you will get warnings for each of them.
You can use __AVAILABILITY_INTERNAL_UNAVAILABLE instead of __AVAILABILITY_INTERNAL_DEPRECATED if you want to get errors.
These lines redefine the actual definitions in AvailabilityInternal.h so you should remove them from your prefix header when your are done.
Here is how it works:
Apple marks the availability of the methods in the header files with macros like __OSX_AVAILABLE_STARTING(__MAC_NA,__IPHONE_4_0).
Since you are compiling for iOS the following definition in Availibility.h is applied:
#define __OSX_AVAILABLE_STARTING(_mac, _iphone) __AVAILABILITY_INTERNAL##_iphone
So the methods are actually marked with __AVAILABILITY_INTERNAL__IPHONE_4_0 and similar macros. Normally when you are compiling with the new SDK these macros are replaced with __AVAILABILITY_INTERNAL_WEAK_IMPORT, which does not produce any warning. By adding the lines at the beginning of my answer to your prefix header, you overwrite these definitions with __AVAILABILITY_INTERNAL_DEPRECATED. Therefore Xcode thinks these methods are deprecated and produces the warnings.