sdcc compilation

one of the problems i had to overcome with getting sdcc up and running is this:

make[3]: Entering directory `/home/iowa/reprap/trunk/reprap/firmware/sdcc-build/sdcc/sim/ucsim'
g++ -g -O2 -gstabs+ -g3 -pipe -I. -Wall -I. -I./sim.src -Icmd.src -Igui.src -c pobj.cc -o pobj.o
cmd.src/newcmdcl.h:127: error: extra qualification 'cl_console::' on member 'clone_for_exec'
make[3]: *** [pobj.o ] Error 1
make[3]: Leaving directory `/home/iowa/reprap/trunk/reprap/firmware/sdcc-build/sdcc/sim/ucsim'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/iowa/reprap/trunk/reprap/firmware/sdcc-build/sdcc/sim/ucsim'
make[1]: *** [sdcc-misc] Error 2
make[1]: Leaving directory `/home/iowa/reprap/trunk/reprap/firmware/sdcc-build/sdcc'
make: *** [/home/iowa/reprap/trunk/reprap/firmware/sdcc/share/sdcc/include/pic] Error 2

i solved it by changing the file sdcc-build/sdcc/sim/ucsim/cmd.src/newcmdcl.h on line 127 from:

virtual class cl_console *cl_console::clone_for_exec(char *fin);

to

virtual class cl_console *clone_for_exec(char *fin);

i have no why that change worked, but it did. would someone like to help out and re-phrase this in a way that we can send it to the sdcc developers and get it integrated with their stuff.

for example, i dont know what version of sdcc we're using, etc. in the meantime, i'm adding this to the firmware compilation info page. if/when it gets fixed, then i'll remove it.

RepRap Forum Mailer wrote:
> Author: ZachHoeken
> Username: ZachHoeken (74.9.71.138)
> Subject: sdcc compilation
> Forum: Developers
> Link: [forums.reprap.org]
> Approved: Yes
>
> one of the problems i had to overcome with getting sdcc up and running is this:
>
> make[3]: Entering directory `/home/iowa/reprap/trunk/reprap/firmware/sdcc-build/sdcc/sim/ucsim'
> g++ -g -O2 -gstabs+ -g3 -pipe -I. -Wall -I. -I./sim.src -Icmd.src -Igui.src -c pobj.cc -o pobj.o
> cmd.src/newcmdcl.h:127: error: extra qualification 'cl_console::' on member 'clone_for_exec'
> make[3]: *** Error 1
> make[3]: Leaving directory `/home/iowa/reprap/trunk/reprap/firmware/sdcc-build/sdcc/sim/ucsim'
> make[2]: *** Error 2
> make[2]: Leaving directory `/home/iowa/reprap/trunk/reprap/firmware/sdcc-build/sdcc/sim/ucsim'
> make[1]: *** Error 2
> make[1]: Leaving directory `/home/iowa/reprap/trunk/reprap/firmware/sdcc-build/sdcc'
> make: *** Error 2
>
> i solved it by changing the file sdcc-build/sdcc/sim/ucsim/cmd.src/newcmdcl.h on line 127 from:
>
> virtual class cl_console *cl_console::clone_for_exec(char *fin);
>
> to
>
> virtual class cl_console *clone_for_exec(char *fin);

I just solved it yesterday by commenting the line out - that seemed to
work too...

We do have a bit of a problem in that the sdcc that's known to work and
that we download is quite an old one, so no one is likely to do a lot of
fixing of it. And - as the compile tools move on - it starts to suffer
from bit rot.

Simon said something a while ago about updating everything to a more
recent sdcc. Apart from anything else, I have never managed to get the
16F628A to work with the one we're using, so I'm sticking with the
16F628 for the moment.

--

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

That's very strange. Way back towards the first quarter of last year when I was trying to get bipolar steppers to work with what was then the stripboard controller design I was using Simon's binaries. I used the JDM programmer board and, I can't remember what the name of it was, software to drive it. I ordered 16F628A's instead of 16F628's because I was assured by the vendors that they were functionally the same, but re-engineered to be cheaper to produce.

In any case, while I had a lot of trouble getting the bipolars to build up enough speed to be useful there was never, that I recall, a problem with Simon's binaries actually working in the 16F628A's.

that really sucks. i bought a bunch of 16F628A's with the impression that those would work. i guess i'll order some of the 16F628 ones and see if those work.

this whole firmware has been a huge frustration... i really hope that we can get it sorted out soon. this is an area where standardization is something we badly need. i'm ready to order boards and now i find out that we dont even know what chip to use? that makes me very nervous.

this is why i think we need maintainers of specific areas. someone to say: this chip and this firmware will work for this board. having so many variables up in the air just makes it seem unmanageable at times.

hopefully when i get my new programmer, things will all fall into place and just work.

Forrest had no trouble with the 16F628A, so the problems could have been
me. To be fair, all the wiki pages say 16F628 consistently.

RepRap Forum Mailer wrote:
> that really sucks. i bought a bunch of 16F628A's with the impression that those would work. i guess i'll order some of the 16F628 ones and see if those work.
>
> this whole firmware has been a huge frustration... i really hope that we can get it sorted out soon. this is an area where standardization is something we badly need. i'm ready to order boards and now i find out that we dont even know what chip to use? that makes me very nervous.
>
> this is why i think we need maintainers of specific areas. someone to say: this chip and this firmware will work for this board. having so many variables up in the air just makes it seem unmanageable at times.
>
> hopefully when i get my new programmer, things will all fall into place and just work

I use 16F628A. I'm pretty sure I already said it, they are the same as
16F628 in terms of software.

Adrian, did you mean you couldn't get the same code to work on those
chips, or we you referring a build issue when specifying 16f628a on the
command line?

The 16f628/16f628a was "standardised" quite some time ago.

We will be distributing binary firmware files.

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

cool. good to hear that from an authoritative source.

i put a quick script into the svn directory called 'make_release' that is intended to streamline the process of creating .zip files of releases. right now it only supports the firmware.

i was trying to think of a way to do the java stuff as well as the STL files. unfortunately i dont know how to get the java to compile to its equivalent of a binary format, and there is no commandline stuff you can do with AoI.

it seems like for now, the best course of action would be to have separate releases for the java, firmware, and object files. what is the status of the firmware files? if possible, i'd like to get a v0.1 preliminary release out there in the wild for people who are experimenting. same goes for the java and object files.

I think it must be in the programmer. I've just tried it again:

If I program extruder.hex into a 16F628 it works.

If I program the same file under identical conditions into a 16F628A I
just get comms errors.

If I program the same file into a 16F628A, but telling gpicp beforehand
that I have a 16F628A, I just get comms errors.

In all cases the gpicp "Verify" option says everything is fine.

I have a Warp 13a programmer. I'll try it on the official Microchip
programmer at work tomorrow...

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]

Quoting Simon McAuliffe :

> RepRap Forum Mailer wrote:
>> that really sucks. i bought a bunch of 16F628A's with the
>> impression that those would work. i guess i'll order some of the
>> 16F628 ones and see if those work.
>>
>> this whole firmware has been a huge frustration... i really hope
>> that we can get it sorted out soon. this is an area where
>> standardization is something we badly need. i'm ready to order
>> boards and now i find out that we dont even know what chip to use?
>> that makes me very nervous.
>>
>> this is why i think we need maintainers of specific areas. someone
>> to say: this chip and this firmware will work for this board.
>> having so many variables up in the air just makes it seem
>> unmanageable at times.
>>
>> hopefully when i get my new programmer, things will all fall into
>> place and just work
>
> I use 16F628A. I'm pretty sure I already said it, they are the same as
> 16F628 in terms of software.
>
> Adrian, did you mean you couldn't get the same code to work on those
> chips, or we you referring a build issue when specifying 16f628a on the
> command line?
>
> The 16f628/16f628a was "standardised" quite some time ago.
>
> We will be distributing binary firmware files.
>
> _______________________________________________
> Developers mailing list
> Developers@reprap.org
> [reprap.org]
>



_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

what sorts of comms errors are we getting? perhaps that is something we can fix in the firmware itself? from what i gather, the 16F628A chip is superior, right?

Quoting RepRap Forum Mailer :

> what sorts of comms errors are we getting? perhaps that is something
> we can fix in the firmware itself? from what i gather, the 16F628A
> chip is superior, right?

As I understand it, the superiority is in its internal design. It
ought to be functionally equivalent. I'll know more after today's
experiments.

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Result of experiment:

As you'd expect, Simon's right. It is something funny about the combination of my PIC programmer and the 16F628A that is causing my problems.

I took a 16F628A, put it in a Microchip Picstart+ programmer, and used Gpicp to program it with our standard extruder.hex file. Then I plugged it into an extruder, and it worked perfectly.

So - as far as I can tell, the 16F628A is fine.

I think I need to buy a new programmer...

I shall check out:

[ajpic.zonk.pl]

of which there are good reports.


Best wishes

Adrian

Dr Adrian Bowyer
[people.bath.ac.uk]
[reprap.org]

yeah, unfortunately i found out about that one after i bought a new one from sparkfun. it runs off external power, so hopefully it will work well for me.

[www.olimex.com]

i cant wait until we get a pic programmer that operates inline with our boards. should be pretty rad.

RepRap Forum Mailer wrote:
> Author: ZachHoeken
> Username: ZachHoeken (74.9.71.138)
> Subject: Re: sdcc compilation
> Forum: Developers
> Link: [forums.reprap.org]
> Approved: Yes
>
> yeah, unfortunately i found out about that one after i bought a new one from sparkfun. it runs off external power, so hopefully it will work well for me.
>
> [www.olimex.com]
>
> i cant wait until we get a pic programmer that operates inline with our boards. should be pretty rad.

It's worth investing a few $$$ in a zero-insertion-force socket for
these things incidentally - makes programming chips a lot easier.

--

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Amen!

I've done a few more experiments with a proper PIC programmer. Results:

If you compile all the RepRap firmware as for a PIC16F628 (i.e. the
standard as in the distribution) you can then program the resulting
.hex file into a PIC16F628, a PIC16F628A and a PIC16F648A and they all
work.

I was using gpicp, and each time I told it that it had the actual PIC
type that was plugged into the programmer it was driving. That is to
say sdcc thought it was making .hex files for the PIC16F628, but all
the subsequent steps after the creation of the .hex files used the
actual device identifier.

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

I too have been using 16F628A's with no problem, though admittedly not driving the current board design.

Vik :v)