go_away

Author Topic: c++ robot code  (Read 7963 times)

0 Members and 1 Guest are viewing this topic.

Offline JesseWelling

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 707
  • Helpful? 0
  • Only You Can Build A Robot!
Re: c++ robot code
« Reply #30 on: March 21, 2008, 08:04:47 PM »
i dont think c++ compilers for mcus are in this world
i did some search and ,,nada


http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus

Offline superchiku

  • Supreme Robot
  • *****
  • Posts: 953
  • Helpful? 5
  • cooll
Re: c++ robot code
« Reply #31 on: March 21, 2008, 10:55:26 PM »
well just use C coz thats the only thing u can do
JAYDEEP ...

IT AND ROBOTICS ENGINEER

"IN THE END IT DOESNT EVEN MATTER"

Offline benji

  • Supreme Robot
  • *****
  • Posts: 832
  • Helpful? 0
Re: c++ robot code
« Reply #32 on: March 22, 2008, 05:06:40 AM »
Quote
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus


is this only some libraries you add to your own compilers or is it a complete compiler?
can you please post the link to download this thing
good ol' BeNNy

Offline JesseWelling

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 707
  • Helpful? 0
  • Only You Can Build A Robot!
Re: c++ robot code
« Reply #33 on: March 22, 2008, 11:50:07 AM »
http://winavr.sourceforge.net/

Or if you use Debian based Linux just do this:
Code: [Select]
apt-get install gcc-avr
« Last Edit: March 22, 2008, 11:57:36 AM by JesseWelling »

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,121
  • Helpful? 108
Re: c++ robot code
« Reply #34 on: March 22, 2008, 12:56:09 PM »
As per all the discussions about structures - well said - that's how C++ works. Early C++ compilers used to work by turning all your code into C and then compiling that. So when it comes to memory overhead then the size of an object instance is just the size of the structure used to store its variables. Each class, ie 'Motor' has one vtable to handle the overridable methods irrespective of the number of instances of Motor you create. So the argument about memory differences between C++ and C just don't stand up. Equally comments about running multiple threads are also irrelevant - if you want to have multiple threads then you could do this in assembler, C, C++, Java etc. Its not a problem with the programming language you choose - its down to whether you want/need to have multiple threads in the first place. If C++/Java make it easier to do so then it doesn't mean you have to use this facility. OK- things like Java often have background threads to help manage the heap space but since you wont be using lots of <code>new(Thing)</code> then this isn't a problem - and is probably why a lot of the mcu compilers don't support <code>new</code> - so that they can save all the overhead of managing the heap. But surely thats the same in C as well - just try using the C <code>malloc</code> command and see how much support you get.

Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline JesseWelling

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 707
  • Helpful? 0
  • Only You Can Build A Robot!
Re: c++ robot code
« Reply #35 on: March 22, 2008, 01:58:00 PM »
Exactly why you make an instances.c and an instances.h

Essentially in an embedded environment you should already know how many instances of an object you need. For example, you should never have to dynamically add sensors, or motors, or servos at run time.

Offline Tsukubadaisei

  • Robot Overlord
  • ****
  • Posts: 293
  • Helpful? 0
Re: c++ robot code
« Reply #36 on: March 23, 2008, 06:15:09 AM »
i dont think c++ compilers for mcus are in this world
i did some search and ,,nada

Actually they exist and are popular in the professional world: Look for FreeScale.


