Has anybody experienced using the Invensense IMU3000 with some microcontroller?
I am trying to build the IMU library for a PIC but I am stuck with the dependencies.. any other experience with others microcontrollers will be nice as well!
Basically I don't get whether it is better to take the Visual Studio 2005 project and make the changes there, adding the PIC dependencies (I get stuck..) or compile the whole library in the PIC environment..
Any hint, even with other platforms, would help!
Thank you all!
PC and PIC programming are so very different... Also there are so many pIC variants, they are hugely different from each other, it's hard to answer such an open ended question. However, basically you're writing mathematical algorithms. So write these as ansi c functions, hosted with a load of PC things (dialogs etc) and once they're working, you can move just the math functions over to the PIC - having already got a framework running on the PIC, ready to receive the algorithms. BUT - take care with memory. You have bags of it on the PC, you have to be mean with memory once you work on a PIC. Good luck, enjoy!
While it can be helpful to write code on the PC that will eventually move to the PIC, you will need to make sure that all code that will move has been written with portability in mind. That is, you cannot assume that code that compiles and works perfectly under Visual Studio will work without modification on any other platform.
To run in the PIC, all of the code must be compiled with cross development tools that are designed to target the PIC.
That said, I often develop algorithms and detailed processing code in the PC where a test suite can be easily used to verify its operation, and then recompile it for my target platform.
Incidentally, Google tells me that the IMU-3000 is a MEMS Gyro. It would probably be helpful to include at least the link to its data sheet in the question.
Related
1) I learned writing bootloaders and tested it using bochs. Now, I want to add GUI to by bootloader. I have googled but didnt hit on relevant sources for that. I even tried searching github for existing projects. I checked out this question. But is there any way to install some graphics libraries or include x-window-system APIs in my code to give in a GUI env (e.g: Chameleon, GAG) instead of including just a splash image ?
2) Is there any possibility to add python execution environment during bootloader stage, so that when I step in protected mode, i could add some python scripts?
3) How to add standard C/C++ library support?
Thanks in advance.
It might help if you told what kind of bootloader you're talking about. I work with this daily and most of what you're saying seems like crazy talk. LOL.
Usually bootloaders are very small startup program that takes a decision on what to load next. Some bootloaders contains features for "flashing" the main application. (The main app often cannot flash it self.) The bootloader being the first piece of code the processor meets, makes it very critical. You do not want it to fail nor upgrade it. Hence bootloaders tend to strive for smaller is better.
As for your questions.
3) I've never seen a bootloader not written in c. So it got that one covered. (They exist though) C++ you would have to compile the whole project with c++. (Not a problem.)
1) and 2) I'm not sure what "protected mode" is, but to include eg python or x-windows you would have to include the source into your project. Here's the thing. Usually bootloaders are baremetal code and code like X isn't. You'd have to include a whole lot of other code as well. And you'd end up with a bootloader at 500 mb. Usually you strive for something like 5 kb.
The splash image is usually done through low level interaction with the graphic card.
If anyone else is interested in bootloader development, I can recommend to look at uboot. It's a linux (mostly) loader and is rather easy to find your way through. And it already supports a lot.
What I need to do is to compile and run a program written in C/C++ on Arduino.
I'm ok with every open source RTOS if it supports C especially struct.
So I have found contikiOS does that, and tried to get started.
But I guess contikiOS doesn't support Arduino port anymore and Due is quite recent model so that I couldn't find proper information.
If you know any information on it or want me to help, please give me an advice.
Ah, do you have any other recommendation for RTOS?
Thanks.
If what you need is to run a simple c/c++ software, you have to know that the arduino environment support c/c++ code, as explained in the arduino homepage http://code.google.com/p/arduino/
If for your requirements, you need to use a real time operating system, there is a contikiOS version for Arduino (Contiki-Arduino).
Last but not least, if you are a beginner, i would advice you to use a popular RTOS, to find support on internet easily if you need it. Sadly, i am not an expert on that field. But when i google it, i find Duinos, maybe you could have a look on it.
a previous relevant question from me is here Reverse Engineering old paint programs
I have set up my base of operations here: http://animatorpro.org
wiki coming soon.
Okay, so now I have a 300,000 line legacy MSDOS codebase. It's sort of a "be careful what you wish for" situation. I am not an experienced C programmer. I'm not entirely inexperienced either, but for all intents and purposes I'm a noob to the language and in particular the intricacies of its libraries. I am especially ignorant of the vagaries of the differences between C programs written specifically for MSDOS and programs that are cross platform. However I have been studying this code base for over a year now, and this is what I know about Animator Pro:
Compilers and tools used:
Watcom C compiler
tcmake (make program from Turbo C)
386asm, a specialised assembler for the Phar Lap dos extender
and of course, the Phar Lap dos extender itself.
a selection of obscure dos utilities
Much of the compilation seems to be driven by batch files. Though I have obtained copies of all these tools, I have not yet succeeded at compiling it. (though I have compiled its older brother, autodesk animator original.
It's got a plugin system that replicates DLL before DLL's were available, based on REX. The plugin system handles:
Video Drivers (with a plethora of included VESA drivers)
Input drivers (including wacom tablets, and keyboards)
Drawing Tools
Inks (Like photoshop's filters, or blending modes)
Scripting Addons (essentially compiled scripts)
File formats
It's got its own script interpreter named POCO, based on the C language- The scripting language has enough power to do virtually all the things the plugin system can do- Just slower.
Given this information, this is my development plan. Please criticise this. The source code is available in the link above, so you can easily, if you are so inclined, assess the situation yourself.
Compile with its original tools.
Switch to using DJGPP, and make the necessary changes to get it to compile with that, plus the original assembler.
Include the Allegro.cc "Game" library, and switch over as much functionality to that library as possible- Perhaps by simply writing new video and input drivers that use the Allegro API. I'm thinking allegro rather than SDL because: there is a DOS version of Allegro, and fascinatingly, one of its core functions is the ability to play Animator Pro's native format FLIC.
Hopefully after 3, I will have eliminated most or all of the Assembler in the project. I say hopefully, because it's in an obscure dialect that doesn't assemble in any modern free assembler without significant modification. I have tried them all. Whatever is left gets converted to assemble in NASM, or to C code if I can define the assembler's actual function.
Switch the dos extender from Phar Lap to HX Dos http://www.japheth.de/HX.html, Which promises to replicate as much of the WIN32 api as possible. Then make all the necessary code changes for that to work.
Switch to the win32 version of Allegro.cc, assuming that the win32 version can run on top of HXDos. Make any further necessary changes
Modify the plugin system to use some kind of standard cross platform plugin library. What this would be, I have no idea. Maybe you can offer some suggestions? I talked to the developer who originally wrote the plugin system, and he said some of the things it does aren't possible on modern OS's because of segmentation restrictions. I'm not sure what this means, but I'm guessing it means all the plugins will need to be rewritten almost from scratch.
Magically, I got all the above done, and we can try and make it run in windows, osx, and linux, whilst dealing with other cross platform niggles like long file names, and things I haven't thought of.
Anyone got a problem with any of this? Is allegro a good choice? if not, why? what would you do about this plugin system? What would you do different? Is this whole thing foolish, and should I just rewrite it from scratch, using the original as inpiration? (it would apparently take the original developer "About a month" to do that)
One thing I haven't covered above is the text/font system. Not sure what to do about that, but Animator Pro has its own custom font format, but also is able to use Postscript Type 1 fonts, and some other formats.
My biggest concern with your plan, in a nutshell: Your approach seems to be to attempt to keep the whole enormous thing working at all times, tweaking the environment ever-further away from DOS. During each tweak to the environment, that means you will have approximately a billion subtle assumptions that might have broken at once, none of which you necessarily understand yet. Untangling them all at once will be incredibly painful.
If I were doing the port, my approach would be to disable as much code as possible to get SOMETHING running in a modern environment, and bring the parts back online, one piece at a time. Write a simple test harness program that loads a display driver and draws some stuff, and compile it for DOS to make sure you understand the interface. Then write some C code that implements the same interface, but with Allegro (or SDL or SFML), and make that program work under Windows or Linux. When the output differs, you have a simple test case to work from.
Your entire job on this port is swapping out implementations of various interfaces and functions with completely new ones. This is a job that unit testing excels at. Don't write any new code without a test of some kind that runs on the old code under DOS! Make your potential problems as small and simple as you possibly can. Port assembly code instead of rewriting it only if you're reasonably confident that it will actually make your job easier (ie, algorithmic stuff that compiles fine with few tweaks under NASM). Don't bite off a bigger piece than you can comfortably fit in your brain at once.
I, for one, look forward to seeing your progress! I think what you're attempting to do is great. Thanks for doing it.
Hmmm - I might approach it by writing an OpenGL video "driver" for it. and todays machines are fast enough with tons of ram that you could do all the pixel specific algorithms on main CPU into a back buffer and it would work. As the "generic" VGA driver just mapped the video buffer to a pointer this would be a place to start. There was a zoom mode in the UI so you can look at the pixels on a high res display.
It is often very difficult to take an existing non-trivial code base that wasn't written with portability in mind - you mention a few - and then try to make it portable. There will be a lot of problems on the way. It is probably a better idea to start from scratch and rewrite the code using the existing code as reference only. If you start from scratch you can leverage existing portable UI solution in your new project like Qt.
I want to run a simple hello world, written in c, app.
on my at91sam9rl-ek.
Is it possible without an os?
And (if it is) how do I have to compile it?
-right now I try using g++ lite for creating arm code
(In general which programms can the board start without OS,
assembler, arm code?)
Sure, no problem running without an operating system, I do that kind of thing daily...
http://sam7stuff.blogspot.com/
You programs are, at least at first, not going to resemble desktop applications, I would avoid any libraries C libraries, no printfs or strcmps or things like that until you get the feel for it and find the right tools. No floating point as well. add some numbers do some shifting blink some leds.
codesourcery lite is probably the fastest way to get started, the gnueabi one I believe is the one you want.
This winarm site has a compiler and tons of non-os projects for seems like every arm based microcontroller.
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/
Atmel is very very good about information, no doubt they have example programs you can try as well on the eval board.
emdebian is another cross compiler that is somewhat up to date and has binaries. building a gcc from scratch for cross compiling is not bad at all. The C library is another story though, and even the gcc library for that matter. I find it easier to do without either library.
It is possible get a C library working and run a great many kinds of programs. Depends on what you are looking to do. Ahh, just looked at the specs, that is a pretty serious eval board, plenty of power for an operating system should you choose to run one. You can certainly run programs that use the display as a user interface. read/write sd cards, usb, basically everything on the board, without an os, if you choose.
I'm wondering how to create a minimal virtual machine that'll be modeled after the Intel 16 bit system. This would be my first actual C project, most of my code is 100 lines or less, but I have the core fundamentals down, read K&R, and understand how things ought to work, so this pretty much is a test of wits.
Could anyone guide me in as far as documentation, tools, tutorials, or plain old tips/pointers on how to go about this, thus far I understand that I require somewhere to store data, a CPU of sorts and some sort of mechanism that functions as an interrupt controller.
I'm doing this to learn: Systems internals, ASM internals and C - three facets of computing that I want to learn in a singular project.
Please be kind enough not to tell me to do something simpler - that would only be annoying. :)
Thanks for reading, and hopefully writing!
Virtual machines fall into two categories: those that interpret the code instruction at a time and those that compile the code to native instructions (e.g. "JIT").
The interpretation category is usually built around an instruction execution loop, using a switch statement, computed gotos or function pointers to determine how to execute each instruction.
There is a fun platform that is worth studying for its simplicity and fun: Corewars.
Corewars is a programming challenge game where programs written in "Redcode" run on a MARS VM. There are many MARS VMs, typically written in C.
It has also inspired 8086-based versions, where programs written in 8086 assembler battle.
Well, for starters I would pick up a reference book for assembly language for the processor you intend to virtualize, like 80286 or similar.
For a JIT, you might want to dynamically generate and execute x86 code.
If you want to write a Virtual Machine using the x86 VMM technology you will need quite a bit of things.
There are a few instructions that are critical such as VM_ENTER/VM_EXIT (name can change depending on the chip, AMD and INTEL use different names but the functionalities are the same). Those instructions are actually privileged and therefore, you will need to write a kernel module to use them.
The first step for your VM to start is to boot it and therefore, you will need a 'BIOS' which will be loaded. Then you need to emulate devices, etc. You could even run an old version of MSDOS in such a VM if you wanted to.
All in all, it clearly isn't trivial and requires a lot of time and effort.
Now, you could do something similar to what VMWare used to do before the Virtualization ready CPUs appeared.