headers
Mike Harrison | 3 Jul 19:25

[PIC] : hitech compiler - deliberately generating poor code in free version?

(posted before but forgot tag....)

WTF is going on with the Hi-Tech compiler that ships with MPLAB....
A few samples below  (all vars are global chars)., target 16F818

Can anyone think of any explanation for such poor code generation other than deliberately making it
slow to make their paid-for compiler look better ? 

It can't be doing Microchip any favours shipping such a poor performing compiler with MPLAB as it
makes their chips look slow and inefficient.  

365:               irrxsum1+=irbyte1;
   115    087A     MOVF 0x7a, W
   116    00C3     MOVWF 0x43
   117    0843     MOVF 0x43, W
   118    07F4     ADDWF 0x74, F

Should be 2 instructions

366:               ircnt1=0;
   119    1003     BCF 0x3, 0
   11A    3000     MOVLW 0
   11B    1803     BTFSC 0x3, 0
   11C    3001     MOVLW 0x1
   11D    00FB     MOVWF 0x7b

This is especially bizarre - should be 1 CLRF instruction

349:               irtmr1+=bittime2; // bittime2 is a constant
   0DF    300E     MOVLW 0xe
(Continue reading)

Permalink | Reply | 6 comments |
headers
Olin Lathrop | 3 Jul 14:02

Re: [PIC] using BREAK in 'C'

Gerhard Fiedler wrote:
>> As you can see the variables declared with 'const' are really static
>> (like the 'static' directive in C) while the ones with the 'var' are
>> 'auto' variables (aka sits on the stack).
>
> I find this at least not intuitive. I'd expect a const to be constant.

In the Pascals I am familiar with CONST defines compile time symbolic
constants only.  Certainly my version works this way, although it often
realizes these constants as static read-only variables.

Note that Tamas' code doesn't prove how exactly the compiler interpreted the
CONST symbols.  Either interpretation would have resulted in the same
output.  For that matter his code doesn't even prove the constants are
static if they are implemented as values in memory locations.  Since you can
only read them and then you always read the same value, you can't tell
whether you are reading a different memory location each time or whether the
compiler is substituting the symbol's value on the fly.

The only way to tell would be to take the address of a symbolic constant.
If you get a compile error, then its just a symbolic constant.  If it works,
then you still don't know whether the compiler created a literal only
because you asked for the address.  You can pass a symbolic constant to a
subroutine pass by reference parameter and see if the the address changes
with nesting level.  If so, then these things aren't variables at all since
the compiler is creating the argument anew each call.

It's very tricky to tell the difference, which also makes it so you don't
need to care in most cases.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Justin Richards | 3 Jul 12:48

[PIC]: PicKit2, MPLAB and OLIMEX_MAXI_WEB(18f97j60) programming target problems

Hi Folks,

I have successfully built my C code for the target OLIMEX_MAXI_WEB but I am
having problems with programming and debugging via the MPLABv8.20 IDE.

I understand that some devices are not supported directly by the IDE using
PicKit2 but I have checked the list and it indicated that the 18F97J60 is
supported directly for both debugging and programing.

I can successfully program the target using the PicKit2 software but fails
when I try it from the IDE.

The error I get is PK2Error0027 (verify failed).  I can confirm that the
device gets erased and I can read from the target (once it has been
programmed via PickKit2 software) via the IDE I just can not program it.

I have another device (pickit2 express debug board) that I can program and
debug successfully but this uses PicKit2 to provide target power supply
requirements whereas the OLIMEX_MAXI_WEB has its own power supply.

Usually I would just keep trying but I have tried 10 times to program, so I
figure that is 10 erases and the Manual for 18f97j60 indicates that it is
only good for approx 100.  Therefore I have reduced its usefulness
significantly and haven't really achieved anything.

I really need to get into debug mode and to do this I need to be able to
program from the IDE (I did try to program from PicKit2 software first and
then enter debug mode but this also fails).

