I've spent the past two days trying to get the node wiring-pi module running on either windows or ubuntu. It installed no problem on my RaspberryPi, but developing on RPi isn't ideal. After a ton of error messages that don't lead me very close to a solution, I'm beginning to realize that trying to set-up a node module which was designed to run on an ARM processor and getting it working on an x86 machine for development may not be the best idea.
Has anybody else dealt with this sort of thing before? How do you write your ARM based programs in an x86 environment? Developing directly on the Pi has it's own set of issues.
What I was thinking of doing was to require the wiring-pi module like this
var wpi = require('wiring-pi')|| { //recreate the required wiring-pi methods for testing on x86};
however, that would mean my npm install would also fail, or need to be different depending on if I was building directly on the raspberyPi or on the windows/ubuntu x86 system.
Anybody else have another solution to working around these sorts of issues?
I have the same problem, and came to the same realization that trying to get the ARM modules working on X86 was not feasible. Hopefully your Raspberry Pi specific calls are isolated in a module that you can then easily replace on x86. I've not found a more clever solution than that.
Related
Currently i am running a Raspberry PI and STM32 in a project and i was looking into the MP1 to replace it with. As its an easier setup.
I am running a node.js application on the raspberry and I am trying to get that application to run on the MP1. I have tried to follow the tutorials from stm32 but doesnt help that much. Has anyone done anything like this? I know the microcontroller is new as it has been released in Oktober.
I know its a broad question. But anything helps as i cant find a lot about it.
Thanks
If you run an embedded OS like Embedded Linux or RTOS on the ARM you can run node.js and see https://elinux.org/images/1/14/Karagoz-nodejs-presentation_0.pdfhttps://stackoverflow.com/questions/44753321/is-it-possible-to-run-node-js-on-an-rtos. On a completely bare metal machine it may also be possible however this is very effortful to implement a JavaScript runtime like it was done for the ESP32-WROVER module (https://www.neonious.com/lowjs/)
You can implement websockets also in C/C++ that can run on bare metal ARM see https://github.com/zaphoyd/websocketpp
I am facing a problem with the analysis of an crashdump that was generated on a linux machine I do not have access to. The situation looks like the following:
Development happens on Linux machines running distributions like Ubuntu 14.04, 13.10 and 14.04.
The target is an embedded x86 based System that runs on a stripped
down Debian 5
The build for the target happens on one of the development machines, dependent on who does the release. We use a chroot-environment to do the cross-build and we are pretty sure the chroot-environments are the same (revision controlled via git)
By the Way, the software is written in C++.
Now from time to time the software crashes in a situation we cannot reproduce so our users send us an core-file via email. The plan looks like the following:
Compile the same version of the software with debug-symbols from within the chroot-environment
Look at the core-file with GDB, also inside the chroot-environment.
This normally works fine, except for one problem. It only works if debugging happens on the same machine the stripped and the released binary was build on. On other machines, the debugger seems to get confused, a stacktrace may consist of completely unrelated calls that do not make any sense. This is a thing we are wondering about for some time now without a conclusion. Also it was a situation we could deal with easily.
But then some mindless upgrading to a new distribution took place on my machine, rendering all the core files from targets that I did the build for useless...
Now I am looking for a way to (a) understand what is happening and (b) for a way to cross-debug core files that where generated on machines without the possibility of remote access that run different Linux distributions. Oh and (c) if we maybe are doing something fundamentally wrong?
It only works if debugging happens on the same machine the stripped and the released binary was build on.
(a) understand what is happening
It's pretty obvious that despite your belief that you have a hermetic build environment, you in fact don't. If you did have a completely hermetic build environment, building on a different machine wouldn't matter.
Therefore, your first step should be to find and eliminate everything non-hermetic, until you can build bit-identical releases on every one of the machines you are building your releases on.
Once you have achieved that, it should also solve your (b) problem.
(c) if we maybe are doing something fundamentally wrong?
What you appear to be doing fundamentally wrong is that you trust that your chroot is version-controlled, when it appears to clearly not be.
I'd like to develop haskell code that will run on windows and interact with windows OS APIs, but I would like to do it on a linux machine. How do I accomplish this? I can compile on a windows machine and that works, but not on a linux machine. Haskell can use a LLVM backend, can't it? Can I use LLVM to accomplish this? Or work with MinGW somehow?
I tried many possibilities, including GHC on Wine (didn't work for me, despite many notices advertising that it works "out of the box").
For cross compilation, one problem lies in making GHC find your C libraries and DLLs (for windows). Template Haskell will also give you headaches (because it needs to load linux libraries but then compile for windows).
I never managed to get around those problems properly.
In the end, I opted for installing GHC on a Windows VM, and now I use a script to push stuff to a repo, connect to the windows machine via SSH, pull, clean, recompile and test, all executed from a linux CLI and giving me feedback about what's happening on windows.
EDIT: I'm not providing this answer in an attempt to discourage anyone from trying something smarter. I too am interested in real cross-compilation and, if someone has a good solution, I'm all ears. My alternative method always works, but it really is a pain, having to start a VM just for this. Furthermore, it implies using one VM per OS per architecture, which is quite heavy.
I have an application using ThreadX 5.1 as the kernel.
The Image is flashed on to a hardware running an ARM 9 processor.
I'm trying to build a Simulator for the application that can be run on Windows (say XP, 32-bit).
Is there any way I can make it run on Windows, without modifying the entire source code to start calling win32 system calls?
You can build a Simulator for the application that can be run on Windows with "ThreadX for Win32".
"ThreadX for Win32"'s specification is hear.
http://rtos.com/products/threadx/Win32
Yes you can if you are willing to put in the work.
First observe that each threadx system call has an equivalent posix call except for events.
So your threadx program can run as a single process using posix threads, mutexes, etc.
Events can be handled by an external library (there are a few out there).
If you find this difficult in windows then the simplest thing to do is set up a linux vm. I use an ubuntu vm running on Virtual Box. It is very easy to set up. All you will need is the cdt version of eclipse.
Next you need to stub out all of your low level system calls.
This is also easier than you might think. For example, if you have a SPI driver to read and write to flash, you can replace your flash with a big array which is quite easy to work with at this level.
Having said all this, you may get more mileage if your threadx application is modular. Then you can test each module on it's own and you don't need to mess with threads, etc.
As a first approximation this may give you what you need without going the distance to port the whole thing to run under posix.
I have done this successfully in the past and developed a full set of unit tests for a module that allowed me to develop and test it (on my mac) before going to the target. Development is much faster and reliable this way.
Another option you may want to consider is to find a qemu project that supports your microprocessor. With some work you can develop a complete simulator for your platform and then run the real firmware under the emulator.
Good luck.
I will have (maybe) to work soon on ARM platform hosting a linux distribution (I don't know which distribution ..).
I know the project concerns video streaming, but I can't tell you more. Actually I only received the announe, and meet nobody yet.
I've never worked on such platform. So the idea for me is to test before the project starts.
What would you advise me to undestand how works such platform ? Internet links? Tutorials? Tools
Morevover, as I don't have any ARM processor at home (well only my iPhone ..) Which virtual machine would you advise me? (I clearly don't want to lose time installing and testing every one of them.)
I am aware of this page on wikipedia. Which one is the more appropriate running on a MacOS X 10.5/intel platform? Which linux distribution to install on the virtual machine?
I know the topic is quite wide, so any idea is welcomed! :-)
For a virtual machine that can emulate a ARM platform try QEMU. You can install a ARM-based Debian Linux distribution and tinker around with it. A google search on ARM, QEMU and Debian will get you started.
Also: Don't worry to much about the ARM CPU. You will use linux, so all the low-level stuff is already done for you. It's much more important to learn how the linux boot process works. How to install stuff ect. You will rarely (if ever) notice that you're running on a ARM device. The big difference to a PC running linux is, that the ARM will be a lot slower.
If you're looking for a real piece of hardware to play around with I suggest that you take a look at the beagleboard (www.beagleboard.org). It's cheap (around $150) and runs (among other things) various linux distributions.
With the beagleboard you'll get the whole linux cross compilation experience if you want (be warned: you'll pull your hair out).
I can't answer all of your questions, but there's a full port of Debian GNU/Linux on ARM. Works fabulously in my experience (I've tried it on a QNAP). Everything that's available in Debian works on QNAP now! So it's probably easiest to first try Debian tools and packages that come close to your project, and then continue from there.