I am Making a MicroPLc and has choosen PIC24FJ series as controller. IN PLC World People use LAD, FBD, STL ,etc for Programming not c or c++.
There a Lot of Open software which converts PLC language to 'C'. My Question is how to convert that C code in .Hex file without Using MPLAB X . or is there any method of procedure by which we can Invoke XC 16 Compiler for compiling and generation .HEX File.
a Internet Search reveals there is an SDK for Mplab but that just help to Burn .Hex file in to the Chip. Nothing about converting 'c' to .Hex
Any suggestion or Link to an Api, Dll etc will be appreciated.
Thanks
I'm unsure exactly what you're asking for but do you just mean a toolchain to compile your C file into a hex binary file?
In that case you should be able to run the XC16 compiler from command line.
MPLAB X just generates a GCC makefile if I'm not mistaken.
Check the XC16 C Compiler manual:
http://www.microchip.com/stellent/groups/techpub_sg/documents/devicedoc/en559023.pdf
And this resource may also be of use:
http://adamsiembida.com/how-to-compile-mplabx-projects-from-the-command-line/
Related
I haven't been able to find a list of possible values for the LANGUAGE variable on the CMAKE.org site or anywhere else. Would someone please enumerate the values CMAKE recognises? I specifically need to specify Objective C++.
Just take a look at all the CMakeDetermine<Language>Compiler.cmake scripts CMake ships with.
This would result - in alphabetic order - in the following you could put in the enable_language() call:
ASM
ASM-ATT
ASM-MASM
ASM-NASM
C
CSharp
CUDA
CXX
Fortran
Java
OBJC (Objective C)
OBJCXX (Objective C++)
RC (Windows Resource Compiler)
Swift
Evaluated with CMake Version 3.16
References
enable_language()
Generic rule from makefile to CMake
Update for CMake 3.16 and later: CMake added native support for Objective-C in version 3.16. The corresponding language strings are OBJC and OBJCXX. Thanks to squareskittles for pointing this out.
Original answer: The support for languages varies across platforms.
Currently CMake supports C, CXX and Fortran out of the box on most platforms. There is also support for certain Assemblers on some platforms. For a complete list, check out the contents of the Modules/Platform folder.
The idea is that the language given to the LANGUAGE field of the project command or the enable_language command is just a string, which will then be used by CMake together with the language dependent variables to setup the build system. The Platform scripts shipping with CMake do this configuration for C and C++. In theory, one can add their own language simply by setting the correct variables (although this is quite involved and I do not know of anyone ever successfully doing this).
As for adding support for Objective-C: Since most toolchains use the same compiler for C and Objective-C, you do not need to configure a new language. Simply compile your code as if it was plain C and add the appropriate compiler flags for Objective-C support.
Unfortunately, this is not very comfortable to use and can easily break in corner cases. But until CMake adds explicit support for Objective-C as a first class language, I'm afraid this is as good as it gets.
How to use SQLite3 library in D language program on Windows?
I found a similar question with Ubuntu, but it didn't work in my case.
import std.stdio, std.string, etc.c.sqlite3;
void main () {
sqlite3* db;
auto ret = sqlite3_open (toStringz("mydb.s3db"), &db);
writeln (ret);
}
As I assume, the sqlite3.d is some kind of header to the real SQLite3 library. I've got an sqlite3.dll, but I have no idea about how to link it with my program. pragma works only with lib formate (like pragma(lib, "sqlite3")).
Maybe I should use the SQLite sources, but how is it possible to compile it together with D code? Or is it better to find some way to convert dll to lib?
What is a general method to solve such problems in D?
Or is it better to find some way to convert dll to lib?
Yes. From the question Statically linking SQLite with DMD (Windows x86), just run the .dll file through implib with the /system switch (linking with the resulting .lib file will still result in dynamic linkage and a dependency on the .dll file).
You can also compile the sqlite source (with modification) using Digital Mars C copmiler which will then give you an object file you can statically link.
CMake developers recommend adding a dummy Fortran file to tell CMake that static libraries need to be linked with Fortran libraries (for example when linking C program with LAPACK).
My first thought was to use empty dummy.f. But ifort 9.0 won't compile it.
What is the minimal portable dummy Fortran file?
Is old Intel compiler the only one that has problem with empty file?
Same error with GFortran and Absoft Fortran. Actually, you need a "program" block to build an executable.
This dummy.f would work:
program dummy
end
According to standard, "A Fortran program must contain one main program and may contain any number of the other kinds of program units". (see "Fortran 95 handbook" by Adams et al., section 2.1.1 p.19)
Or in standard Fortran 95 same section 2.2.1, p.12:
A program consists of exactly one main program unit and any number
(including zero) of other kinds of program units. The set of program
units may include any combination of the different kinds of program
units in any order as long as there is only one main program unit.
What are the differences between the byte code binary executables such as Java class files, Parrot bytecode files or CLR files and machine code executables such as ELF, Mach-O and PE.
what are the distinctive differences between the two?
such as the .text area in the ELF structure is equal to what part of the class file?
or they all have headers but the ELF and PE headers contain Architecture but the Class file does not
Java Class File
Elf file
PE File
Byte code is, as imulsion noted, an intermediate step, right before compilation into machine code. Because the last step is left to load time (and often runtime, as is the case with Just-In-Time (JIT) compilation, byte code is architecture independent: The runtime (CLR for .net or JVM for Java) is responsible for mapping the byte code opcodes to their underlying machine code representation.
By comparison, native code (Windows: PE, PE32+, OS X/iOS: Mach-O, Linux/Android/etc: ELF) is compiled code, suited for a particular architecture (Android/iOS: ARM, most else: Intel 32-bit (i386) or 64-bit). These are all very similar, but still require sections (or, in Mach-O parlance "Load Commands") to set up the memory structure of the executable as it becomes a process (Old DOS supported the ".com" format which was a raw memory image). In all the above, you can say , roughly, the following:
Sections with a "." are created by the compiler, and are "default" or expected to have default behavior
The executable has the main code section, usually called "text" or ".text". This is native code, which can run on the specific architecture
Strings are stored in a separate section. These are used for hard-coded output (what you print out) as well as symbol names.
Symbols - which are what the linker uses to put together the executable with its libraries (Windows: DLLs, Linux/Android: Shared Objects, OS X/iOS: .dylibs or frameworks) are stored in a separate section. Usually there is also a "PLT" (Procedure Linkage Table) which enables the compiler to simply put in stubs to the functions you call (printf, open, etc), that the linker can connect when the executable loads.
Import table (in Windows parlance.. In ELF this is a DYNAMIC section, in OS X this is a LC_LOAD_LIBRARY command) is used to declare additional libraries. If those aren't found when the executable is loaded, the load fails, and you can't run it.
Export table (for libraries/dylibs/etc) are the symbols which the library (or in Windows, even an .exe) can export so as to have others link with.
Constants are usually in what you see as the ".rodata".
Hope this helps. Really, your question was vague..
TG
Byte code is a 'halfway' step. So the Java compiler (javac) will turn the source code into byte code. Machine code is the next step, where the computer takes the byte code, turns it into machine code (which can be read by the computer) and then executes your program by reading the machine code. Computers cannot read source code directly, likewise compilers cannot translate immediately into machine code. You need a halfway step to make programs work.
Note that ELF binaries don't necessarily need to be machine/arch specific per se.
The interesting piece is the "interpreter" header field: it holds a path name to a loader program that's executed instead of the actual binary. This one then is responsible for loading the actual program, loading and linking libraries, etc. This is the way how eg. ld.so comes in.
Theoretically one could create an ELF binary that holds java bytecode (or a complete jar). This just needs some appropriate "interpreter" program which starts up a JVM and loads the code from the binary into it.
Not sure whether this actually has been done before, but certainly possible.
The same can be done w/ quite any non-native code.
It also could serve for direct multiarch support via some VM like qemu:
Let the target platform (libc+linker scripts) put the arch name into the interpreter program name (eg. /lib/ld.so.x86_64, /lib/ld.so.armhf, ...).
Then, on a particular arch (eg. x86_64), the one with native arch name will point to the original ld.so, while the others point to some special one that calls up something like qemu-system-XXX.
I'm looking for a way to patch Mach-o Binaries, although I've come up short of possible (and not too tedious) ways of accomplishing this. I'm very familiar with hex editing and patching bytes by hand, although ultimately what I really need is a way to create a drag'n'drop method of doing this via a compiled Xcode Cocoa application.
Any example, or even better, an actual usable Xcode project template to get start would be very helpful.
If I wanted to do this kind of thing, I'd start with HexFiend. Then I'd look up the implementation of dyld and otool in the Darwin source repository and the Mac OS X ABI Mach-O File Format Reference
If you want to programmatically deal with the Mach-O file format to access load commands, segments, sections and more, you should use libMachObjC which is part of the class-dump project. The API is very easy to use.
Have a look at the deprotect tool source code for an example of reading a Mach-O file, patching some bytes and writing the modified file to disk.