I tried to install edge TPU compiler on my raspberrypi 3b+ but apparently it is no longer supported on 32bit. Can I install compiler on a 64bit machine, compile my code, turn it into a code readable by the edge tpu and bring this code back and run it on my raspberry pi? Or will there be conflict of some sort?
As far as application goes:
You can write your application code on the rpi. The code that you compiles on an x86-64 machine won't be executable on the rpi due to architecture differences. Unless you are using a cross compiler.
Now on the edgetpu compiler:
The edgetpu compiler can only be installed on the x86_64 machine, although since the format of the model is the same for all platform (flat buffer), you can use the same model compiled on the x86_64 platform on your rpi just fine!
Related
i get this massage when i try to compile
gcc plug-in: No AVR Toolchain installation found. The AVR GCC plug-in can still be used if you set up your own build tools.
Which version of AVRstudio is working?
In general, it is a good idea to say what piece of software is giving you an error message when you post questions here. I am guessing that you are using AVR Studio 4.19 and that is the piece of software that is giving you that error message about the toolchain not being found.
AVR Studio 4 is designed to use the AVR GCC toolchain provided by WinAVR, so if you install WinAVR you can probably get around that message. But I would not recommend using either of these pieces of software because they are extremely old and do not support the latest AVRs.
The current IDE from the company that makes AVRs is called Microchip Studio for AVR® and SAM Devices. You can download it for free and it has an updated AVR GCC toolchain that comes with it.
I'm trying to compile my working 32-Bit DLL project which communicates with USB-Devices to a 64-Bit Windows-DLL.
The sources compile fine with MinGW32 but if I try to build them with MinGW W64 I get an error within hidclass.h:
hidclass.h|132|error: unknown type name ‘PINTERFACE_REFERENCE’
I can't find anything about PINTERFACE_REFERENCE so I'd be glad for every hint about this.
Building it in 32-Bit is not an option because it will be used within Java via JNI and I have to support both 32- and 64-Bit JVMs.
I know that I could do minor changes to my code and switch to Microsofts Visual C++ compiler using VisualDDK and the Windows Driver Kit but I'd love to continue using my free toolchain since it works flawless for 32-Bit builds and I don't have to think about licensing issues.
I have a x86 development machine and developing kernel module for mips. I wanted to disassemble a routine to find problems with the module.
So my question is
"Can I disassemble it on x86 machine or I will have to get a MIPS development machine ?"
I tried it, but it disassembles in x86 instruction set.
You basically need some form of cross compilation. A cross compiler would allow you to compile on a host machine (x86 in your case) for a target machine (MIPS in your case). So you would be able to generate MIPS binaries from your x86 machine. Moreover, you would also get all the other tools associated to the compiler, such as objdump. Here you have a guide on how to build a cross compiler for GCC.
Assuming you are using objdump to disassemble a binary, you may not need to build a cross compiler. objdump belongs to binutils and it may be possible to just compile binutils for using MIPS as the target (I have never tried to create a cross-platform build of binutils, so I am not 100% sure).
EDIT: I just read the title again, and realized that you are using gdb. In that case I believe you would need to create a full cross compiler, and create a cross-platform version of gdb.
I have a small C program that I wish to port from Linux to Windows. I can do this with the MinGW compiler, and I have noticed that it has two different prefixes, amd64 and i586. I am on an i686 computer and I was wondering if I compile my C program using and amd64 architecture, will it run on my i686 machine? And vice-versa?
UPDATE:
Is there a compiler that compile C code to run on ANY architecture?
If you compile your code for i586 (actually what is commonly called x86) it should work fine on AMD64 (x86-64) processors, since x86-64 processors can execute "legacy" 32 bit code, as long as the OS supports this - and mainstream OSes usually do; Windows support for 32 bit applications in particular is really good, since most applications installed on the average Windows system are still 32 bit.
The contrary instead does not hold true, since the x86-64 instruction set is (loosely speaking) an expansion of the x86 architecture, so any non-64 bit x86 processor wouldn't know how to interpret the new machine code (and even if it knew it, it wouldn't have the resources to run it).
As for the edit, you can't generate machine code that runs natively everywhere; the usual solution in such cases is to use pseudo-compiled languages that output an intermediate-level machine code that needs an architecture-specific VM installed to be run (the classic example here is Java and .NET). If instead you use a language compiled to "native code", you have to generate an executable for each target platform.
I have 3rd party libraries for my mac applications which used to link nicely to my application with the previous version of Mac OS X.
I have upgraded to Snow Leopard and now g++ linker complains:
ld: warning: in /Users/paul/Projects/3rdPath/NHUI/Lib/mac32/libNHUI.a, file is not of required architecture
The link also fails to locate functions from this library.
Do I need Snow Leopard versions of each 3rd party library or can I provide some compiler/link switch which could allow me to build like I did in the previous Mac OS X version.
Thank you,
Paul
I don't even own a Mac so feel free to disregard this, but your path has "mac32" in it, which suggests to me that it's a 32 bit library. "architecture" in computers usually refers to 32/64 bit CPU architectures, and I've heard that Snow Leopard has a big emphasis on migrating to 64 bit apps. As such, my first blush impression is that you are using a 32 bit library which Snow Leopard is warning you away from.
Hope that helps you get going in the right direction!
My guess is you're compiling 32/64-bit Universal, but the library itself is only 32-bit. While ideally you should get a 64-bit version of the library, for the time being you should just turn off 64-bit compilation of your application.