Essentially in an embedded environment you should already know how many instances of an object you need. For example, you should never have to dynamically add sensors, or motors, or servos at run time.
When it comes to robot hardware you are right but when it comes to interactivity with the environment you might not know how many variables are out there. Last year I did some experiments by connecting my umpc to a microcontroller. The controller was nothing but an interface between the robot hardware and the umpc. then I connected I camera and used Artoolkit to make the robot scan the environment and collect random small objects(that I choose) in my room. I programmed the umpc in C++ and every single object the robot identified (from my bed to a piece of paper) became an object. Then I had a methods for each one of those objects to compare them to the target objects. And finally I had a separated set of methods(outside a class) for serial communication between the umpc and the controller. Unfortunatelly I am still working with the comparation algorithm(there are so many angles). Whatever, it is just some nerdy project that I work when I have too much spare time. My point is that C++ is a great language for robotics. I think C# would be even better but it is only for windows and it is still way too heavy for the usual one-chip mcu(that is because I like C# syntax the most). C is still great. You can "pretend" that you are using c++ and oop by structures and functions related to those structures(I do that quite a lot).
« Last Edit: March 23, 2008, 06:38:13 AM by Tsukubadaisei »
A.I.(yes those are my initials)

Offline JesseWelling

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 707
  • Helpful? 0
  • Only You Can Build A Robot!
Re: c++ robot code
« Reply #37 on: March 23, 2008, 09:59:18 AM »
Well if you need dynamic memory you are going to have to use a chip with memory management. That pretty much goes without saying. I think you are correct that C++ is probably the best compromise between performance and ease of use for robotics on the higher level.

My thoughts on C# are that the syntax is ok, it's just about the same as Java so no big deal there. But I personally detest using any language that does Garbage Collection. I think it's the biggest crutch that was ever made.

But I'm strange like that  :P

Offline benji

  • Supreme Robot
  • *****
  • Posts: 832
  • Helpful? 0
Re: c++ robot code
« Reply #38 on: March 23, 2008, 04:04:14 PM »
Quote
Actually they exist and are popular in the professional world: Look for FreeScale.

Freescale is a company,can you provide the link to that compiler?
is it a reliable one?efficient in using mcu memory?
good ol' BeNNy

Offline benji

  • Supreme Robot
  • *****
  • Posts: 832
  • Helpful? 0
Re: c++ robot code
« Reply #39 on: March 23, 2008, 04:12:17 PM »
anyways if you guys are interested to make it easier for you to program processors u gorra check the matlab embedded toolbox
,it has a toolbox to compile matlab code into machine code,,
matlab programming is awesome,,compared to lots of languages ,including c++.
still not sure if this toolbox supports avr and 8051 cores mcus
i think its basicly made for DSPs
good ol' BeNNy

Offline JesseWelling

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 707
  • Helpful? 0
  • Only You Can Build A Robot!
Re: c++ robot code
« Reply #40 on: March 23, 2008, 05:37:31 PM »
Yea they tell us at work that Matlab and model based design are the wave of the future.
I don't buy that either. It's a performance sink in a big way. We have a division that only uses model based design and they use the same processor that we use, except we have nearly 5 applications to their one per processor. It may be better for rapid prototyping or limited production solutions (such as hobby robotics) but I don't think it's really going to take off that much in the industry.

I'm not meaning to be contrary though... if you like it, use it.

Offline Tsukubadaisei

  • Robot Overlord
  • ****
  • Posts: 293
  • Helpful? 0
Re: c++ robot code
« Reply #41 on: March 24, 2008, 02:45:41 AM »
Quote
Actually they exist and are popular in the professional world: Look for FreeScale.

Freescale is a company,can you provide the link to that compiler?
is it a reliable one?efficient in using mcu memory?

It is a company. A famous one. And they have c++ compilers for their micro controller. But you have to buy them. Honestly you should at least do some research first.

Quote
My thoughts on C# are that the syntax is ok, it's just about the same as Java so no big deal there. But I personally detest using any language that does Garbage Collection. I think it's the biggest crutch that was ever made.

That is my problem with c# as well. Garbage collection is garbage. But the code is easy to read and write though(and I like intelisense, it is a nice feature). I use it (and Java) for quick prototyping or small programs(usually not related to robotics). But only for that.
« Last Edit: March 24, 2008, 02:50:56 AM by Tsukubadaisei »
A.I.(yes those are my initials)

Offline benji

  • Supreme Robot
  • *****
  • Posts: 832
  • Helpful? 0
