PIC16f648a

Simon - have you ever done a firmware make for the PIC16f648a? The old
SDCC version we currently use doesn't support that, but later ones do,
I think. Do you know which one to go for?

If so I think we should switch permanently - there's more room (which
should free up more space for the comms software), they should be pin
compatible in the PCBs, and they are no more expensive.

Best wishes

Adrian

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

Adrian Bowyer wrote:
> Simon - have you ever done a firmware make for the PIC16f648a? The
> old SDCC version we currently use doesn't support that, but later ones
> do, I think. Do you know which one to go for?
>
> If so I think we should switch permanently - there's more room (which
> should free up more space for the comms software), they should be pin
> compatible in the PCBs, and they are no more expensive.

Sorry for the slow response. I've been very tied up and probably will
be until the end of the month.

I was testing the new version of the comms using PIC16F648a. I still
have code bloat issues (amongst others) with the new sdcc though which
is why I've been putting that on hold a little and I'm focusing on
finishing the Java comms which is still missing some important
functionality. As a consequence of missing that functionality, we
temporarily added some nasty nasty hacks and none of that helps the
reliability. If that is finished, and we make a few small mods to the
existing comms, it will be almost as robust as the better designed new
comms system but will be smaller and simpler. It's a slightly tricky
tradeoff.

In any case, the 16f628 should be sufficient if we go with this simpler
approach. Using the 16f648 and new sdcc/new comms may be okay too, but
it needs more work. I haven't tested using new versions of sdcc with
the current comms system. Has anybody else done that? Given some of
the changes I needed to make to get the new comms system building, I'm
pretty sure it won't build directly with the latest sdcc. When I have
some time again, I can look into doing a port of the current code to the
latest sdcc if nobody else has already done it -- I've learned a few
useful things for the latest sdcc now.

All the above aside (imo) the 16f648 would really be preferable because
it gives people's machines a greater upgrade potential. If we switch to
the latest sdcc, it may also be essential to switch to the 16f648 given
the code bloat.

But depending on how quickly we want to release, it may pay to stick to
the 16f628 and old sdcc for now and switch to the 16f648 (or something
else) and the latest sdcc for the next version (?).


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

Quoting Simon McAuliffe :

> All the above aside (imo) the 16f648 would really be preferable because
> it gives people's machines a greater upgrade potential. If we switch to
> the latest sdcc, it may also be essential to switch to the 16f648 given
> the code bloat.

That's what I was thinking.

> But depending on how quickly we want to release, it may pay to stick to
> the 16f628 and old sdcc for now and switch to the 16f648 (or something
> else) and the latest sdcc for the next version (?).

Yes - I can't get our existing code to compile for the 16F648 using the
latest sdcc. It barfs at the line

BIT_AT(PORTA_ADDR, 0) PORTA0;

in pic14.h claiming to have found an illegal character (0x05), which
sounds like some sort of text buffer overrun to me (I did grep for 05
in a hex dump of pic14.h to make sure sdcc was lying - paranoia, or
what?).

Best wishes

Adrian

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

Adrian Bowyer wrote:
> Yes - I can't get our existing code to compile for the 16F648 using the
> latest sdcc. It barfs at the line
>
> BIT_AT(PORTA_ADDR, 0) PORTA0;
>
> in pic14.h claiming to have found an illegal character (0x05), which
> sounds like some sort of text buffer overrun to me (I did grep for 05
> in a hex dump of pic14.h to make sure sdcc was lying - paranoia, or
> what?).
>

Yes. The way you do some of those bit bashing things changed slightly
in the latest sdcc. I fixed it for the new comms code, so it's quite
easy to change. It shouldn't be difficult at all to make those same
changes to the current firmware and be able to build under the new
sdcc. It's all just time...

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

Quoting Simon McAuliffe :

> Adrian Bowyer wrote:
>> Yes - I can't get our existing code to compile for the 16F648 using the
>> latest sdcc. It barfs at the line
>>
>> BIT_AT(PORTA_ADDR, 0) PORTA0;
>>
>> in pic14.h claiming to have found an illegal character (0x05), which
>> sounds like some sort of text buffer overrun to me (I did grep for 05
>> in a hex dump of pic14.h to make sure sdcc was lying - paranoia, or
>> what?).
>>
>
> Yes. The way you do some of those bit bashing things changed slightly
> in the latest sdcc. I fixed it for the new comms code, so it's quite
> easy to change. It shouldn't be difficult at all to make those same
> changes to the current firmware and be able to build under the new
> sdcc. It's all just time...

Yes - I know how it is. Can you email me a copy of your example .h
file, and I'll see if I can take a look?

Best wishes

Adrian

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