I know that TinyOS itself is written in nesC and the application written in nesC gets executed in TinyOS. Can we develop C language application to run on TinyOS?
The short is answer is NO. You generally can't write a application in C that "runs" on TinyOS.
TinyOS uses nesC so you can't directly use a full, already existing C application with TinyOS. Remember that the NesC compiler takes a TinyOS application written in nesC as input and then compiles it and outputs an C application. That C application is then fed to the microcontroller's compiler which compiles it and uploads it to the microcontroller. So if you already have a complete C application then the question is why do you need to compile it with TinyOS's nesC compiler.
A common task that people want to accomplish is to include pure C code (either from some library or self written) in a TinyOS application. This can be accomplished by including normal C header files and then calling the C functions as you normally would do in C. The actual C code can then be located in the header file itself (for instance the CRC.h file in the TinyOS distribution has C code in it's header) or can be in some other C file. Similar to how you would do it in C.
Related
I've been successfully using Vivado and the SDK to develop VHDL and C for the Zynq XC7Z010 on a Digilent Zybo board. I've also been using the GNAT GPS IDE to learn Ada targeted to an STM32F4 processor (using one of the supported development boards).
GPS also ships with a set of zynq7000 run-times targeted to the XC7Z020 (as far as I can tell). Having looked through the BSPs for these target I believe that the code generated should also run on the XC7Z010 as the ARM cores appear to be the same. It may turn out that there are differences, in which case I will have a go at building a specific run-time based on the existing zynq7000 BSP (Adacore have documented this process and give an example for generating a new STM32F4 BSP).
My main problem is I'm not sure how to load and run the generated Ada elf file on my Zybo. I have tried to generate a BOOT.ini file containing a FSBL (built with the SDK and using my exported hardware from Vivado), a bit-stream and the Ada elf file (The the Zybo has an MicroSD interface that can be configured as a boot device, this works perfectly with a bit-stream and C elf produced via Vivado / SDK).
Anyway, this didn't work... I'm guessing that it might be a linking issue, or a boot loader issue, or similar. With my current level of knowledge I'm just not sure at this stage.
Any advice or pointers would be greatly appreciated!
It turns out that my BOOT.ini was fine, the problem was related to accessing custom AXI registers defined in my bit-stream. If I remove these references from the Ada the generated ELF file works perfectly. For example, printing over the Zybo's VCP using Text_IO.Put_Line(), using Ada run-time delay and Clock operations etc.
For some reason the AXI interface isn't working when I boot an Ada ELF file. If I substitute this for the equivalent C, then all is well.
This particular problem is currently unresolved, but not related to my original question!
(It might be that the Ada run-time is relying on the FSBL or u-Boot to have initialised this, not sure. Feel free to comment if you know, I'll also add a comment when I resolve this)
**** Update ****
Here is some additional background and a description of what I had to do to get my custom AXI IPs to work.
The provided AdaCore BSP (Board Support Package used to build the run-time) is targeted at the Xilinx XC702 development board. I'm using a Digilent Zybo (the older version). The two boards use different Zynq parts, the XC702 is based on a XC7Z020 and the Zybo uses a XC7Z010 (there is a new version with a XC7Z020 option).
I followed the AdaCore instructions (available on their web site) and built a BSP specifically for the Zybo. Initially I just updated the clock details as the Zybo runs at a different speed and then verified that the Ada delay function worked correctly (provided as part of the Ravenscar run-time built from the updated BSP). However, my custom AXI IPs still didn't work...
To cut a long story short, the Ada run-time contains as assembly file called start-ram.S that amongst other things sets up the MMU. There is an include file called memmap.inc that contains the actual MMU page definitions as a series of .long directives. I had to update the AXI_GP0 address entry by editing the particular directive to,
.long 0x43c10c16 # for 0x43c00000, axi_gp0
Previously it was set to 0x00000000 # for 0x43c00000, *none*. These entries are decoded within start-ram.S and then used to configure the MMU (the top 12 bits set the page and the remaining bits are chopped up and used as page config).
So, once I edited this file in my Zybo BSP and re-built the run-time, the IPs became accessible from the PS and worked as expected. This all took a while to figure out, but was worth it as I learn loads whilst exploring the dead ends!
I hope this helps someone in the future, I also highly recommend Ada for Zynq development especially if you ultimately need DO-178 certification, or similar.
The project ask to call 3 separate files in this project for the bankers algorithm one is called a driver
include "banker.c"
include "process.c"
I've developed a program and I am trying to make this program work with a controllable light source manufactured by some other company. I've emailed the company and they have agreed to send me their external library as a DLL.
I have developed all of my software using Qt 4.8.1 and it has been compiled using MSVC2008.
The controllable light's DLL was compiled in Visual Studio 2008 and was written in either C++ or C# (the manufacturer is uncertain). All I have been given is the DLL and a text file saying that I must:
Add the DLL as a reference to my project
Add using LightName; to the top of the class
Instantiate an instance of the object like so: LightName *ln = new LightName();
Call function void turnOn() with the newly created LightName instance.
Firstly, I find it odd that an external library requires me to instantiate an instance of their object especially when its for a simple piece of hardware.
Secondly, the other company has provided me with no interface files.
My question is:
How can I possibly link to a C++ DLL and expose the functions nested in this library without having an interface header file in a Qt environment? Is there someway to make an interface for an external library?
I have already attempted using QLibrary and doing the following:
QLibrary myLib("mylib");
typedef void (*MyPrototype)();
MyPrototype myFunction = (MyPrototype) myLib.resolve("mysymbol");
if (myFunction)
myFunction();
However, this doesn't work because the DLL I was given was not a C DLL and I have no interface so Qt doesn't have a clue about what symbols it needs to resolve.
I've attempted to display all the definitions exported from my DLL using the dumpbin /EXPORTS command. Unfortunately this was unable to produce anything. I was hoping that I would get some sort of mangled C++ from this that I could then unscramble to make my own header.
I've attempted to use the dependency walker(very useful tool) however it couldn't resolve any symbols to give me some function definitions.
QLibrary only helps you if the library has functions exported as C symbols. If that is C++ you can dump the symbol table and look if that is sufficient for you. Names must be demangled: try to look for dumpbin or similar. It is however possible that you can't do this, it depends on how the symbols have been defined. In that case you'll have to ask for the header: read this.
Well it's absolutely legal to ask you for "instantiating an instance of their object". It's been simply their design decision to make the dll interface object oriented (as contrary to plain extern "C"). QtCore.dll is just someone else's DLL too, and you are instantiating their objects all the time.
But it also means that you will have harder time to call the DLL. The symbols are not "C" symbols (you can't export class that way) so QLibrary can't do anything for you. You can try dumpbin /EXPORTS from the DLL and then tediously unmangle them to reconstruct the class declaration. Luckily there are tools to help you (even online)
But not providing a header file for such DLL is completely dumb in the first place.
I tried looking for a similar question, but couldn't find one.
I have a ASPNET1.1 web application that is business-oriented. And there are many rules which are hardcoded in the application.
I want to start using Boo as an scripting language which developers can use to write some logic there (not final users).
Whenever a change in the BL is done, I would just update the "script file", deploy to server and that's it. No need for compilation. This is important.
So I have two questions:
It seems only CS-Script and Boo support NET1.1 and I don't like CSScript because it requires an exe or a compiled dll for each script. Is Boo the right choice? I wanted to use JINT (NET2.0+) or LUA (couldn't find a way to import to C#).
How fast is to execute Boo? I don't want to compile it (I know this is fast since it will be a static language). I want to only use the Boo interpreter Eval function.
By the way, the business logic I want to execute is simple. It should only be something like:
function(a, b)
{
return a["Type"] == b["Type"];
}
where a and b are simply Hashtables or DataRow. So I actually don't really need the System imports and all that.
Thanks in advance
I'm discarding Boo because even though I wanted to only use the Eval method, Boo automatically compiles the expression and loads that Assembly generated into the AppDomain.
Since I'm running in ASPNET1.1 and a big web application (thousands of users) that will not be efficient nor fast.
Even if I create an internal AppDomain and run the script in there so the memory is restored.
If I run in the same AppDomain, the memory would be eaten and eaten because those new assemblies will be loaded and never unloaded.
So I guess from Ricardo's response on some forums, that was never the intention of Boo language being designed as CLR language, but it beats the whole "scripting" halo put around Boo.
This is a big boo for Boo :(
I just tested LuaInterface 1.3.0 (the last one that supports NET1.1) and it has footprint zero. No assemblies are created and is just plain better in general (more javascript-like, no footprint, etc).
I just hope 1.3.0 version will be stable enough. There is no way I can upgrade my app to NET2.0 in the near future.
IMPORTANT UPDATE:
LuaInterface and luanet had a lot of memory leaks!!!! Instead I linked directly to the lua52.dll by using DllImport and using as a basis the following file: https://simpleot.googlecode.com/svn-history/r32/SimpleOT/trunk/SimpleOT/Scripting/Lua.cs
I used lua52 because it had support for VC++2003.
Background: I have a DLL I created that includes 2 c files. These c files reference a third c file which defines a user defined type (we'll call it class_pointer), which is a pointer of type class.
E.g.
typedef class pointer_class *class_pointer;
then defines the class:
typedef class pointer_class {..}
pointer_class has various variables and functions associated with it that the original 2 c files make use of through class_pointer.
I am using this DLL in an ASP.NET C# web application. I am using PInvoke to import the functions into the dll. However, when I go to call on these functions that involve the class_pointer, the website running on IIS hangs. This does not happen in the VS debugger. If I comment out said class_pointers, everything runs smoothly -- I have access to the DLL and everything.
I have tried changing the permissions on all the DLLs included in my bin directory (just to be safe) for NETWORK SERVICE to have read/execute permissions. The dll will work without the class_pointers, so I don't think it is an issue of permissions. Does anyone have any advice on what might be causing IIS to hang when these class_pointers are involved?
I finally was able to figure this out with the help of Microsoft's debugging tools.
The class_pointers were written by another developer that has since left the place I work. In the pointer_class, there was a function to get the current application path. When running on the web, this was set to the inetsrv directory in SYSWOW64 (The machine I was running on was a 64bit machine). To solve the issue, we set the application path to the website when we are running the web, rather than where the .exe application was running from (SYSWOW64/inetsrv).
Because the application path was wrong, the native dll was unable to load some files in and was putting up popup warning messages. These pop up messages were waiting for a user response and since we couldn't get one on the web, the application hanged!
Hope this helps someone else out there!