GNUPro Development, v850

Hello,

I am new to GNUPro development. I am trying to create a very simple test program (just setting an output pin to high) for the NEC v850ES (?PD70F3718). Unfortunately I have troubles getting the code to run.

I was able to compile the v850 toolchain for a windows host. I used the following command:

/src-cross/configure --host=i686-pc-cygwin --target=v850-elf

--prefix=/project/install -exec-prefix=/project/install/H-i686-pc-cygwin

The compilation and installation process of the tool chain worked very fine. Then I compiled my test program and converted the outcome to .hex with the following commands:

v850-elf-gcc -Wall -mv850e test.c -o test

v850-elf-objcopy -O ihex test test.hex

In a next step I uploaded the .hex file with my NEC Minicube flash programmer. Unfortunately the hardware is not doing anything.

My questions are:

1) Is there any sample "workspace" for the NEC v850 available where I can start? I read a lot of articles, news group postings etc. . I am not sure how to configure crt0, makefiles, gcc, linker scripts correctly for the v850. There are so many possible error sources, I am simply stuck. I didn't modify any of these files in my first attempts. Even if there is no complete sample workspace, a working makefile, crt0 or linker script file would help me a lot!

2) If there is no sample for the v850 available, are there some kinds of similar samples available you may recommend where I can start?

3) I noticed that my compiled hex file is loaded into the wrong flash segment. I modified this by adapting the objcopy command with the parameter --change-address. After this fix the code is loaded into the correct segment but the v850 is still not doing anything. In my opinion there is some kind of start-up problem relating to crt0 or linker scripts.

I would appreciate very much any little help!!

Best regards,

Norbert

Reply to
Norbert Druml
Loading thread data ...

What you probably need to do is pull the default linker script out of the build tree and modify it to match the memory layout of the specific chip you're using. Then, at least, you won't need to use the

--change-address command (which likely will corrupt your program).

Reply to
DJ Delorie

We use this - no problems at all:

formatting link

Reply to
bigbrownbeastiebigbrownface

schrieb im Newsbeitrag news: snipped-for-privacy@t11g2000yqg.googlegroups.com...

Hello,

thanks for your response. We already use this kind of software but our aim is to live without such expensive compilers.

Regards, Norbert

Reply to
Norbert Druml

In message , Norbert Druml writes

It seems to me you do have an expensive compiler now. Time == money and you are spending a lot of it now trying to get the compiler working,.

"Expensive" compilers like the IAR install and work out of the box.

"Expensive" compilers like the IAR come with working examples.

"Expensive" compilers like the IAR have explicit support set up for most silicon variants

"Expensive" compilers like the IAR have application notes worked on by the Silicon company and the compiler company...

As PJ Plauger oft said " I can't afford free tools"

The cost of an engineer to a company is about 60 GBP or 90USD per hour... If it takes you more than a week to set up the compiler and get some examples and get them working the IAR compiler would have been less expensive for that alone.

That is without going into efficiency and compactness of the code.

There is also a support line for the IAR compiler that is a little more efficient than the GCC one you are on now.

Regards Chris

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

To be fair, if he has the GNUPro compiler, he should already know about the support line for it - the Red Hat Global Engineering Services group, where I work. Not free, but you get what you pay for. (if anyone wants details, you know where to find me ;)

Perhaps you're thinking of a toolchain built from the FSF sources? That would meet the criteria you give, but the GNUPro toolchain has everything you claim the IAR toolchain has. The big difference is that you can share the GNUPro software with your friends and co-workers without being sued.

Do you have publishable third-party benchmarks to back this up?

Reply to
DJ Delorie

How about when the IAR compiler dongle stops working, and you lose access to your own projects? And the only versions that will run on your current machines can't compile the old code?

How much does it cost a company when they lose the ability to modify their own software?

And when I last tested them, I found that gcc produced more compact code (on ARM) than IAR.

--

John Devereux
Reply to
John Devereux

In message , DJ Delorie writes

Fair enough. So why hasn't he called you?

Again fair enough. IT seems GCC is a generic term meaning many different things.

For GCC but not YOUR GCC.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

Years ago, my dongle (not an IAR compiler this time) threw belly up. It took six weeks to send it to the US and get a working one back from the compiler vendor. How much does this kind of delay cost?

I swore that I'm not voluntarily going to use any dongled piece of software.

