I want to create an USB interface using PIC18F14K50. I have source code using c18 compiler but I want to update my firmware using XC8 (v1.37) compiler. I am using MPLAB X 3.25. Though the C compiler is giving me good results, I want to make my firmware forward compatible.
Download the current Microchip Libraries for Applications from the vendor's website. Most (if not all) of the USB sample projects in the MLA compile with XC8 and build for the PIC18F14K50.
Related
I'm trying to get my app ready for Apple Silicon. My app currently uses SSE instructions for Mac and equivalent Neon implementation for iOS.
Apple porting guide suggests moving to the Accelerate framework, which I'm not ready to do right now.
Is there a way to keep using SSE/neon (based on the architecture) in the universal binary for Apple silicon? I can see that arm64_neon.h is not available for Apple Silicon.
NEON intrinsics are available via the arm_neon.h header, and are standard ARM C Language Extensions intrinsics. arm64_neon.h is a MSVC specific header name (and since a few versions of MSVC, you can use the standard header name arm_neon.h for both 32 and 64 bit ARM even there, like other compilers).
I am trying to write an OpenCL hostcode for a custom kernel of mine and I want to count the LLVM IR instructions that where executed. My problem is, the LLVM IR representation of the kernel is lost after I build it, and the only thing that exists is the native binary. Is there any way to:
count the native architecture instructions executed?
find a mapping between the native architecture instructions and the LLVM IR representation and, through this, manage to count the LLVM IR instructions that were executed?
I think that is not directly possible through the OpenCL API. But there are two ways you could achieve counting native/IR instructions using tools:
IR:
You could use the SPIR-V (Khronos-defined IR, similar to LLVM IR, but portable) tools, see this README to generate SPIR-V from an OpenCL source. Then count the IR instructions of the result.
Native:
You can use an offline OpenCL compiler from some SDK, e.g. the Intel OpenCL SDK provides a command line tool called ioc64 which can generate assembly code from OpenCL and even allows you to specify the target architecture.
You could try to disassemble the OpenCL-generated binary (via clGetProgramInfo() with CL_PROGRAM_BINARY_SIZES and CL_PROGRAM_BINARIES), e.g. with an appropriate command line tool after storing it to disk.
Hope that helps.
I am a newbie in OpenCL stuffs.
Whats is the best way to compiler an OpenCL project ?
Using a supported compiler (GCC or Clang):
When we use a compiler
like gcc or clang, how do we control these options? Are they
have to be set inside the source code, or, likewise the normal
compilation flow we can pass them on the command line. Looking at the Khornos-Manual-1.2, there are a few options provided for cl_int clBuildProgram for optimizations. :
gcc|clang -O3 -I<INCLUDES> OpenCL_app.c -framework OpenCL OPTION -lm
Actually, I Tried this and received an error :
gcc: error: unrecognized command line option '<OPTION>'
Alternatively, using openclc:
I have seen people using openclc to compiler using
a Makefile.
I would like to know which is the best way (if
there are actually two separate ways), and how do we control the
usage of different compile time options.
You might be aware but it is important to reiterate. OpenCL standard contains two things:
OpenCL C language and programming model (I think recent standard include some C++)
OpenCL host library to manage device
gcc and clang are compilers for the host side of your OpenCL project. So there will be no way to provide compiler options for OpenCL device code compilations using a host compiler since they are not even aware of any OpenCL.
Except with clang there is a flag that accept OpenCL device code, .cl file which contains the kernels. That way you can use clang and provide also the flags and options if I remember correctly, but now you would have either llvm IR or SPIR output not an device executable object. You can then load SPIR object to a device using device's run-time environment(opencl drivers).
You can checkout these links:
Using Clang to compile kernels
Llvm IR generation
SPIR
Other alternative is to use the tools provided by your target platform. Each vendor that claims to support opencl, should have a run-time environment. Usually, they have separate CLI tools to compile OpenCL device code. In you case(I guess) you have drivers from Apple, therefore you have openclc.
Intel CLI as an example
Now to your main question (best way to compile opencl). It depends what you want to do. You didn't specify what kind of requirements you have so I had to speculate.
If you want to have off-line compilation without a host program, the considerations above will help you. Otherwise, you have to use OpenCL library and have on-line compilation for you kernels, this is generally preferred for products that needs portability. Since if you compile all your kernels at the start of your program, you directly use the provided environment and you don't need to provide libraries for each target platform.
Therefore, if you have an OpenCL project, you have to decide how to compile. If you really want to use the generic flags and do not rely on third party tools. I suggest you to have a class that builds your kernels and provides the flags you want.
...how do we control these options? Are they have to be set inside the source code, or, likewise the normal compilation flow we can pass them on the command line.
Options can be set inside the source code. For example:
const char options[] = "-cl-finite-math-only -cl-no-signed-zeros";
/* Build program */
err = clBuildProgram(program, 1, &device, options, NULL, NULL);
I have never seen opencl options being specified at the command line and I'm unaware whether this is possible or not.
Does anyone know how to use gcc to compile a bare-metal program for xilinx's microblaze processor?
It is very easy to do this with xilinx sdk, but now I am trying to integrate the microblaze build into a larger build workflow. In other words, I need to be able to do everything command line -- not using the sdk gui.
Most of xilinx support and examples are centered around their sdk. There seems to be limited support on their site for gnu tools but they seem to be focused on users who want to compile a linux kernel for microblaze. I just want to compile a simple bare metal application.
Ideally, I would be able to do something like
$ gcc microblaze_program.c
and end up with a microblaze executable.
Has anyone done this before? Does anyone know of any examples?
SDK creates a makefile - you can just make use of this from the command line.
If you don't open the command-line from Xilinx's provided icon, you need to call $XILINX/settings[32|64].[bat|sh] to set up the environment correctly first.
Is it possible to compile native GCC for ARM (host == target == ARM) using Code Sourcery G++?
If it is not possible, could I use crosstool-NG to build the cross-compile and then using this one for compiling the native ARM GCC?
Thank you,
Edit: as to why: I'm creating my own distro for beagleboard...
CodeSourcery provides prebuilt toolchains only for Linux/x86 and Windows (see "Host System Requirements" here). If you want a native ARM-hosted toolchain, you should be able to build one using a cross-compiler. If you want a prebuilt one, you can try some of the existing ARM distros such as Debian-arm, or Aboriginal Linux (it's made to be run in QEMU but you can probably extract the compiler from it and run natively).
Tiny C Compiler runs decently natively on the kindle 3.
Find it on the mobileread forums compiled for native use.
Code sourcery toolchain works for simple comilation via "arm-none-linux-gnueabi-gcc foo.c" IIRC with no effort. creating native arms. Crosstools-ng as well but neither natively AIUI.
I looked into http://buildroot.uclibc.org/downloads/manual/manual.html#_about_buildroot
for a more comprehensive solution.
There are some options in there for what you require IIRC using x-compile to make the compiler but Crosstools is the more robust chain I had trouble with codesourcery doing true static build. HTH
better off to use openembedded