Re: c++ robot code
« Reply #42 on: March 24, 2008, 11:59:45 AM »
well its not model based design nesecerally
i was talking about the matlab programming language
it provide real ease compared to the others
adding to that that the basic element in matlab is a matrix
which is what commonly used in robotics
good ol' BeNNy

Offline paulstreats

  • Supreme Robot
  • *****
  • Posts: 1,381
  • Helpful? 21
Re: c++ robot code
« Reply #43 on: March 24, 2008, 06:31:45 PM »
Does anybody have any opinions on how large a return stack should be kept?

Im in the process of writing an interrupt based kernel in 99% c. This involves copying the hardware return stack to memory. The stack is usually 31 levels deep allowing for nested functions, if conditionals, while loops etc.. of up to 31 levels.

Each thread must have its own software based return stack (stored in an array) to remember where it is upto when its thread yields to another one. So when the thread yields, the program counter is copied to the top of the hardware stack. The entire hardware stack is copied into the threads own software stack array. When the thread is allowed to resume, its software stack array is copied back into the hardware return stack and a return command pushes the top level of the hardware stack back into the program counter so it resumes from the position the thread yielded it.

The threads are interrupted when timer0 overflows. This is when the hardware stack is copied. It allows all threads to run for 256 clock cycles before yielding (it can be altered by setting divisors if necessarry). The timer1 module is used to set priorities and that thread will not resume until its defined priority is equalled or exceeded based on timer1 (this is controlled by a simple process scheduler).

The problem involved in this is that it means that to allow for the maximum 31 level returns, each thread must have three arrays as such: ubyte[31] hbyte[31] lbyte[31] because the stack is 3 bytes wide by 31 deep. That means each thread uses 93 bytes of ram before its actually used to do anything. The uc (pic18f4520) im using allows 1536 of ram, but its soon going to get used up with a few threads and typedef and variables.

Obviously the memory usage of the threads can be greatly reduced by only allowing a return stack of 10 levels. I cant think of any time lately that ive gone above 5 levels deep in returns which brings me back to the question above.

What does everyone think is acceptable for nesting depth?

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,121
  • Helpful? 108
Re: c++ robot code
« Reply #44 on: March 24, 2008, 10:15:37 PM »
How long is a piece of string...

This will depend on the maximum nesting of subroutine calls in your main code. Ifs/whiles etc should make no difference.

BUT the other thing is that all variables declared locally within the methods/subroutines will normally also be allocated within the stack. There will also normally be an overhead per nested level of subroutine where several key registers are pushed/popped. The exact implementation will vary from one compiler to the next.

Consider:
Code: [Select]
void mySubroutine(void){
    char buffer[256];
    do something;
}

The
Code: [Select]
buffer variable space may be allocated on the stack or it may be allocated on a separate virtual heap stack tracked via some other register.
Also if your subroutine has parameters that are passed by value, rather than as a pointer to the original values, then these are normally also copied to the stack.
ie
Code: [Select]
void mySubroutine(char *args){
  do something
}
will just pass the address of the original array of data but
Code: [Select]
void mySubroutine(char args[256]){
    do something
}
may well copy 256 bytes of info to the stack.

If you are not careful you will spend most of your time copying stuff in and out of the stack rather than running the code.

Rather than copying stack contents into C variables ie ubyte[31] you may be better off thinking about how many tasks there would be (maximum) and then chopping up the stack space yourself. Look at the generated assembly code to see how the stack is managed and then swap the contents of the stack register when you swap tasks. ie dont modify the contents of the stack, rather change the actual stack pointer itself to a unique location for each thread. Most C compilers will also keep variables for the top and bottom of the stack (to detect stack overflows)  so you would also need to change the contents of these variables yourself at each task switch so that a given task works within the subset you have given it. If you dont do this then if one stack gets bigger than expected it will overwrite the stack for another thread without you knowing until you switch to that tasks and it crashes horribly. If you do it properly then you should get the standard C stack-overflow messages.