And, yes, I'm using GCC for both ARM's and AVR's without any extra problems whatsoever.

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

You get it replaced. Not a problem. (Same with other compilers AFAIK)

No you don't.

Much the same for any compiler including GCC.

How would that happen?

Of course you did.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

Why back to the US? We can get you back up and running with a temp license in an hour or so (during working hours) and swap out the dongle in a few days. You shouldn't loose more and an hour or so.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

The IAR Compilers I have used did not come with any examples that actually ran on any sort of actual hardware. They compiled, but that was it. One still had to go through the docs to find out how to modify the linker script to be applicable foe one's own hardware. These days they do have some examples for specific development boards, but so do GCC if one buys a development board with GCC support. How quickly one gets going on new hardware with IAR or GCC depends much more on one's experience with the particular tool than anything else. The IAR documentation for their less mainstream compilers were also MUCH worse than the documentation for their more mainstream compilers. This might have changed for the better, but I doubt it.

Regards Anton Erasmus

Reply to
Anton Erasmus

The problem was I changed my machine/configuration, then (later) found the dongle did not work. Their support never said that the dongle was faulty as such (but who knows?) just that it was likely incompatible.

Well, we did. In retrospect, I expect with enough effort I could have bought an older machine/os, reinstalled everything, jumped through all the hoops and eventually got things working. But by then I had already wasted many days with a newer version, we decided just to use the EPROM images we had. We put the effort instead into finishing the development of the new version of the product line, which used another platform.

But that is the funny thing. I would *expect* commercial software vendors to make sure their compilers run on all environments without problems. But they *don't*. And gcc does! It is very tolerant, you can run it on linux, windows, under emulation/virtualization, old systems and new. Even different host CPU architectures.

As above.

I tried an application that had a particularly critical inner loop, on IAR, Keil and gcc - last year I think. Keil tied with gcc, IAR was about 50% more instructions. Not representative of anyone elses application perhaps, but true nonetheless.

--

John Devereux
Reply to
John Devereux

Well, he might be one of the friends or co-workers who got a free shared copy and isn't entitled to support from us. He could buy it if he wanted, but he isn't required to. I did try to help him out a little here anyway.

Yup. We check version numbers and such when we get support tickets so we know which "gcc" (it's really more than just gcc) we need to look at. Performance varies *widely* across versions and distributions, and our gcc won't perform exactly the same as any FSF release.

Reply to
DJ Delorie

Ok so you have no real idea what the problem is. But lets just slag off IAR anyway.

So they weren't ion ascii but some strange format that nothing else would read?

Sounds somewhat confused to me. But blame IAR anyway. I don't suppose you being a FOSS devotee has anything to do with you automatically blaming a commercial compiler for everything?

You would have the same problem with any other compiler. Unless GCC hasn't changed since day 1 (remembering that they did a complete change of most of it in the past.)

BUT THEY DO they run on all platforms that there is any serious interest in.

And?

You automatically blames the compiler for no real reason as far as i can see.

Ok. Fair enough

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

Maybe now, but it did not work then, and one time is one time too much.

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

*They* said it was the dongle. In fariness they *were* good enough to supply a later version of the compiler that would run - but this would not compile my code.

Nothing else would *compile* it.

It is very much the other way around: Having had these problems with a commercial compiler may have had something to do with me *becoming* a "FOSS devotee".

Not that I would actually call myself that. Although as time goes on I do seem to be tending towards it. The free software I use just seems to get better and better, with the commercial stuff getting worse and worse. (Not talking about compilers particularly here).

I can still compile the gcc projects I did 10 years ago. It took a lot less than 10 years for the IAR compiler to become "unsupported".

I will be able to run all my old gcc stuff until the end of time - with virtualisation of complete environments if neccessary, although so far that has not been needed (I guess the Linux ABI for command line tools is pretty stable). But in any case commercial compiler vendors go out of their way to make sure that is impossible.

[...]
--

John Devereux
Reply to
John Devereux

... snip ...

I suspect that is simply the use of standard C for gcc code.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

... snip ...

Are you denying that IAR supplied, and required, the dongle?

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

Well, standard "gcc C" :)

But I think it is more to do with being a command line tool that only requires minimal, standardized OS support. And in particular it does not try to access dongle hardware that has specifically been designed to be incapable of abstraction or emulation.

--

John Devereux
Reply to
John Devereux

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.