If anyone has had success ICSP programming 18f97j60 or better yet the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Restall | 3 Jul 13:14

[OT] York Radio Rally


Morning all,

Anybody from the UK going to be at the York Radio Rally this weekend (Sunday) ?
I went last year and was a bit disappointed at the lack of trade stalls
there; hopefully this year will be better since there are fewer other events
on at the same time elsewhere in the country.

Regards,

Pete Restall
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 0 comments |
headers
solarwind | 3 Jul 02:17

[OT] First surface mount component

So today I soldered my first surface mount component - a PIC32 100 pin
TQFP package with 0.4 mm pin pitch. It was perfect.

I would post pictures, but unfortunately, my camera is damaged.

I did it with a simple radio shack soldering iron, liquid flux, copper
desoldering braid and a TQFP adapter board.

I first put liquid flux on the adapter board's pads with the flux
applicator pen. Then I placed and aligned the surface mount component
on the pad. This was the most difficult part.

I then put some tape on it so it wouldn't move around and soldered a
few pins to hold it down. Then on the opposite side I used the drag
solder & flood method (albeit easy on the solder) and continued the
rest of the way - all around the chip. Some pins were bridged - so I
took some handy copper desoldering braid (this stuff is awesome) and
dragged it across all the pins with the hot iron. The excess solder
was effortlessness absorbed and I was left with a cleanly soldered 100
pin 0.4 mm pitch TQFP component!

Some of you may believe that I tend to ask too many questions
regarding seemingly simple topics such as PCB etching or surface mount
soldering - but it helps - because I got it perfectly the first time -
no mess ups.

Interestingly enough, when I did my motorcycle insurance course, the
instructor assured me (and was willing to bet) that I would drop the
motorcycle since I had not driven one before (but had studied it
carefully beforehand). Needless to say - I didn't drop it at all - or
(Continue reading)

Permalink | Reply | 10 comments |
headers
cdb | 3 Jul 00:43

[OT]Supermarket sales blurb

 Aldi in Australia the supermarket that is liable to have a one off 
special purchase on cement mixers  whilst purchasing your brussel 
sprouts, has this electrobabble sales pitch for a pair of thermal 
underwear for next weeks Special Buys.

'The Herst anti-static treatment has been added to the Merino to 
reduce the bioelectrical fields so it's much less likely to cling to 
your body.' 