This is much more efficient as you can swap tasks by changing a register and a system wide variable or two (irrespective of how big the stack actually is). But it does involve you understanding exactly the assembler that is generated by your C compiler and then adding some assembler code to do the switching. Look at the symbol/map files - as they may also help located where some of this info is stored.

I did this about 15 years ago for a commercial application in MSDOS  for IBM cash registers monitoring multiple petrol pumps - it is possible - can be very efficient - but requires some in-depth jiggery pokery. If you dont have a good understanding of the processor architecture and assembler then you may find it a big challenge.

Good luck

Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline paulstreats

  • Supreme Robot
  • *****
  • Posts: 1,381
  • Helpful? 21
Re: c++ robot code
« Reply #45 on: March 25, 2008, 03:09:34 AM »
Ive already written it. (about 2hours writing code, about 100 hours researching and reading the datasheet and testing code snippets on the hardware stacks).

The hardware stack on the pic18 for return pointers is only 31 deep anyway so i dont think its large enough to just use pointer locations for many threads on it. I could implement a larger software stack (If i had some external sram fitted, It could be as large as that is) and just point to that, but then you hit the problem of 1 thread overflowing into another etc... I also have a couple of plans for communicating between threads and the global environment but I need to do a bit more work on this aspect (It needs to follow my object model). I think that each thread is going to have a corresponding struct ##name_global_variables.variable_name  and also variables that are private to the thread created with the ##name_1.

I need to do a lot of work on assigning extra functions to the threads, but this is likely to be fully pointer based.

I also decided before I went to bed that since the copied stack pointer is only 5 bits long, and im going to be using probably another 5 bits for interrupt priority settings then I can use the remaining 5 bits to select a return depth with 1 bit left over for some possible future boolean allocation(like thread_active). It just means having to configure the threads a bit more before they run. I'll post the code tomorrow when im sure that its working properly

Offline paulstreats

  • Supreme Robot
  • *****
  • Posts: 1,381
  • Helpful? 21
Re: c++ robot code
« Reply #46 on: March 26, 2008, 05:41:13 PM »
Here is the first version of my multi tasking system on PIC18's.
It only has 1 thread configured to run at the minute called logic_thread, im working on making defining threads easier, its priority driven with threads executing according to a priority set against the timer1 module. The timer0 module interrupts the thread after 256 instruction cycles and checks to see if any other threads are due to run. The threads will only run when their predefined priority time comes up, there is a priority of 0 that can be set so threads alsways execute when the scheduler gets to them. priorities go down to 31.

Each thread stores its return stack in software so when a thread is interrupted it stores where it was upto so when  its priority time comes up again it can carry on where it left off rather than starting from the top of its function.

Lessons learnt:-
Microcontrollers really need to interface to external ram. - im hopefully going to add this into my model

To make threaded systems that can be easily used by other people, you really need to develope a higher level precompiler that includes the usual c commands along with a few other bits. - the reason i decided to do this was because most other simple threaded systems seem to need you to insert extra bits in the threads to allow it to break out, the interrupt driven style that i have made needs nothing extra adding into your thread, it just takes a lot of setting up at the minute.

You can spend hours trying to find where the bug in your code is causing erratic behavior until you realise that the code simulator has a problem with the timer overflowing more than 8192 times?

Having to actually monitor memory stacks, return stacks, and sift through stupid amounts of assembly gives a much deeper understanding into how things work in the PIC

When at first you think that 1 thread has taken up an immense amount of memory, its time to check the memory usage gauge with a blank main.c document only to realise that an empty main file with just the P18f4520.h included takes over 300 bytes, and its not really that bad after all. If ever you start to run low on memory, maybe its time to sift through the standard header file used and make your own with only the things in it that you need.

This is an ongoing project which needs a lot of cleaning up yet, and maybe  think about making a higher level language to make objects threads easier to use....

 


Get Your Ad Here

data_list