Searching \ for '[PIC] 2 questions about 18f4550' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=18F
Search entire site for: '2 questions about 18f4550'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 2 questions about 18f4550'
2006\02\18@205955 by kerri

flavicon
face
Hi,

I have to questions about pic18f4550,

1. I have noticed that if I touch the top of the ic with my finger
the usb connection to my computer breaks. Is this normal?

2. Is it possible to write a firmware for the this pic that will listen
on all addresses (to enable to write a packet sniffer?)

thanks!!

2006\02\18@220957 by Peter Todd

picon face
On Sun, Feb 19, 2006 at 01:59:48AM -0000, kerri wrote:
> Hi,
>
> I have to questions about pic18f4550,
>
> 1. I have noticed that if I touch the top of the ic with my finger
> the usb connection to my computer breaks. Is this normal?

Not likely... Usually that means a digital IO line has been left
floating somewhere. Check that every single digital input, including
ones going to the PC, is definitively held in a valid state.

One example of this would be IO lines on your PIC that aren't being
connected to them. Either make sure they are set as outputs, or tie them
to V+ or ground through a 10k resistor.

It may be the case that the USB link needs "steering" resistors attached
to it. I'm no expert on USB, but for instance the I2C protocol needs
resistors attached to the bus to establish valid signal levels. If you
don't do this, things *may* appear to work, but will be very flaky.

--
spam_OUTpeteTakeThisOuTspampetertodd.ca http://www.petertodd.ca

2006\02\19@075150 by kerri

flavicon
face
> Not likely... Usually that means a digital IO line has been left
> floating somewhere. Check that every single digital input, including
> ones going to the PC, is definitively held in a valid state.
Hi,
Note I do not touch any of the pins, just the plastic top cover, did
you realise that? I'll check my tris registers to be sure. Also, it only
happens at one end (nearer to the notch), if I touch in the centre or
on the left side it is unaffected.

2006\02\19@105023 by Josh Koffman

face picon face
On 2/19/06, kerri <.....kerri1111111KILLspamspam@spam@btinternet.com> wrote:
> Note I do not touch any of the pins, just the plastic top cover, did
> you realise that? I'll check my tris registers to be sure. Also, it only
> happens at one end (nearer to the notch), if I touch in the centre or
> on the left side it is unaffected.

What's on the MCLR pin?

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2006\02\19@112225 by kerri

flavicon
face
> > Note I do not touch any of the pins, just the plastic top cover, did
> > you realise that? I'll check my tris registers to be sure. Also, it only
> > happens at one end (nearer to the notch), if I touch in the centre or
> > on the left side it is unaffected.
>
> What's on the MCLR pin?

MCLR is connected to the +5v via a 15k R, but I think there are a few
floating inputs, I need to connect them to +5v and check it again, I'll
let you know tonight.

2006\02\19@112427 by Bill & Pookie

picon face
If the chip was made in Katmandu, then the previous thread on pic list of
"shock the kitty" may apply.

Try probing it  with a non conducting object and see if same thing happens.
If it does maybe there is a bad solder joint or the chip needs to be removed
and reinstalled in it's socket.

Or the chip may be heat sensitive and your finger heats it.  A way to test
for this is to blow hot air from a hair blow drier or a heat gun on the chip
while it is running. Sometimes is helps to cool down a circuit or component.
Freezing your finger and then touching the parts is painful because of the
frost bite.  They make cans of "Freeze It" spray that will put frost on the
pumpkin.

Once you have found the part that works/don't work, when you heat/cool it,
then you have found the problem which  may have been an intermittent problem
and difficult to find any other way.

As a final test on a state of the art board where I once worked, we would
cover the board under test with 15 mm of sand and heat it with blow torches
to a cone 4.  Then with a CO2 fire extinguisher, we would blow the sand away
and make frost on the board.  If the board worked during this test, it would
pass and be put into the "Minnie the Moo Cow" Speak and Spell Computer.

If all else fails, "Don't Do That!". or put a finger shield over the chip.

Pookie

{Original Message removed}

2006\02\19@133242 by Howard Winter

face
flavicon
picon face
On Sun, 19 Feb 2006 08:24:24 -0800, Bill & Pookie wrote:
>...
> If all else fails, "Don't Do That!". or put a finger shield over the chip.

Or glue some really sharp tacks, point-upwards, to the top of the chip.  Dispels static charges, and seriously
discourages people from touching it!  :-)

Cheers,



Howard Winter
St.Albans, England


2006\02\19@134839 by Bob Axtell

face picon face
Howard Winter wrote:

{Quote hidden}

sorta like a lightning arrestor, Howard? hehe.

I think this is being caused by an electric field imposing its minor
effect on
the innerds of the PIC. The finger against the insulator forms a...
capacitor.
Having troubleshot a few problems like this... you might make sure your
device is properly bypassed, and make sure ALL  GND pins are connected
and all VDD pins are connected. The device  might work, but in a sorta funny
way, if a few are missing...

--Bob

--
Note: To protect our network,
attachments must be sent to
attachspamKILLspamengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\02\19@181555 by kerri

flavicon
face
> > 1. I have noticed that if I touch the top of the ic with my finger
> > the usb connection to my computer breaks. Is this normal?
>
> Not likely... Usually that means a digital IO line has been left
> floating somewhere. Check that every single digital input, including
> ones going to the PC, is definitively held in a valid state.
>
> One example of this would be IO lines on your PIC that aren't being
> connected to them. Either make sure they are set as outputs, or tie them
> to V+ or ground through a 10k resistor.

This is about the inputs, I have seen in the datasheet that after power-on
all the TRIS registers are set as inputs. So what is the recommended
practice, I suspect unused pins should be left as inputs, isn't that why
they are reset to inputs in the first place?

Secondly, what is the recommended procedure with unused pins, to
leave them alone, or to connect them to gnd or something, don't they
have a week pull up/down internally anyway?

And why would touching an input would have any effect on the pic,
unless there is some firmware which is monitoring these pins, which
there isn't, I can't see why this could possibly be the reason, and
maybe it is a capacitance issue,  i.e normal  expected behaviour?

2006\02\19@185122 by David VanHorn

picon face
>
> I suspect unused pins should be left as inputs, isn't that why
> they are reset to inputs in the first place?


Not exactly.  It lets you use pulling resistors to set the output pins into
safe states without having to fight the chip outputs.



> And why would touching an input would have any effect on the pic,
> unless there is some firmware which is monitoring these pins, which
> there isn't, I can't see why this could possibly be the reason, and
> maybe it is a capacitance issue,  i.e normal  expected behaviour?


An open pin can float to VCC/2 where the input circuitry will draw some fair
current.  They can cause undesired interrupts, and interfere with other
stages on the chips.

2006\02\19@185600 by Bob Axtell

face picon face
kerri wrote:

>>>1. I have noticed that if I touch the top of the ic with my finger
>>>the usb connection to my computer breaks. Is this normal?
>>>      
>>>
>>Not likely... Usually that means a digital IO line has been left
>>floating somewhere. Check that every single digital input, including
>>ones going to the PC, is definitively held in a valid state.
>>
>>One example of this would be IO lines on your PIC that aren't being
>>connected to them. Either make sure they are set as outputs, or tie them
>>to V+ or ground through a 10k resistor.
>>    
>>
>
>This is about the inputs, I have seen in the datasheet that after power-on
>all the TRIS registers are set as inputs. So what is the recommended
>practice, I suspect unused pins should be left as inputs, isn't that why
>they are reset to inputs in the first place?
>  
>
They are set to INPUT at reset so that the chip isn't damaged by
something driving the
pin at power up.

>Secondly, what is the recommended procedure with unused pins, to
>leave them alone, or to connect them to gnd or something, don't they
>have a week pull up/down internally anyway?
>  
>
Assign unused pins as OUTPUTS usually at GND level. You can assign a
weak pullup,
but they are normally just floating...

>And why would touching an input would have any effect on the pic,
>unless there is some firmware which is monitoring these pins, which
>there isn't, I can't see why this could possibly be the reason, and
>maybe it is a capacitance issue,  i.e normal  expected behaviour?
>  
>
Your body has about a 100K to 1M  resistance to GND. But more important,
your
body picks up stray electric fileds, such as flourescent lighting etc.

I know of a PIC design that uses the fact that the human body effects
pins WITHOUT
TOUCHING them (just being closeby). The RC time constant of the design
is changed
by the presence of the finger, and is detected by the PIC. Take a peek at
http://www.bytecraft.com/touchsw.html .

--Bob

--
Note: To protect our network,
attachments must be sent to
.....attachKILLspamspam.....engineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\02\19@192730 by kerri

flavicon
face
> >This is about the inputs, I have seen in the datasheet that after
power-on
> >all the TRIS registers are set as inputs. So what is the recommended
> >practice, I suspect unused pins should be left as inputs, isn't that why
> >they are reset to inputs in the first place?
> >
> >
> They are set to INPUT at reset so that the chip isn't damaged by
> something driving the
> pin at power up.

Sorry, but what do you mean "something" ?

>
> >Secondly, what is the recommended procedure with unused pins, to
> >leave them alone, or to connect them to gnd or something, don't they
> >have a week pull up/down internally anyway?
> >
> >
> Assign unused pins as OUTPUTS usually at GND level. You can assign a
> weak pullup,
> but they are normally just floating...

Sorrry, what do you mean "they are just floating"
Are they floating because of a pullup, or because a pullup is weak,
or something else - sorry you have completely lost me now.
which pullup?

{Quote hidden}

ok, this is interesting (perhaps), but how does it help me to understand if
touching
my pic should have an effect or not under proper design. Am I the only one
in the world who has noticed that (and became a tadd concerned)?

2006\02\19@200832 by Jinx

face picon face

> > I suspect unused pins should be left as inputs, isn't that why
> > they are reset to inputs in the first place?

Kerri, never leave inputs floating (unless it's part of the design)

http://www.piclist.com/techref/logic/xtrapins.htm

2006\02\19@203049 by Bob Axtell

face picon face
kerri wrote:

{Quote hidden}

Assume for the moment that your PIC design has a credit card reader
attached at your
PIC's pin RB0. The card reader is an output. If the PIC powered up as an
output as well,
either the PIC is damaged by the credit card reader, or the credit card
reader is damaged
by the PIC. MAYBE they won't be damaged... but we engineers don't
tolerate things like
that, it is not good practice to hope things aren't broken by just
powering them up.

{Quote hidden}

Inputs are just inputs, and they are unconnected to either rail. Sorry, no
pullups at powerup. You're thinking of motorola stuff, they have small
pullups everywhere. But not PICs.


>Are they floating because of a pullup, or because a pullup is weak,
>or something else - sorry you have completely lost me now.
>which pullup?
>  
>
They are "floating" because they are not connected yet. They might float
low or
float high. But when they hang around the middle, they draw a LOT of
current.


{Quote hidden}

When all the inputs to the PIC are handled properly, low impedance
pullups, etc there will
NOT be this effect. Yes, you should be concerend. You need to fix that
problem.

But you'll discover it.

--Bob



--
Note: To protect our network,
attachments must be sent to
EraseMEattachspam_OUTspamTakeThisOuTengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\02\20@034651 by Peter Todd

picon face
On Sun, Feb 19, 2006 at 06:30:48PM -0700, Bob Axtell wrote:
> Assume for the moment that your PIC design has a credit card reader
> attached at your
> PIC's pin RB0. The card reader is an output. If the PIC powered up as an
> output as well,
> either the PIC is damaged by the credit card reader, or the credit card
> reader is damaged
> by the PIC. MAYBE they won't be damaged... but we engineers don't
> tolerate things like
> that, it is not good practice to hope things aren't broken by just
> powering them up.

Here's an opposite question then:

Often in my designs, I leave pins unconnected, and then make sure the
first thing I do on bootup, literally within the first 10 instructions,
is to make any unconnected pins outputs with the appropriate TRIS bits.

How kosher is that practice? I can say I've never had any problems with
unexplained behavior at startup or ICSP programming, but I don't design
anything for harsh EMI environments.

I take it during ICSP the pins will get treated as inputs, which could
be a problem, correct?

> Inputs are just inputs, and they are unconnected to either rail. Sorry, no
> pullups at powerup. You're thinking of motorola stuff, they have small
> pullups everywhere. But not PICs.

Do PICs avoid those small pullups to allow for their ultra-low power
consumption modes?

--
petespamspam_OUTpetertodd.ca http://www.petertodd.ca

2006\02\20@035908 by Bob Axtell

face picon face
Peter Todd wrote:

{Quote hidden}

Pretty kosher. I'll bet a steak dinner that 99% of the PIClist does the
very same thing.
I sure do.

>I take it during ICSP the pins will get treated as inputs, which could
>be a problem, correct?
>  
>
Actually, during programming, most of the chip seems to be turned off.
For example,
no osc runs, etc etc.  But, yes, ICSP is a possibly weak time for noise.

{Quote hidden}

Yep. That extra stuff adds up fast.

--Bob



--
Note: To protect our network,
attachments must be sent to
@spam@attachKILLspamspamengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\02\20@041355 by Chen Xiao Fan

face
flavicon
face


> -----Original Message-----
> From: KILLspampiclist-bouncesKILLspamspammit.edu
> [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu] On Behalf Of Bob Axtell
> Sent: Monday, February 20, 2006 9:31 AM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] 2 questions about 18f4550
>
> Assume for the moment that your PIC design has a credit card reader
> attached at your PIC's pin RB0. The card reader is an output.
> If the PIC powered up as an  output as well, either the PIC is
> damaged by the credit card reader, or the  credit card
> reader is damaged by the PIC. MAYBE they won't be damaged...
> but we engineers don't tolerate things like that, it is not good
> practice to hope things aren't broken by just powering them up.
>

To prevent power-up wrong behaviors is actually an important
considerations for production quality designs.

I understand your points but I think you have a wrong assumptions
here. You should not attached the credit card reader directly to
your PIC's pin RB0. That will for sure fail the ESD test. There
should be some circuits between them.



Regards,
Xiaofan

2006\02\20@042401 by Michael Rigby-Jones

picon face


{Quote hidden}

The credit card reader was just an example, it could have been a push button, a serial driver (MAX232 etc.), or many other devices that could cause a conflict if the PIC pins were configured to outputs at power up.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2006\02\20@063455 by kerri

flavicon
face
> Kerri, never leave inputs floating (unless it's part of the design)
>
> http://www.piclist.com/techref/logic/xtrapins.htm

I can't see anywhere in the bootloader that they have made any
explicit to ANY TRIS register, this is official pic code is it not..

2006\02\20@065135 by Jinx

face picon face

> > www.piclist.com/techref/logic/xtrapins.htm
>
> I can't see anywhere in the bootloader that they have made any
> explicit to ANY TRIS register, this is official pic code is it not..

Not sure where you're coming from. I see no mention of bootloader
on that page. As for "official", it is simply people's opinion and advice
on what to do with unused pins. Which is to not let them float

2006\02\20@081525 by kerri

flavicon
face
> >
> > I can't see anywhere in the bootloader that they have made any
> > explicit to ANY TRIS register, this is official pic code is it not..
>
> Not sure where you're coming from. I see no mention of bootloader
> on that page. As for "official", it is simply people's opinion and advice
> on what to do with unused pins. Which is to not let them float

What I mean is if everyone seems to say to set unused pins to outputs,
then one would expect microchip to be doing this as well, yet in boot
loader (bootloader is official in the sense that it is provided by
microchip company) there is no use of any TRIS registers, so this
means they do not bother to change unused pins to output, so this
is puzzling.

2006\02\20@083629 by Michael Rigby-Jones

picon face


{Quote hidden}

Microchips examples frequently contain bad coding practice and other mistakes.  Do not use them as a guide to "good practice"!

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2006\02\20@084442 by John Nall

picon face
Michael Rigby-Jones wrote:

> > Microchips examples frequently contain bad coding practice and other mistakes.  Do not use them as a guide to "good practice"!
>  
.
I wonder why that is?  Clearly  they have the expertise within the
company to produce impeccable code, and it seems like the bad public
relations resulting from putting out examples with bad coding practices
and, sometimes, outright errors, would make them want to do it right.  
The only thing that I can figure out is that the more skilled people are
so busy at doing other things that  they put the newbies on the example
projects.

2006\02\20@090240 by Maarten Hofman

face picon face
> I wonder why that is?  Clearly  they have the expertise within the
> company to produce impeccable code, and it seems like the bad public
> relations resulting from putting out examples with bad coding practices
> and, sometimes, outright errors, would make them want to do it right.
> The only thing that I can figure out is that the more skilled people are
> so busy at doing other things that  they put the newbies on the example
> projects.

To be honest, I never really had the idea that any of the examples of
Microchip were considered "bad". I agree that you can't describe them
as "good" either, but they are examples that usually seem to give the
result that is promised in the surrounding text, they have sufficient
comments and they have a style that allows you to easily convert them
to your own code.

It is true, however, that I learned PICmicro despite Myke Predko's
book (I appreciate his hardware knowledge, but hope his code is not
used in any application that touches my life), so I might have a
different idea of what is considered a "bad" example.

Greetings,
Maarten Hofman.

2006\02\20@092159 by John Nall

picon face
Maarten Hofman wrote:
>> > To be honest, I never really had the idea that any of the examples of
>> Microchip were considered "bad". I agree that you can't describe them
>> as "good" either, but they are examples that usually seem to give the
>> result that is promised in the surrounding text, they have sufficient
>> comments and they have a style that allows you to easily convert them
>>    
I find them to be very useful, and usually when I want to do something
that I don't know how to do,  then I will go to a Microchip manual
(usually the Programmers' Reference Manual) and try to find something
that is close.  But sometimes there are errors in their code.  Not
always, not even most of the time, but enough so that I never know for
sure  that it will work as they have it.  I find this disconcerting.  I
think that their code should be a model for how to program a PIC -- not
merely an example that is somewhere in the general ballpark.

Of course, I realize that  this is a "what have you done for me lately?"
mentality, and actually am very grateful to Microchip for providing the
resources that they freely make available.  :-)

2006\02\20@094752 by Jan-Erik Soderholm

face picon face
kerri wrote :

> ...but how does it help me to understand if touching
> my pic should have an effect or not under proper design.

It shouldn't, in a "proper design". Simple as that.

> Am I the only one in the world who has noticed that
> (and became a tadd concerned)?

Well, if so, where do you think all the advice saying
"do NOT leave open pins as inputs" come from ???

> What I mean is if everyone seems to say to set unused pins
> to outputs, then one would expect microchip to be doing this
> as well, yet in boot loader (bootloader is official in the sense
> that it is provided by Microchip company) there is no use of
> any TRIS registers, so this means they do not bother to
> change unused pins to output, so this is puzzling.

Well, the *bootloader* has no idea of what is connected
or not to pins of the processor. so if the *bootloader*
would start setting pins to outputs just like that, it could
have some "interesting" effects. Think of motors and relays
starting acting "by themself"...

I think you're making this to a much larger issue that
it is. Just read the advices about open pins and follow them...

Regards,
Jan-Erik.



2006\02\20@095302 by Wouter van Ooijen

face picon face
> What I mean is if everyone seems to say to set unused pins to outputs,
> then one would expect microchip to be doing this as well, yet in boot
> loader (bootloader is official in the sense that it is provided by
> microchip company) there is no use of any TRIS registers, so this
> means they do not bother to change unused pins to output, so this
> is puzzling.

A bootloader is meant to be used in a target circuit. It would be a bit
crude if a bootloader assumes that it is safe to set all pins to
output...

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\20@100105 by Bob Axtell

face picon face
John Nall wrote:

{Quote hidden}

But very true, John. There are errors in the oldest math appnote they
ever wrote, in
1989 or so, and it has never been fixed in all these years.

--
Note: To protect our network,
attachments must be sent to
RemoveMEattachspam_OUTspamKILLspamengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\02\20@101320 by kerri

flavicon
face
> --

2006\02\20@104759 by kerri

flavicon
face
> Well, the *bootloader* has no idea of what is connected
> or not to pins of the processor. so if the *bootloader*
> would start setting pins to outputs just like that, it could
> have some "interesting" effects. Think of motors and relays
> starting acting "by themself"...

I would have thought secure a soundly working bootloader
first, then the other app can make it's own settings.

2006\02\20@114841 by Wouter van Ooijen

face picon face
> > Well, the *bootloader* has no idea of what is connected
> > or not to pins of the processor. so if the *bootloader*
> > would start setting pins to outputs just like that, it could
> > have some "interesting" effects. Think of motors and relays
> > starting acting "by themself"...
>
> I would have thought secure a soundly working bootloader
> first, then the other app can make it's own settings.

A bootloader that makes the 'self destruct now' pin output and high? You
must be kidding!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\20@115638 by David VanHorn

picon face
>
>
> I would have thought secure a soundly working bootloader
> first, then the other app can make it's own settings.


The point is that knowing what the safe settings for all the pins are, is
outside the scope of a bootloader. This would be different in every
application.  While the bootloader is running, and before the application
starts up, it's up to the designer to assure that all the pins are in safe
states, and to know what those states are, dependent on the hardware
connected.

2006\02\20@145616 by kerri

flavicon
face
> > I would have thought secure a soundly working bootloader
> > first, then the other app can make it's own settings.
>
>
> The point is that knowing what the safe settings for all the pins are, is
> outside the scope of a bootloader. This would be different in every
> application.  While the bootloader is running, and before the application
> starts up, it's up to the designer to assure that all the pins are in safe
> states, and to know what those states are, dependent on the hardware
> connected.

I think all the pins there are safe, I just can't find the TRIS
instructions.
You won't understand what I mean without having a look at it.

2006\02\20@161413 by Jinx

face picon face

> To be honest, I never really had the idea that any of the examples of
> Microchip were considered "bad

Some Microchip code examples do have mistakes (both in instructions
and comments) that do absolutely baffle and confuse. Which, IMHO,
is inexcusable. For the newbie this can be extremely frustrating and time-
consuming. Even if you're familiar with PICs it's not always obvious why
a routine doesn't work, particularly if it's code for a process that you
weren't able to code yourself (otherwise you'd not have tried someone
else's code). The end result, after numerous threads along the lines of
"Why can't isn't ANxxx code working ?", is that confidence in Microchip
code examples is not 100%. When it should be

2006\02\20@161949 by Jan-Erik Soderholm

face picon face
kerri wrote :

> I think all the pins there are safe, I just can't find the TRIS
> instructions.

And you would you ?
What exactly should the bootloader do with the TRIS regs ??

All pins ar in a safe state on restet anyway...

Jan-Erik.



2006\02\20@164651 by Wouter van Ooijen

face picon face
> I think all the pins there are safe, I just can't find the TRIS
> instructions.

TRIS instructions on an 18F ??

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\20@165516 by David VanHorn

picon face
>
>
> All pins ar in a safe state on restet anyway...


Safe for the processor certainly, but what about the external hardware?

Having designed thermal and impact printers, you're only about a millisecond
away from an expensive ruined printhead, if you don't provide resistors to
pull those processor driven control lines to a definite state during reset,
or when something like a loader is running.

2006\02\20@170628 by kerri

flavicon
face
> > I think all the pins there are safe, I just can't find the TRIS
> > instructions.
>
> And you would you ?
> What exactly should the bootloader do with the TRIS regs ??
>
> All pins ar in a safe state on restet anyway...

Exactly, which is why I am puzzled that people here told me that
I need to set them as outputs. (btw, how do you know?)

Just to be clear, TRIS is what is needed to change pins from input
to output, and yes they do apply to pic18f4550, you have got
TRISA/TRISB/TRISC/TRISD/TRISE, sorry for any notational
confusion. So to change all porta inputs to outputs you would use
clr TRISA

2006\02\20@171526 by Herbert Graf

flavicon
face
On Mon, 2006-02-20 at 22:06 +0000, kerri wrote:
> > > I think all the pins there are safe, I just can't find the TRIS
> > > instructions.
> >
> > And you would you ?
> > What exactly should the bootloader do with the TRIS regs ??
> >
> > All pins ar in a safe state on restet anyway...
>
> Exactly, which is why I am puzzled that people here told me that
> I need to set them as outputs. (btw, how do you know?)

Well, if you're the one designing the hardware, it would be hard NOT to
know what is "safe" since, well, you HAVE to know.

> Just to be clear, TRIS is what is needed to change pins from input
> to output, and yes they do apply to pic18f4550, you have got
> TRISA/TRISB/TRISC/TRISD/TRISE, sorry for any notational
> confusion. So to change all porta inputs to outputs you would use
> clr TRISA

You said "TRIS instruction". The TRIS instruction is a relic of very old
PICs. It's still used in the smallest and/or oldest PICs (i.e. 12C509,
16C54). It's still available in 16F PICs (I don't know about ALL 16F
PICs, but at least a few still support the TRIS instruction). It is NOT
available in the 18F or above PICs AFAIK.

Now, a search for clr TRISA may ALSO not be valid since some people like
to use their own names and rename things like that.

But yes, it does stand a fair chance that if the code makes no mention
of "TRIS" it doesn't change those registers (note I said FAIR chance,
there is a sizable chance that someone changes the TRIS registers but
doesn't use the letters TRIS to do it).

TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2006\02\20@172817 by Jinx

face picon face

> Exactly, which is why I am puzzled that people here told me
> that I need to set them as outputs. (btw, how do you know?)

You don't *have* to or need to set them as outputs. No reason
why you can't have them as commited inputs. I think you should
read this page again

http://www.piclist.com/techref/logic/xtrapins.htm

2006\02\20@173124 by David VanHorn

picon face
>
>
> Exactly, which is why I am puzzled that people here told me that I need to
> set them as outputs. (btw, how do you know?)



OOOOk.

For a microcontroller with nothing else connected to it.
Set unused pins to outputs.  High or low makes little difference.
Internal pullups may or may not be strong enough to prevent external static
fields from causing problems by pulling pins into the VCC/2 region.  These
problems can be excessive current consumption, spurious interrupts, problems
in adjacent pin functionality, or other, depending on the architecture.

In all cases, pins which are connected to nothing should be outputs, or
externally pulled high or low, to avoid them floating into the VCC/2 region
which will cause problems, determined by the exact implementation.  On-chip
pullups are typically very weak, and won't protect you from large E-fields.

IF you have external hardware connected to the pins, then you as the
engineer have to determine the safe state those pins should be in, so that
neither the micro, or the peripheral electronics, or the user is damaged.
Since the micro cannot drive those pins during reset (which might be a
microsecond or a month), the normal method is to use pulling resistors to
drive the pins with a low but workable current in the proper direction. The
chip tristates during this time (all inputs) so that it's outputs aren't
fighting yours.  The circuit should go into a safe state if you unplug the
micro entirely.

Once the software starts running, it is possible to set the pins up to safe
states driven by the pin output drivers or internal pullup/down resistors.
No loader program will magically know how to do this in YOUR application, so
this is not properly part of a loader app note.  You can easily add a few
instructions at the start of the loader to take care of this.

2006\02\20@173458 by kerri

flavicon
face
> Well, if you're the one designing the hardware, it would be hard NOT to
> know what is "safe" since, well, you HAVE to know.

I do, but no one here wants to put a little effort and look and what I am
saying.

2006\02\20@180719 by Jinx

face picon face
> I do, but no one here wants to put a little effort and look and
> what I am saying.

I don't think I'm being especially dense today Kerri, but I'm afraid
I can't actually grasp what you're trying to say. From the first post
about touching the PIC makes it go funny, it's somehow drifted on
to Microchip's bootloader and some confusion about TRIS

Can you re-state, simply, what it is you need to know ?

2006\02\20@180919 by Jan-Erik Soderholm

face picon face
kerri wrote :

> I do, but no one here wants to put a little effort
> and look and what I am saying.

And how do you know that ?

I'd say you are not reading the replies... :-)

So what now ?
Maybe you'd better sum it up and restate your question.
But read the replies once again. I guess that you'll
find that you have your answers there already...

Best Regards,
Jan-Erik.



2006\02\20@181810 by kerri

flavicon
face
> > > Well, the *bootloader* has no idea of what is connected
> > > or not to pins of the processor. so if the *bootloader*
> > > would start setting pins to outputs just like that, it could
> > > have some "interesting" effects. Think of motors and relays
> > > starting acting "by themself"...
> >
> > I would have thought secure a soundly working bootloader
> > first, then the other app can make it's own settings.
>
> A bootloader that makes the 'self destruct now' pin output and high? You
> must be kidding!

Sorry, which question are you replying to? Is it the bootloader one ?

2006\02\20@194747 by Robert Ammerman

picon face
> The point is that knowing what the safe settings for all the pins are, is
> outside the scope of a bootloader. This would be different in every
> application.  While the bootloader is running, and before the application
> starts up, it's up to the designer to assure that all the pins are in safe
> states, and to know what those states are, dependent on the hardware
> connected.


Or, modify the bootloader to take advantage of knowledge of the actual
hardware.

Bob Ammerman
RAm Systems

2006\02\20@205125 by William Chops Westfield

face picon face

On Feb 20, 2006, at 5:44 AM, John Nall wrote:

>>> Microchips examples frequently contain bad coding practice and other
>>> mistakes.  Do not use them as a guide to "good practice"!
>>
> .
> I wonder why that is?  Clearly  they have the expertise within the
> company to produce impeccable code...

Why do you assume that?  Microchip is a hardware company.
The environment necessary to write "impeccable" code usually
consists of a fairly large body of coders who routinely tear
into each other when a mistake is detected...  I dare say that
there is VERY LITTLE "impeccable" code ANYWHERE.  (and it doesn't
help that one coder's favorite style is another's "bad coding
practice."

BillW

2006\02\20@213330 by John Nall

picon face
William Chops Westfield wrote:
>> > Why do you assume that?  Microchip is a hardware company.
>>    
.
Well...yeah...but IBM was also a hardware company  (at least until they
"unbundled, " anyway)  and they had some of the best coders that ever
existed.  IMHO.
.

>> > The environment necessary to write "impeccable" code usually
>> consists of a fairly large body of coders who routinely tear
>> into each other when a mistake is detected...
.
I most certainly agree with that!  Peer pressure trumps every time.  :-)
.

>> >  I dare say that
>> there is VERY LITTLE "impeccable" code ANYWHERE.  (and it doesn't
>> help that one coder's favorite style is another's "bad coding
>> practice."
>>    
.
I am defining "impeccable" as tight, well organized, and absolutely 100%
correct.  If one were to change the definition, then of course that
might allow for other entries.  :-)


2006\02\20@224139 by Herbert Graf

flavicon
face
On Mon, 2006-02-20 at 22:34 +0000, kerri wrote:
> > Well, if you're the one designing the hardware, it would be hard NOT to
> > know what is "safe" since, well, you HAVE to know.
>
> I do, but no one here wants to put a little effort and look and what I am
> saying.

Well then, perhaps I'm the only one who's missed what you are trying to
say.

In case that's not the case, how about stating exactly WHAT you are
trying to say, obviously I've misunderstood.



-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2006\02\20@232438 by William Chops Westfield

face picon face

On Feb 20, 2006, at 1:48 PM, David VanHorn wrote:

>> All pins ar in a safe state on restet anyway...
>
>
> Safe for the processor certainly, but what about the external
> hardware?
>
> Having designed thermal and impact printers, you're only about
> a millisecond away from an expensive ruined printhead, if you
> don't provide resistors to pull those processor driven control
> lines to a definite state during reset, or when something
> like a loader is running.
>
But, isn't reset time "long" enough that you have to worry about
that sort of thing anyway?  72ms after power-on reset, plus 1024
clock cycles for oscillator stabilization, and who knows how long
before the power supply (or supplies) reach points where the PIC
things POR occurs.  Plus whatever circuit you've got on MCLR?

If you have critical external circuits, you have to deal with
the possibility of tri-stated "output" of the PIC for significant
times anyway, so dealing with the bootload state is probably not
much of an additional problem.

(or you can just customize the bootloader for your particular
application...)

BillW

2006\02\21@001932 by Peter Todd

picon face
On Mon, Feb 20, 2006 at 09:07:29PM -0500, John Nall wrote:
> >> > The environment necessary to write "impeccable" code usually
> >> consists of a fairly large body of coders who routinely tear
> >> into each other when a mistake is detected...
> .
> I most certainly agree with that!  Peer pressure trumps every time.  :-)

And in those enviroments you often end up with people writing this and
not much else:

void main(){
       printf("Hello World!\n")l
}

Even then my main declaration isn't really correct... and I'm missing
support for unicode.

--
RemoveMEpeteTakeThisOuTspamspampetertodd.ca http://www.petertodd.ca

2006\02\21@005708 by John Temples

flavicon
face
On Tue, 21 Feb 2006, Peter Todd wrote:

> And in those enviroments you often end up with people writing this and
> not much else:
>
> void main(){
>        printf("Hello World!\n")l
> }
>
> Even then my main declaration isn't really correct...

In the context of writing C for a PIC, there isn't a "correct"
declaration for main() -- assuming there is a main(), which isn't
required either.

--
John W. Temples, III

2006\02\21@012327 by Chen Xiao Fan

face
flavicon
face


> -----Original Message-----
> From: EraseMEpiclist-bouncesspamspamspamBeGonemit.edu
> [RemoveMEpiclist-bouncesKILLspamspammit.edu] On Behalf Of John Temples
>
> On Tue, 21 Feb 2006, Peter Todd wrote:
>
> > And in those enviroments you often end up with people
> writing this and
> > not much else:
> >
> > void main(){
> >        printf("Hello World!\n")l
> > }
> >
> > Even then my main declaration isn't really correct...
>
> In the context of writing C for a PIC, there isn't a "correct"
> declaration for main() -- assuming there is a main(), which isn't
> required either.

In general, main() is not strictly necessary but the default
startup code is calling main() for MPLAB C18 and C30.

Inside the C18 startup code, there are the following lines.

loop:
 // Call the user's main routine
 main ();
 goto loop;
}

It is interesting to see that Microchip is use the following
definitions of main for MPLAB C18:

void main(void){
}

And they are using the following prototype for MPLAB C30

int main(void){
       ...
       return 0;
}

Guess this is because that MPLAB C30 is based on GCC.

Regards,
Xiaofan

2006\02\21@013735 by Chen Xiao Fan

face
flavicon
face


> -----Original Message-----
> From: piclist-bouncesSTOPspamspamspam_OUTmit.edu
> [spamBeGonepiclist-bouncesSTOPspamspamEraseMEmit.edu] On Behalf Of kerri
>
> Just to be clear, TRIS is what is needed to change pins from input
> to output, and yes they do apply to pic18f4550, you have got
> TRISA/TRISB/TRISC/TRISD/TRISE, sorry for any notational
> confusion. So to change all porta inputs to outputs you would use
> clr TRISA

By the way, Microchip's USB firmware is using MPLAB C18. So there
will not be anything like "clr TRISA".

And they are doing the following for the bootloader example
(in file io_cfg.h).
#define mInitAllLEDs()      LATD &= 0xF0; TRISD &= 0xF0;

This is indeed questionable. It is correct to set RD0/1/2/3
to output since they are for LED output. RD4/5/6/7 are not
used so maybe it is better to set them as output and output 0
if you do not have something connected to them in the final
circuits. Take note this is only the bootloader. The
use application hardware/software should take care of this.

Regards,
Xiaofan

2006\02\21@015116 by John Temples

flavicon
face
On Tue, 21 Feb 2006, Chen Xiao Fan wrote:

> And they are using the following prototype for MPLAB C30
>
> int main(void){
>        ...
>        return 0;
> }
>
> Guess this is because that MPLAB C30 is based on GCC.

Probably because gcc likes to give a warning if the return type of
main() is not int.

--
John W. Temples, III

2006\02\21@030933 by Wouter van Ooijen

face picon face
> > And in those enviroments you often end up with people
> writing this and
> > not much else:
> >
> > void main(){
> >        printf("Hello World!\n")l
> > }
> >
> > Even then my main declaration isn't really correct...

The problem is that C is not "correct" in the embedded context. Like
Olin's explanation for coexistence of imperial/metric: it is the result
of a sequence of decisions that where probably correct *at that time*.
So I am stuck with explaining my students that an embedded program
starts 'from nothing' and 'never ends', yet the correct declaration of
main is still

  int main( int argc, char **argv )

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\21@030937 by Wouter van Ooijen

face picon face
> > > > Well, the *bootloader* has no idea of what is connected
> > > > or not to pins of the processor. so if the *bootloader*
> > > > would start setting pins to outputs just like that, it could
> > > > have some "interesting" effects. Think of motors and relays
> > > > starting acting "by themself"...
> > >
> > > I would have thought secure a soundly working bootloader
> > > first, then the other app can make it's own settings.
> >
> > A bootloader that makes the 'self destruct now' pin output
> and high? You
> > must be kidding!
>
> Sorry, which question are you replying to? Is it the bootloader one ?

The common sense is to keep the exact question or remark one is replying
to exactly above (or for aussies: exactly beneath) the reply. In this
case I replied to "I would have thought secure a soundly working
bootloader first, then the other app can make it's own settings.", which
seems to require that the bootloader does something with setting pins to
a safe (output) state. This is so obviously foolish that I replied in a
humourous way. If you don't believe it to be foolish, think again. A
general-purpose bootloader is by its nature not written for a specific
application, so it can't know how the pins are used. Now imagine the
bootloader in a nuclear doomsday device. I would not like it to set its
pins to a 'safe' output state! It makes more sense to put the
responsibility on the hardware designer to include hardware to make
input (high-imedance) on all pins a safe state.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
 

2006\02\21@030938 by Wouter van Ooijen

face picon face
> I do, but no one here wants to put a little effort and look
> and what I am saying.

If you have an opinion and everyone else has a different opinion you are
obviously right and everyone else is wrong, right?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\21@080154 by Howard Winter

face
flavicon
picon face
John,

On Mon, 20 Feb 2006 21:07:29 -0500, John Nall wrote:

> I am defining "impeccable" as tight, well organized, and absolutely 100% correct.

There's a coincidence - in my dictionary that's the definition of "impossible"!  :-)

"Fast, efficient, cheap - choose two"  :-)))

Cheers,


Howard Winter
St.Albans, England


2006\02\21@085206 by John Nall

picon face
Howard Winter wrote:

>> >> I am defining "impeccable" as tight, well organized, and absolutely 100% correct.
>>    
>
> There's a coincidence - in my dictionary that's the definition of "impossible"!  :-)
>
> "Fast, efficient, cheap - choose two"  :-)))
>
>  
.
Yeah, but Howard, I didn't have  the word "fast" in my definition.  
There is always a trade-off.  Generally speaking, the fastest code is
just going to be completely linear, no branches, no function calls,
etc.  :-)

2006\02\22@031743 by William Chops Westfield

face picon face

On Feb 21, 2006, at 5:01 AM, Howard Winter wrote:

>
>> I am defining "impeccable" as tight, well organized, and
>> absolutely 100% correct.
>
> There's a coincidence - in my dictionary that's the
> definition of "impossible"!  :-)
>
Heh.  I was thinking that "tight" and "well organized" were rather
at odds with each other.  And it's not at all clear that efficiency
is something to be sought after in a code snippet that's supposed to
be "educational."

But I do think "not flat-out WRONG" would be a requirement!

BillW

2006\02\22@051413 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

> The problem is that C is not "correct" in the embedded context. Like
> Olin's explanation for coexistence of imperial/metric: it is the result
> of a sequence of decisions that where probably correct *at that time*.
> So I am stuck with explaining my students that an embedded program
> starts 'from nothing' and 'never ends', yet the correct declaration of
> main is still
>
>    int main( int argc, char **argv )

I always thought that "int main( void )" was also a correct (that is,
according to the standard) form of main. I don't have the standard here...
Is this not so?

Gerhard

2006\02\22@055724 by Michael Rigby-Jones

picon face


{Quote hidden}

Correct only from an ANSI point of view maybe.  The HiTech compiler expects void main( void ) as the declaration of main, which is technicaly correct for an embedded program.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2006\02\22@060439 by Chris Emerson

flavicon
face
On Wed, Feb 22, 2006 at 07:13:49AM -0300, Gerhard Fiedler wrote:
> I always thought that "int main( void )" was also a correct (that is,
> according to the standard) form of main. I don't have the standard here...
> Is this not so?

It is so.  Section 5.1.2.2 says in a "hosted environment" (ie running
under an operating system), main can either be "int main(void)" or "int
main(int argc, char *argv[])".

In fact in a "freestanding environment" (section 5.1.2.1), "the name and
type of the function called at program startup are
implementation-defined".  So a PIC ANSI C compiler can legally use "void
main(void)", or indeed "float asdf(char a, double b)" if it really wants
to, as long as it's documented.

(References from C99)

Chris

2006\02\22@063509 by Wouter van Ooijen

face picon face
> I always thought that "int main( void )" was also a correct (that is,
> according to the standard) form of main. I don't have the
> standard here...

Even with that form I have a hard to explain what the 'int' is for,
after I have emphasised that an embedded program never stops.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\22@075334 by olin piclist

face picon face
Michael Rigby-Jones wrote:
> Correct only from an ANSI point of view maybe.  The HiTech compiler
> expects void main( void ) as the declaration of main, which is
> technicaly correct for an embedded program.

Actually even that contains unnecessary baggage for an embedded system.
There is no good reason for the top level routine to be a subroutine at all.
The point of not providing a return value is that there is nothing to return
to.  Once again this runs into a problem with C adapted to small embedded
systems.  There is no way to define executable code except within a
subroutine.  Some languages do have this capability, like Pascal and even
FORTRAN, so the concept is not new.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\02\22@075923 by Michael Rigby-Jones

picon face


{Quote hidden}

But the baggage in reality is zero, only a brain dead compiler would use a stack position by calling main() from the reset vector, (and even if it did it wouldn't make any difference with the PIC's circular stack).  Every program has to have an entry point, in C it happens to be called main().

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2006\02\22@081928 by olin piclist

face picon face
Michael Rigby-Jones wrote:
> But the baggage in reality is zero, only a brain dead compiler would
> use a stack position by calling main() from the reset vector,

Actually the compiler has nothing to do with it.  This is a function of the
C runtime initialization code which I expect the compiler writers wrote in
assembler.  The problem is forcing support for somebody doing a RETURN in
MAIN.  I've seen C runtime startup code that does call MAIN and it did
handle MAIN returning.  In the case I looked at it just reinitialized the
system, which of course ended up calling main again.  In other words, a
RETURN in MAIN had the same net effect as GOTO 0.

> (and even
> if it did it wouldn't make any difference with the PIC's circular
> stack).

This is only true on the PIC 16 and 12.  The PIC 18 stack is not circular
and the PIC 30 stack is in memory.  On these systems calling MAIN as a
subroutine permanently ties up some resources.

What I've done in the few cases where we had mixed C/ASM is to provide a C
MAIN normally.  That allows the C runtime startup to do whatever it has to
do.  The C MAIN would call true main routine which was written in assembler.
This would reset the stack.  This only wastes two or three extra
instructions, but then again if that was an issue you wouldn't be using C in
the first place.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\02\22@103507 by John Temples

flavicon
face
On Wed, 22 Feb 2006, Olin Lathrop wrote:

> Michael Rigby-Jones wrote:
>> Correct only from an ANSI point of view maybe.  The HiTech compiler
>> expects void main( void ) as the declaration of main, which is
>> technicaly correct for an embedded program.
>
> Actually even that contains unnecessary baggage for an embedded system.
> There is no good reason for the top level routine to be a subroutine at all.

The fact that it looks like a subroutine in your text editor doesn't
mean the compiler treats it as one.

Hi-Tech's compiler does not call main() from its startup code; it
branches to it.  And it does not generate a return instruction at the
closing brace of main().  You cannot "call" main() and expect anything
meaningful to happen.

> The point of not providing a return value is that there is nothing to return
> to.  Once again this runs into a problem with C adapted to small embedded
> systems.  There is no way to define executable code except within a
> subroutine.

Since main() is not being called, and not being returned from, what is
the problem you believe would be solved by defining executable code
outside of a subroutine?

--
John W. Temples, III

2006\02\22@104016 by John Temples

flavicon
face
On Wed, 22 Feb 2006, Wouter van Ooijen wrote:

>> I always thought that "int main( void )" was also a correct (that is,
>> according to the standard) form of main. I don't have the
>> standard here...
>
> Even with that form I have a hard to explain what the 'int' is for,
> after I have emphasised that an embedded program never stops.

The 'int' is not required in a "freestanding" (embedded) system.  The
standard places no requirements on the declaration, or even existence
of, main() in an embedded system.

--
John W. Temples, III

2006\02\22@110716 by William Killian

flavicon
face
ANSI C specifies int main (int, char **) as that is what was expected in
standard systems development.  This entry point was defined as what the
compiler's linked to base would call.  That same code was what was
responsible for clearing extern class memory items to 0.  This is also
the code main() would return to and do what ever it took to pass the
exit or return value back to the O/S.

Embedded systems typically do not have such a loader with the memory
clear.  It will be up to the particular architecture of the processor
and any kernel used as to what a particular program would use.  But with
embedded you almost always have to write the initial code that replaces
the loader object that would clear memory and call your "main".  With
embedded multitasking kernels a single main() is not meaningful.  I've
typically in those cases created multiple tasks with entry points such
as task1_main(), task2_main() etc.   These also typically never returned
so had no need for a return type other than void like the PIC compilers
seem to based on this thread.

The C language as do all algol derivative languages only have code with
in functions/procedures/subroutines.  Its part of the language
definition.  In the embedded world you do typically have an entry point
that is first started by the processors restart mechanism with some form
of direct jump or branch rather than a subroutine call mechanism.  The C
stack frame stuff at the entrance to C is 'wasteful' but more or less
unavoidable.  Many compilers designed for embedded or even not allow you
to eliminate most of the traditional stack frame through optimization
phases.  One could write a C derivative with an extension for embedded
work where a new keyword would allow a function to be defined as a tasks
or reset condition entry point that is not called but instead branched
to that can not return.  I now wonder if a reserved word, entry IRC, had
originally been intended for that purpose.  The reserved word interrupt
is defined to mean a function enters differently than a standard
function so another would be fine.

The primary entry point for embedded systems can be written is C for
many architectures but is often assembly anyway.  



> {Original Message removed}

2006\02\22@112249 by olin piclist

face picon face
John Temples wrote:
> Since main() is not being called, and not being returned from, what is
> the problem you believe would be solved by defining executable code
> outside of a subroutine?

The point is that I don't know that MAIN isn't a subroutine, and on some
implementations it is.  Some compiler vendors have apparently decided to
make a special case of MAIN to get around the problem.  A better answer
would be a deliberate way to define the top level program specified in the
standard so that every compiler implementer wouldn't have to work around
this differently.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\02\22@112423 by Wouter van Ooijen

face picon face
> > Even with that form I have a hard to explain what the 'int' is for,
> > after I have emphasised that an embedded program never stops.
>
> The 'int' is not required in a "freestanding" (embedded) system.  The
> standard places no requirements on the declaration, or even existence
> of, main() in an embedded system.

OK, so I'll just have to wait for all compilers for freestanding
embedded systems to allow 'void main(void)'.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\22@113943 by John Temples

flavicon
face
On Wed, 22 Feb 2006, William Killian wrote:

> ANSI C specifies int main (int, char **) as that is what was expected in
> standard systems development.  This entry point was defined as what the
> compiler's linked to base would call.  That same code was what was
> responsible for clearing extern class memory items to 0.  This is also
> the code main() would return to and do what ever it took to pass the
> exit or return value back to the O/S.
>
> Embedded systems typically do not have such a loader with the memory
> clear.

I would not say "typically"; I've only seen one compiler have this
behavior by default (Microchip's C18), and the necessary code can be
enabled.

Clearing static storage is not optional in ANSI, even for embedded
systems.

> One could write a C derivative with an extension for embedded
> work where a new keyword would allow a function to be defined as a tasks

IAR does this with the __C_task extension.

> to that can not return.  I now wonder if a reserved word, entry IRC, had
> originally been intended for that purpose.  The reserved word interrupt
> is defined to mean a function enters differently than a standard
> function so another would be fine.

"entry" and "interrupt" are not reserved words in standard C.

--
John W. Temples, III

2006\02\22@115220 by John Temples

flavicon
face
On Wed, 22 Feb 2006, Wouter van Ooijen wrote:

>> The 'int' is not required in a "freestanding" (embedded) system.  The
>> standard places no requirements on the declaration, or even existence
>> of, main() in an embedded system.
>
> OK, so I'll just have to wait for all compilers for freestanding
> embedded systems to allow 'void main(void)'.

That's not going to happen, because you can't generalize about
embedded systems.  That's why the standard was written the way it
was.  I've used systems where main() was "int main(int argc, char
*argv[])" because it was possible to pass "command line arguments" to
the embedded target from an attached host and get a return value when
main() exited.

--
John W. Temples, III

2006\02\22@121741 by Peter Todd

picon face
On Wed, Feb 22, 2006 at 08:39:42AM -0800, John Temples wrote:
> Embedded systems typically do not have such a loader with the memory
> > clear.
>
> I would not say "typically"; I've only seen one compiler have this
> behavior by default (Microchip's C18), and the necessary code can be
> enabled.

SDCC seems to have that behavior. Usually static items show up as zero
on boot, but not always. I recently fixed a problem in one of my devices
where I had a 32bit variable that was used as an accumulator that then
got written to eprom. Every so often, the high bits of the eeprom value
would show up as set after a device reset, even though this was counting
keystrokes. Manually clearing that accumulator on boot fixed this.

> Clearing static storage is not optional in ANSI, even for embedded
> systems.

Well, compilers should make it possible o disable and not follow the
standards IMO. I've heard of a lot of embedded apps that requier fast
resets to save power and what not.

--
.....petespam_OUTspampetertodd.ca http://www.petertodd.ca

2006\02\22@124419 by Michael Rigby-Jones

picon face


{Quote hidden}

In every embedded C compiler I've used you have been free to write your own power up code and link it in place of the default code that the compiler vendor supplies.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2006\02\22@124420 by John Temples

flavicon
face
On Wed, 22 Feb 2006, Peter Todd wrote:

>> Clearing static storage is not optional in ANSI, even for embedded
>> systems.
>
> Well, compilers should make it possible o disable and not follow the
> standards IMO. I've heard of a lot of embedded apps that requier fast
> resets to save power and what not.

Every embedded compiler I've ever used includes the source to the
startup code so you can change it however you like.

--
John W. Temples, III

2006\02\22@125216 by Peter Todd

picon face
On Wed, Feb 22, 2006 at 05:44:13PM -0000, Michael Rigby-Jones wrote:
>> Clearing static storage is not optional in ANSI, even for embedded
> >> systems.
> >
> >Well, compilers should make it possible o disable and not
> >follow the standards IMO. I've heard of a lot of embedded apps
> >that requier fast resets to save power and what not.
>
> In every embedded C compiler I've used you have been free to write your own power up code and link it in place of the default code that the compiler vendor supplies.

To you and John:

Sounds like embedded compiler writers used a time machine to implement
my suggestion before I was even born... I feel so proud. :)

--
.....petespamRemoveMEpetertodd.ca http://www.petertodd.ca

2006\02\22@125821 by Wouter van Ooijen

face picon face
>> OK, so I'll just have to wait for all compilers for freestanding
>> embedded systems to allow 'void main(void)'.
>
> That's not going to happen, because you can't generalize about
> embedded systems.  That's why the standard was written the way it
> was.  I've used systems where main() was "int main(int argc, char
> *argv[])" because it was possible to pass "command line arguments" to
> the embedded target from an attached host and get a return value when
> main() exited.

That's a slaved embedded system, or rather a slaved part of it, not what
I would call a freestanding embedded system.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\22@143220 by William Killian

flavicon
face


> -----Original Message-----
> From: RemoveMEpiclist-bouncesspamspamBeGonemit.edu [spamBeGonepiclist-bounces@spam@spamspam_OUTmit.edu] On
Behalf
> Of John Temples
> Sent: Wednesday, February 22, 2006 11:40 AM
> To: Microcontroller discussion list - Public.
> Subject: RE: [PIC] 2 questions about 18f4550
>
> On Wed, 22 Feb 2006, William Killian wrote:
>
> > ANSI C specifies int main (int, char **) as that is what was
expected in
> > standard systems development.  This entry point was defined as what
the
> > compiler's linked to base would call.  That same code was what was
> > responsible for clearing extern class memory items to 0.  This is
also
{Quote hidden}

Clearing static storage in pretty much every embedded system I worked on
only happens when my written program clears it.  The loader that would
clear it isn't called if my code controls it from reset on.

> > One could write a C derivative with an extension for embedded
> > work where a new keyword would allow a function to be defined as a
tasks
>
> IAR does this with the __C_task extension.
>
> > to that can not return.  I now wonder if a reserved word, entry IRC,
had
> > originally been intended for that purpose.  The reserved word
interrupt
> > is defined to mean a function enters differently than a standard
> > function so another would be fine.
>
> "entry" and "interrupt" are not reserved words in standard C.

Reserved word interrupt or a variant is a common extension not a part of
ANSI C but none-the-less reserved in most compilers I've used.  One
variant in an 8051 compiler uses instead _interrupt.  GCC seems to use
interrupt_handler for some architectures/

Reserved word entry has been specifically dropped.  Or at least it was
very close to the word entry, my old K&R book is across the country from
me now.  No compiler I ever used implemented it.  Sorry I didn't
explicity state that it had been dropped.  I believe other reserved
words were dropped at the same time - might have been dropped for C83.
I just don't remember any more.





-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
TakeThisOuTpostmasterspamspamvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\22@145058 by William Killian

flavicon
face


> -----Original Message-----
> From: piclist-bouncesEraseMEspammit.edu [RemoveMEpiclist-bouncesEraseMEspamspam_OUTmit.edu] On
Behalf
> Of John Temples
> Sent: Wednesday, February 22, 2006 11:52 AM
> To: Microcontroller discussion list - Public.
> Subject: RE: [PIC] 2 questions about 18f4550
>
> On Wed, 22 Feb 2006, Wouter van Ooijen wrote:
>
> >> The 'int' is not required in a "freestanding" (embedded) system.
The
> >> standard places no requirements on the declaration, or even
existence
{Quote hidden}

TR 18037: Embedded C
WG14 is working on a TR on Embedded C. The latest draft, approved for
publication, is in document N1021.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1040.pdf

I didn't notice a bit type added.  But some standardization of machine
register access and fixed point (DSP code from mine background) is in
there.

Relatively few compilers are actually ANSI compliant in that the C99
additions to C90 were neglected in favor of C++ issues.


/listinfo/piclist


-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
@spam@postmasterRemoveMEspamEraseMEvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\22@145948 by David VanHorn

picon face
I've always done the memory clear as the first part of the init.
Not that I use variables without first loading them with something, but I've
always liked the idea of starting absolutely from a known state.

2006\02\22@200607 by kerri

flavicon
face
> By the way, Microchip's USB firmware is using MPLAB C18. So there
> will not be anything like "clr TRISA".
>
> And they are doing the following for the bootloader example
> (in file io_cfg.h).
> #define mInitAllLEDs()      LATD &= 0xF0; TRISD &= 0xF0;
>
> This is indeed questionable. It is correct to set RD0/1/2/3
> to output since they are for LED output. RD4/5/6/7 are not
> used so maybe it is better to set them as output and output 0
> if you do not have something connected to them in the final
> circuits. Take note this is only the bootloader. The
> use application hardware/software should take care of this.
>
> Regards,
> Xiaofan

Xiaofan,

I will tell you what happened, btw the touching issue is solved now,
but I don't understand why. Apparently it was pin38 which was
causing this. Now I connected it to gnd and the touching problem
is gone. Interestingly, if I connect it to 5v instead of gnd, the
bootloader doesn't start AT ALL. As you have seen yourself in
io_cfg.h there is no mention of pin38 (on the schematic it is S3,
the bootloader shares some hardware with the demonstartion
board, but the bootloader never uses S3) so I have no idea why
this is happening. Any ideas?
b.t.w.
I would like to thank everyone here, I really didn't ask well, but
now I believe everyone should understand. thanks.

2006\02\22@212653 by Chen Xiao Fan

face
flavicon
face


> -----Original Message-----
> From: EraseMEpiclist-bouncesspam@spam@mit.edu
> [@spam@piclist-bouncesspam_OUTspam.....mit.edu] On Behalf Of kerri
>
> I will tell you what happened, btw the touching issue is solved now,
> but I don't understand why. Apparently it was pin38 which was
> causing this. Now I connected it to gnd and the touching problem
> is gone. Interestingly, if I connect it to 5v instead of gnd, the
> bootloader doesn't start AT ALL. As you have seen yourself in
> io_cfg.h there is no mention of pin38 (on the schematic it is S3,
> the bootloader shares some hardware with the demonstartion
> board, but the bootloader never uses S3) so I have no idea why
> this is happening. Any ideas?
> b.t.w.
> I would like to thank everyone here, I really didn't ask well, but
> now I believe everyone should understand. thanks.

For 18F4550, pin 38 is either RD0 (for 44pin TQFP used in PICDEM FS
USB) or RB5/PGM for 40 pin DIP. So you are using the 40pin DIP
package.

Both RB4 and RB5 are defined as input in io_cfg.h. But the definitions
are not used in the boot firmware. I do not know what happened to your
board that you can not enter the bootload mode when connecting
RB5 to high. Have you checked your board to see if all connections
are correct.

#define mInitAllSwitches()  TRISBbits.TRISB4=1;TRISBbits.TRISB5=1;
#define mInitSwitch2()      TRISBbits.TRISB4=1;
#define mInitSwitch3()      TRISBbits.TRISB5=1;
#define sw2                 PORTBbits.RB4
#define sw3                 PORTBbits.RB5

The bootloader entry is using RB4 (S2). The firmware uses the
fact that RB4 is already being defined as input after reset.
I will generally not use this but redefine it again in the
code.

I have just made a partial PICDEM FS USB board (no RS232, no
temperature sensor, only bus powered). I connected S2/S3 as
per the schematics in the user guide and I do not have problem
entering the bootload mode. I think you should have pull-up
resistors for S2/S3.

Regards,
Xiaofan

2006\02\22@212844 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> I've used systems where main() was "int main(int argc, char *argv[])"
>> because it was possible to pass "command line arguments" to the
>> embedded target from an attached host and get a return value when
>> main() exited.
>
> That's a slaved embedded system, or rather a slaved part of it, not what
> I would call a freestanding embedded system.

Right... but isn't it cool that you don't need a different compiler when
you want to do a "slaved" system? I'd rather see this as a feature that can
be used if needed and not if not than something to gripe about. What is the
actual problem?

Gerhard

2006\02\22@213701 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> A better answer would be a deliberate way to define the top level program
> specified in the standard so that every compiler implementer wouldn't
> have to work around this differently.

See, now you're arguing in favor of standardization. I don't think I have
to quote your arguments against it in their entirety to make a point :)

I think the problem in this case is that C runs on so many different
systems with so many different processor architectures that a tight
specification of the startup code would make the standard startup code
unsuitable for many applications -- which then might just result in more
non-standard compilers rather than more similar compilers.

Maybe with compilers it's the same as it is with screwdrivers: you just
need to get the one that's right for the job. There are of course better
ones, and less good ones. And there are the ones with multiple bits -- but
they have disadvantages, too :)

Gerhard

2006\02\22@214539 by Gerhard Fiedler

picon face
William Killian wrote:

> Many compilers designed for embedded or even not allow you to eliminate
> most of the traditional stack frame through optimization phases.  One
> could write a C derivative with an extension for embedded work where a
> new keyword would allow a function to be defined as a tasks or reset
> condition entry point that is not called but instead branched to that
> can not return.  

I had a little parsing problem with these two sentences, but maybe this is
pertinent :)

Some PIC compilers are non-standard in that they don't use a real stack;
they create a static stack (and therefore a static call tree). This limits
some features, but it makes it easily possible that functions that are
called only once are not called, but jumped into, and they don't use a
return, but also a jump out.

Gerhard

2006\02\23@074625 by kerri

flavicon
face
{Quote hidden}

I may then have a problem on my board, however I have this question:
As you said RB4 and RB5 are defined as inputs, but are not trist_ed
into this mode because they are using the fact that ALL pins are input
anyway after reset, right? If so, it seems very strange that it is pin RB5
which seems to be sensitive to no pullup and the other pins (all the
other ports, about 32) are not having this problem. Try not pulling up
RB5, leave it unconneted, see if you get this problem, then if you do,
can you explain why RB5 is sensitive, rather than any other port pin
of which there are many.

Also, as you say yourself, microchip left all unused pins in input stage,
so it seems this is not the same as per the advice some people here
seem to be giving - to configure unused pins to output.

If I am repeating myself I am sorry, I just want to make sure that
I am being understood. Thanks.

>
> I have just made a partial PICDEM FS USB board (no RS232, no
> temperature sensor, only bus powered). I connected S2/S3 as
> per the schematics in the user guide and I do not have problem
> entering the bootload mode. I think you should have pull-up
> resistors for S2/S3.
>
> Regards,
> Xiaofan

2006\02\23@081354 by olin piclist

face picon face
Gerhard Fiedler wrote:
> See, now you're arguing in favor of standardization. I don't think I
> have to quote your arguments against it in their entirety to make a
> point :)

You have totally misunderstood what I previously said.  I never argued
against standardization.  I was objecting to your implicit and sometimes
overt characterization that people refusing to switch to standards now were
being stupid.  I tried to explain how we got here and that these descision
were largely reasonable, not that the outcome is necessarily desirable or
that standards are bad.

> I think the problem in this case is that C runs on so many different
> systems with so many different processor architectures that a tight
> specification of the startup code would make the standard startup code
> unsuitable for many applications -- which then might just result in more
> non-standard compilers rather than more similar compilers.

All I was suggesting was a syntax to define a GOTO entry point as apposed to
a CALL entry point.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\02\23@082736 by Xiaofan Chen

face picon face
On 2/23/06, kerri <spamBeGonekerri1111111EraseMEspambtinternet.com> wrote:
>
> I may then have a problem on my board, however I have this question:
> As you said RB4 and RB5 are defined as inputs, but are not trist_ed
> into this mode because they are using the fact that ALL pins are input
> anyway after reset, right? If so, it seems very strange that it is pin RB5
> which seems to be sensitive to no pullup and the other pins (all the
> other ports, about 32) are not having this problem. Try not pulling up
> RB5, leave it unconneted, see if you get this problem, then if you do,
> can you explain why RB5 is sensitive, rather than any other port pin
> of which there are many.
>
> Also, as you say yourself, microchip left all unused pins in input stage,
> so it seems this is not the same as per the advice some people here
> seem to be giving - to configure unused pins to output.
>
> If I am repeating myself I am sorry, I just want to make sure that
> I am being understood. Thanks.
>

To put unused pin to defined status is a good engineering practise.
To do that you can do the following two things:
1) to configure the unused pin as input and use pull-up/pull-down
resistor to put them into define status (high or low).

2) to config the unused pin as output and then output high or low to
put them into defined status (high or low).

If you do not do this, there is no guarantee that it would work or
would not work in certain situationns. In this case, RB5 causes problem
for you. In another case, maybe another pin causes you problems.
Worstly, it may not cause problems during testing stage but the
problems may pop up in the field.

Microchip's board is a demo board. It may or may not follow good
engineering practise but generally they serve their purpose well.
But there are some ugly application notes out there as well. In this
paticular case, it is a bootloader. It is the user's repsonsibility to
design the hardware/firmware to use the bootloader or modify it.


Regards,
Xiaofan

2006\02\23@094246 by Jan-Erik Soderholm

face picon face
kerri wrote :

> it seems very strange that it is pin RB5
> which seems to be sensitive to no pullup...

If you have LVP enabled in your CONFIG, RB5/PGM
*have* to be low to not enter LVP mode.

> Also, as you say yourself, microchip left all unused pins in
> input stage, so it seems this is not the same as per the
> advice some people here seem to be giving - to configure
> unused pins to output.

And you are *STILL* mixing up what is reasonable to do
at *RESET* (that is, set all pins as inputs), and what whould
be done in a particular *DESIGN* with "unused" pins (that is
set them as output *or* add pull up/down resistors).

Regards,
Jan-Erik.



2006\02\23@103701 by William Killian

flavicon
face


> -----Original Message-----
> From: piclist-bouncesspamBeGonespammit.edu [RemoveMEpiclist-bounces@spam@spamspamBeGonemit.edu] On
Behalf
> Of Gerhard Fiedler
> Sent: Wednesday, February 22, 2006 9:45 PM
> To: .....piclist@spam@spamEraseMEmit.edu
> Subject: Re: [PIC] 2 questions about 18f4550
>
> William Killian wrote:
>
> > Many compilers designed for embedded or even not allow you to
eliminate
> > most of the traditional stack frame through optimization phases.
One
> > could write a C derivative with an extension for embedded work where
a
> > new keyword would allow a function to be defined as a tasks or reset
> > condition entry point that is not called but instead branched to
that
> > can not return.
>
> I had a little parsing problem with these two sentences, but maybe
this is
> pertinent :)
>
> Some PIC compilers are non-standard in that they don't use a real
stack;
> they create a static stack (and therefore a static call tree). This
limits
> some features, but it makes it easily possible that functions that are
> called only once are not called, but jumped into, and they don't use a
> return, but also a jump out.

PICs with their very small RAM space are not really suitable for
standard C approach.  Thus the unusual call and return approach.  But
nothing in the C definition requires the actual call and return assembly
instructions be used.  As long as it works enough like call and return
it is okay.

There is an ISO committee working on a standard embedded extension for
ISO C (mostly supplanting ANSI C as we're all globalized now and don't
need American ownership of the process.  Did you know that?  Thought you
might.)

An extension could be something like 'no_return' as in use entry instead
of no-return for a function that starts off the whole processor for
reboot or any task that can not return - for multi-tasking systems any
of the task entry points. Another extension could be forcing this
'function' to an absolute address.  That embedded committee is putting
in things to allow memory partitioning so that might very well be
enough.

Something like:
 noreturn reset (void)
 {
   /* do system init stuff */
   or (;;)
   {
     main_body();
   }
 }



-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
.....postmasterRemoveMEspamvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\23@141331 by Bill & Pookie

picon face
Defining code within a subroutine reminds me of the tombstone in Silicon
Valley ;

LDA              Life
GOSUB        Death

Pookie

{Original Message removed}

2006\02\23@153812 by kerri

flavicon
face
> Microchip's board is a demo board. It may or may not follow good
> engineering practise but generally they serve their purpose well.
> But there are some ugly application notes out there as well. In this
> paticular case, it is a bootloader. It is the user's repsonsibility to
> design the hardware/firmware to use the bootloader or modify it.

Why do you think the board does not have the pullups for the
unused pins?

>
>
> Regards,
> Xiaofan

2006\02\23@160753 by piclist

flavicon
face
On Thu, 23 Feb 2006, William Killian wrote:

> An extension could be something like 'no_return' as in use entry instead
> of no-return for a function that starts off the whole processor for
> reboot or any task that can not return

Any reasonable compiler will do that automatically, without any
special keywords.

--
John W. Temples, III

2006\02\23@164834 by William Killian

flavicon
face


> -----Original Message-----
> From: .....piclist-bouncesSTOPspamspam@spam@mit.edu [piclist-bouncesEraseMEspam@spam@mit.edu] On
Behalf
> Of RemoveMEpiclistspamspamBeGonexargs.com
> Sent: Thursday, February 23, 2006 4:08 PM
> To: Microcontroller discussion list - Public.
> Subject: RE: [PIC] 2 questions about 18f4550
>
> On Thu, 23 Feb 2006, William Killian wrote:
>
> > An extension could be something like 'no_return' as in use entry
instead
> > of no-return for a function that starts off the whole processor for
> > reboot or any task that can not return
>
> Any reasonable compiler will do that automatically, without any
> special keywords.

Boy are people getting more and more sure of compiler technologies these
days.  I'm not so overly confident especially as languages that started
simple like C continue to get more elaborate with each new standards
release.

But please name any compiler that will automatically not generate a
return statement at the end of a function.

I don't know how the PIC compilers handle automatic variables but they
are 'created' and 'destroyed' at the beginning and end of a function so
would there be unreachable code put in to fix the 'stack' as well?

And these compilers, which are indeed getting better at many things but
with much angst along the way, could use such a construct to generate
warnings and/or errors for simple things like a return statement in the
function of a path to the end of the function.




-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
spamBeGonepostmasterKILLspamspam@spam@vgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\23@165112 by Jan-Erik Soderholm

face picon face
kerri wrote :

> Why do you think the board does not have the pullups for the
> unused pins?

Mayve becaus the designer of the board didn't know at
design-time what pins would be "unsued" in *your* application.

Regards,
Jan-Erik.



2006\02\23@182145 by kerri

flavicon
face
> > Why do you think the board does not have the pullups for the
> > unused pins?
>
> Mayve becaus the designer of the board didn't know at
> design-time what pins would be "unsued" in *your* application.

The board is a programmer, wouldn't you want your
programmer to be properly made?

>
> Regards,
> Jan-Erik.

2006\02\23@200418 by Gerhard Fiedler

picon face
William Killian wrote:

> PICs with their very small RAM space are not really suitable for standard
> C approach.  Thus the unusual call and return approach.  

It's not the missing RAM, actually, it's the lack of hardware support for a
traditional (RAM based) stack.

> But nothing in the C definition requires the actual call and return
> assembly instructions be used.  As long as it works enough like call and
> return it is okay.

Well, the thing is that a static call tree does work "enough like call and
return" only if you don't use a few standard features, like recursion (not
really a favorite of mine in embedded systems) and function pointers (which
I'm sometimes missing).

So I guess this is actually non-standard. But reasonably so, in this case.

Gerhard

2006\02\23@202045 by Gerhard Fiedler

picon face
William Killian wrote:

> But please name any compiler that will automatically not generate a
> return statement at the end of a function.

HiTech PICC-18 for example (and probably PICC, too, as they are pretty
similar). There probably are others.

> I don't know how the PIC compilers handle automatic variables but they
> are 'created' and 'destroyed' at the beginning and end of a function so
> would there be unreachable code put in to fix the 'stack' as well?

It doesn't sound as if you were familiar with the concept of a static,
compiled "stack". There is no stack to "fix", variables don't get created
and destroyed like with a normal, stack-based C implementation.

Every function has a fixed starting location for local variables in the
memory area set aside for its "variable stack". Which means in essence that
every local variable has a pre-determined address that doesn't change from
one call to the function to the next. This starting location of the
"variable stack" is determined at link time, from the static call tree and
the space requirements for each function. (That's why recursion is not
possible with this method, and there are limits for the use of function
pointers.)


> This message contains confidential information and is intended only for
> the individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail.

??? I couldn't help but not take this seriously in replying to the
message...

Gerhard

2006\02\23@204751 by piclist

flavicon
face
On Thu, 23 Feb 2006, Gerhard Fiedler wrote:

> Well, the thing is that a static call tree does work "enough like call and
> return" only if you don't use a few standard features, like recursion (not
> really a favorite of mine in embedded systems) and function pointers (which
> I'm sometimes missing).

Function pointers work fine with a compiled stack, at least on
Hi-Tech.  I don't think the feature is implemented on C18, though.

--
John W. Temples, III

2006\02\23@221712 by Gerhard Fiedler

picon face
piclist@xargs.com wrote:

>> Well, the thing is that a static call tree does work "enough like call and
>> return" only if you don't use a few standard features, like recursion (not
>> really a favorite of mine in embedded systems) and function pointers (which
>> I'm sometimes missing).
>
> Function pointers work fine with a compiled stack, at least on
> Hi-Tech.  I don't think the feature is implemented on C18, though.

They kind of work (with HiTech compilers PICC/PICC18), but they are limited
in their functionality. AFAIK, no two pointers may refer to functions with
the same "signature".

This makes sense, as calculating a static call stack becomes practically
impossible if you allow normal function pointer functionality (with all the
"usual" tricks like casting integers to function pointers :)

Gerhard

2006\02\23@232343 by John Temples

flavicon
face
On Fri, 24 Feb 2006, Gerhard Fiedler wrote:

>> Function pointers work fine with a compiled stack, at least on
>> Hi-Tech.  I don't think the feature is implemented on C18, though.
>
> They kind of work (with HiTech compilers PICC/PICC18), but they are limited
> in their functionality. AFAIK, no two pointers may refer to functions with
> the same "signature".

In general that's not true; you only get in trouble if you use the
pointers in such a way that the linker can't tell if you're trying to
be recursive or not (function pointers calling functions that call
through function pointers).  I've never run across that limitation in
real-world usage of using multiple pointers pointing at functions with
not just the same signature, but the same type.

--
John W. Temples, III

2006\02\24@062316 by Gerhard Fiedler

picon face
John Temples wrote:

>>> Function pointers ...
>>
>> They kind of work (with HiTech compilers PICC/PICC18), but they are limited
>> in their functionality. AFAIK, no two pointers may refer to functions with
>> the same "signature".
>
> In general that's not true; you only get in trouble if you use the
> pointers in such a way that the linker can't tell if you're trying to
> be recursive or not (function pointers calling functions that call
> through function pointers).  I've never run across that limitation in
> real-world usage of using multiple pointers pointing at functions with
> not just the same signature, but the same type.

Last time I used them I ran exactly into that: the compiler was thinking
"uh-oh recursive" when there was nothing recursive. Since it is not (to my
knowledge) documented what the conditions are under which they work and
under which not, I thought that I'd better do it without them. I don't like
having to "experiment" with a compiler to find out what structures work...

Gerhard

2006\02\24@075731 by Jan-Erik Soderholm

face picon face
kerri wrote :

> > Mayve becaus the designer of the board didn't know at
> > design-time what pins would be "unsued" in *your* application.
>
> The board is a programmer, wouldn't you want your
> programmer to be properly made?

Never mind, I'll leave now.
I'm tired of searching throught masive amounts of
compilers internals to find your posts...

Jan-Erik.
>



2006\02\24@102830 by William Killian

flavicon
face


> -----Original Message-----
> From: piclist-bouncesspam_OUTspam@spam@mit.edu [spamBeGonepiclist-bounces@spam@spammit.edu] On
Behalf
{Quote hidden}

for
> a
> traditional (RAM based) stack.
>
> > But nothing in the C definition requires the actual call and return
> > assembly instructions be used.  As long as it works enough like call
and
> > return it is okay.
>
> Well, the thing is that a static call tree does work "enough like call
and
> return" only if you don't use a few standard features, like recursion
(not
> really a favorite of mine in embedded systems) and function pointers
> (which
> I'm sometimes missing).
>
> So I guess this is actually non-standard. But reasonably so, in this
case.

I've only just started messing with PIC.  The RAM space and lack of a
stack I'm sure are related.  You don't need much RAM if you don't do a
call stack and you don't implement a standard stack if you don't have
enough RAM.  Obviously it can be faked.

I do use recursion in embedded work, but it is usually a very limited
form where I know it will only go only to a second call.  But I tend to
come up with approaches that are not text book cookie cutter approaches
and end up far simpler and are noted for ease of maintenance.















>
> Gerhard
>
> --
>
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist


-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
spamBeGonepostmasterspam_OUTspamRemoveMEvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\24@104325 by William Killian

flavicon
face


> -----Original Message-----
> From: .....piclist-bouncesspamRemoveMEmit.edu [piclist-bouncesspam@spam@mit.edu] On
Behalf
{Quote hidden}

they
> > are 'created' and 'destroyed' at the beginning and end of a function
so
> > would there be unreachable code put in to fix the 'stack' as well?
>
> It doesn't sound as if you were familiar with the concept of a static,
> compiled "stack". There is no stack to "fix", variables don't get
created
> and destroyed like with a normal, stack-based C implementation.
>
> Every function has a fixed starting location for local variables in
the
> memory area set aside for its "variable stack". Which means in essence
> that
> every local variable has a pre-determined address that doesn't change
from
> one call to the function to the next. This starting location of the
> "variable stack" is determined at link time, from the static call tree
and
> the space requirements for each function. (That's why recursion is not
> possible with this method, and there are limits for the use of
function
> pointers.)

Which is why I call these C derivatives and thus C-like as much as C.
They will not behave the same as a more traditional C implementation in
some cases.  Old Tiny-C was another language more C-like than truly C.  

We will hit semantics here.  Since this PICC C does several things that
are not C it effectively gives the feature of no entrance and exit stack
code at the loss of other features many of us might call significant at
times.  Yeah I want both - maybe not in the PIC but in all the other
processors.  PICS lack a lot of features that would make PIC C far more
like C in other environments.  

I've very seldom used real numbers for example in embedded work but have
a hard time calling a compiler a C compiler if it doesn't support them.

> > This message contains confidential information and is intended only
for
> > the individual named. If you are not the named addressee you should
not
> > disseminate, distribute or copy this e-mail.
>
> ??? I couldn't help but not take this seriously in replying to the
> message...

Blame the IT department here.  I'm a firm believer that engineering and
production networks are not the same.  This is a production network
manager trying to corral us engineers.  That statement is glommed on by
the exchange server.  It is ridiculous isn't it?  And look there it will
be again below I bet.


-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
RemoveMEpostmasterKILLspamspamTakeThisOuTvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...