I wonder if this bioelectrical anti treatment is applied to the sheep 
(it's made from Merino wool hence the name) the garment or the wearer.

In fact as we now have electrosmog, which EU department would 'static 
cling' fall under? Should one need to buy a EMI approved licence to 
wear such clothes?

'Due to the interference caused by the crews underwear the RC control 
of the boat got jammed and the cruise ship went around in circle for 2 
days, unitl some one 'reset' the crew members'

Colin

--
cdb,  on 3/07/2009

--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olin Lathrop | 2 Jul 15:27

Re: [PIC] using BREAK in 'C'

Gerhard Fiedler wrote:
> I'm not sure I follow you. I at least never doubted that almost
> everything that can be done with C can be done with any reasonable
> Pascal dialect.

Others do seem to doubt it though.  One of the technical arguments that
several people have made here recently is that you can "do anything" in C,
implying you can't do it in other languages.

> (FWIW, I think the main thing that C has that's missing from even
> decent Pascal dialects is the precompiler.

I agree.  A preprocessor can be a powerful addition to any language.

> But you're talking about popularity, availability.

No, I'm specifically not.  I understand how C got where it is and that today
you have to use it regardless of technical merits.  The part I'm trying to
point out is that C sucks technically, because too many sheeple use C and
don't see a problem with that.  I'm not saying there is a handy solution
because I don't see one either.  But the realization that it would be nice
if there was one is something too many people haven't made yet, and that's
what I'm trying to get them to see.  There are still people in this world
that actually *like* C (and I don't mean in the business sense), as
evidenced by several of the responses here.

> This is the thing you seem to get confused. The reason why C is more
> popular has nothing to do with computer science concepts,

No, in fact I've been trying to point that out.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Rikard Bosnjakovic | 2 Jul 15:28

[EE] Constructing a PLL for MFM-reading

I'm going to extract raw-data from an old Amiga floppydrive without
using a floppy disk controller. That is, I'm reading the data-gate on
the floppy drive feeding it into a microcontroller and then perform
the MFM-decoding of the data myself.

There's not a lot of documentation available, but what I've been able
to dig out is this:

* How the MFM-data is laid out. The data itself is twice as large as
the actual data: '1' is encoded as 01, '0' is encoded as 10 (if
following a '0') or 00 (if following a '1'), according to the Amiga
Hardware reference manual. However,
http://au.geocities.com/redskulldc/transactor/disksys.pdf claims that
both data and clock bits are interleaved together in the stream, like
this:

  Number 18:    1   0   0   1   0
  Clock bits: 0   0   1   0   0
  MFM:        0 1 0 0 1 0 0 1 0 0

Extending this example to the number 89 I get this:

  Number 89:  1   0   1   1   0   0   1
  Clock:    0   0   0   0   0   1   0
  MFM:      0 1 0 0 0 1 0 1 0 0 1 0 0 1

I.e. the clock is not predeterminable (or whatever the word for it is).

* Each bitcell on the floppy is 2us big (or wide, or whatever you would call it)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Olin Lathrop | 2 Jul 15:00

Re: [PIC] using BREAK in 'C'

Michael Rigby-Jones wrote:
> I think you are missing Bills point.  Can you take the code you have
> just written and be sure it will compile and work on any arbitrary
> Pascal compiler?  Would you really want to have to have a diffierent
> implementaion of this code for each target you want to use it on?

That would be a relevant question if we were chosing a compiler from today's
available choices.  I was only pointing out that C is a really bad language
and used some examples based on Pascal to show there are other ways.  I'm
not advocating Pascal either, but its concepts are useful as counter
examples to C, especially since I'm pretty familiar with a language based on
those concepts.

> When I last used Pascal (a long time ago admittedly), I could find no
> way of defining static variables within a function, so end up using
> globals which is very ugly.  Has this situation changed?

There are several ways to define static variable.  One is to put variables
at the module level outside any function:

module xxx;

var
  ii: integer32;  {static variable with module scope}

procedure aaa;
begin
  end;

procedure bbb;
(Continue reading)

Permalink | Reply | 7 comments |
headers
Alan B. Pearce | 2 Jul 14:07
Favicon

[OT] I wouldn't be thinking about safety watching this ...

http://www.stuff.co.nz/travel/2560047/Body-painted-staff-now-deliver-safety-video

--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 2 comments |
headers
Jesse Lackey | 2 Jul 09:08

[EE] Potting boards...

(repost with [EE] tag.  sorry.)

Hello all, I have a client who wants to pot the board I'm making to make
it as indestructible as possible.

I haven't done this before, and wonder a few things.
Maybe someone would like to offer advice?

Heat.  The components being potted generate some heat, not a lot, and
there will be a heatsink of some sort on the underside of the board.
(only the top is being potted).  So I'm not too worried about this.

My main concern is what being potted may do the following component types:

Electrolytic caps: they have some sort of safety vent, right?  If
sealed, and should disaster occur somehow, I figure failing in potting
couldn't be any worse than failing in open air?

Inductors: I'm using 5 for dc/dcs, 4 of which handle significant current
(2amps) in pulses.  They get pretty warm.  I just wonder if the potting
compound could cause them to change behavior (inductance value, current
capacity) in a significant way, by possibly squeezing them a little when
it cures?  Seems unlikely, thought I'd ponder.

Crystal: there is a 10mhz xtal that needs to be reasonably accurate
(250K baud serial coming in), and I remember somebody here saying once
how potting a board made their xtal drift.  How problematic might this be?

Any advice appreciated.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane