>2&file=3Dviewtopic&t=3D380...
>>
>> ,it's possible to write directly into the program memory section in
AVR
>> controller ,I would like to know whether it is possible to follow a
>> similar kind of procedure for PIC controllers as well.
>
>After looking at the link you posted, it looks to me like you want to
>know how to store C language constants in flash memory? That is, you
>want to compile them into your code, and burn them into the target
>chip at the same time you download your program, right?
>
>That is certainly possible with the PIC24/dsPIC devices. They have a
>special architecture that lets you map the 24-bit program memory bus
>over to the 16-bit data memory bus. I think this is called Program
>Visibility, or something like that. C30 handles that for you
>automatically.
>
>There's actually 2 ways to view program memory as data on that chip
>family. The other is via a special table assembler instruction. C30
>supports both of these, and you don't have to know the underlying
>details.
>
>const char buf[] =3D "abc"; // constant data is stored in flash and
>accessed automatically via Program Visibility (you write zero code)
>
>char buf[] =3D "abc"; // this is an initialized value. It's stored in
>flash and copied to RAM in the startup code. That uses the table
>method internally. This is a little more memory efficient because it
>can use every byte of flash. The Program Visibility method actually
>wastes 1 byte out of every 3 because 24 bits don't map directly to 16
>bits. But Program Visibility lets you directly read flash data at
>runtime without first copying them over to RAM, which is needed with
>non-consts.
>
>My discussion above does NOT tell you how to write to flash memory at
>runtime. This is strictly a discusssion of how to store constants in
>flash at the time you download your program to the chip. Writing to
>flash at runtime is much harder.
>
>Eric
>
>
Thanks for all the info , the two methods that you described work fine ,
but I was actually for a way by which I could store some constants into
the chip independent of the program itself, ie I do not have to write the
data variables in the program itself, but download the variables in the
program flash directly.
Reply by aroravaibhav87●January 9, 20082008-01-09
>On Jan 2, 11:23=A0am, "aroravaibhav87" <aroravaibha...@gmail.com> wrote:
>> With reference to the
>2&file=3Dviewtopic&t=3D380...
>>
>> ,it's possible to write directly into the program memory section in
AVR
>> controller ,I would like to know whether it is possible to follow a
>> similar kind of procedure for PIC controllers as well.
>
>After looking at the link you posted, it looks to me like you want to
>know how to store C language constants in flash memory? That is, you
>want to compile them into your code, and burn them into the target
>chip at the same time you download your program, right?
>
>That is certainly possible with the PIC24/dsPIC devices. They have a
>special architecture that lets you map the 24-bit program memory bus
>over to the 16-bit data memory bus. I think this is called Program
>Visibility, or something like that. C30 handles that for you
>automatically.
>
>There's actually 2 ways to view program memory as data on that chip
>family. The other is via a special table assembler instruction. C30
>supports both of these, and you don't have to know the underlying
>details.
>
>const char buf[] =3D "abc"; // constant data is stored in flash and
>accessed automatically via Program Visibility (you write zero code)
>
>char buf[] =3D "abc"; // this is an initialized value. It's stored in
>flash and copied to RAM in the startup code. That uses the table
>method internally. This is a little more memory efficient because it
>can use every byte of flash. The Program Visibility method actually
>wastes 1 byte out of every 3 because 24 bits don't map directly to 16
>bits. But Program Visibility lets you directly read flash data at
>runtime without first copying them over to RAM, which is needed with
>non-consts.
>
>My discussion above does NOT tell you how to write to flash memory at
>runtime. This is strictly a discusssion of how to store constants in
>flash at the time you download your program to the chip. Writing to
>flash at runtime is much harder.
>
>Eric
>
>
Thanks for all the info , the two methods that you described work fine ,
but I was actually for a way by which I could store some constants into
the chip independent of the program itself, ie I do not have to write the
data variables in the program itself, but download the variables in the
program flash directly.
Reply by Chris H●January 4, 20082008-01-04
In message
<d1c3c5ab-85d2-4bf8-b031-7b3ac2fc8b22@f3g2000hsg.googlegroups.com>,
larwe <zwsdotcom@gmail.com> writes
>On Jan 4, 1:35�pm, Chris H <ch...@phaedsys.org> wrote:
>
>> I thought that until some one sent me a link to the case history. �Turns
>> out McDonnell's were intentionally running their coffee some 20 degrees
>> hotter than anyone else for reasons of storage life when brewed. �On a
>
>Tip of the iceberg, as far as lawsuits vs. frivolity go.
Yes.
>BTW that story was always very counter-intuitive to me - I would
>expect that increasing the temp would REDUCE the shelf life. Very
>strange.
Me too. Never did work it out.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by larwe●January 4, 20082008-01-04
On Jan 4, 1:35=A0pm, Chris H <ch...@phaedsys.org> wrote:
> I thought that until some one sent me a link to the case history. =A0Turns=
> out McDonnell's were intentionally running their coffee some 20 degrees
> hotter than anyone else for reasons of storage life when brewed. =A0On a
Tip of the iceberg, as far as lawsuits vs. frivolity go.
BTW that story was always very counter-intuitive to me - I would
expect that increasing the temp would REDUCE the shelf life. Very
strange.
Reply by Chris H●January 4, 20082008-01-04
In message
<a8dc4bfb-b216-4e8c-8fbe-52dfd6546fef@r60g2000hsc.googlegroups.com>,
Eric <englere_geo@yahoo.com> writes
>On Jan 3, 9:51�am, larwe <zwsdot...@gmail.com> wrote:
>
>> Caution: microwave meal will be hot after heating.
>
>Don't forget that hot coffee is also served hot. I saw a message to
>that effect in the McDonalds drive-through recently.
>
>Why is it that lawyers were only born with half a brain?
I thought that until some one sent me a link to the case history. Turns
out McDonnell's were intentionally running their coffee some 20 degrees
hotter than anyone else for reasons of storage life when brewed. On a
drive through where spillage is more likely burns from MacDonalds coffee
would be (and were) substantially worse than any other coffee shop.
Hence the "scalded by a hot cup of coffee" law suite. And the
complainant won against McD I believe.
This is why McDonalds put the signs up (and had to set the temperature
on the coffee some 20 degrees lower).
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by larwe●January 4, 20082008-01-04
On Jan 4, 1:19=A0pm, Eric <englere_...@yahoo.com> wrote:
> Don't forget that hot coffee is also served hot. I saw a message to
> that effect in the McDonalds drive-through recently.
Starbucks cups say something like "The beverage you are about to enjoy
is extremely hot". I'd like to revise that text, surreptitiously, to
something more of the order of "Caution: The beverage you will shortly
be raising to your lips, while capable of conveying your taste and
olfactory senses unto the utmost seventh heaven of ecstasy, will
simultaneously scald, sear and deglove your tongue with the
excruciating pain of a beverage dipped directly from a lake in hell".
> Why is it that lawyers were only born with half a brain?
Judges and juries, not lawyers, are the root of this evil. Without
those credulous simpletons roaming the streets ready to judge in favor
of massive damages for ludicrous lawsuits, we would not need such
disclaimers, and liability insurance would be pennies per month.
Lawyers are the facilitators, not the cause, of stupidity.
Reply by Eric●January 4, 20082008-01-04
On Jan 2, 11:23=A0am, "aroravaibhav87" <aroravaibha...@gmail.com> wrote:
>
> ,it's possible to write directly into the program memory section in AVR
> controller ,I would like to know whether it is possible to follow a
> similar kind of procedure for PIC controllers as well.
After looking at the link you posted, it looks to me like you want to
know how to store C language constants in flash memory? That is, you
want to compile them into your code, and burn them into the target
chip at the same time you download your program, right?
That is certainly possible with the PIC24/dsPIC devices. They have a
special architecture that lets you map the 24-bit program memory bus
over to the 16-bit data memory bus. I think this is called Program
Visibility, or something like that. C30 handles that for you
automatically.
There's actually 2 ways to view program memory as data on that chip
family. The other is via a special table assembler instruction. C30
supports both of these, and you don't have to know the underlying
details.
const char buf[] =3D "abc"; // constant data is stored in flash and
accessed automatically via Program Visibility (you write zero code)
char buf[] =3D "abc"; // this is an initialized value. It's stored in
flash and copied to RAM in the startup code. That uses the table
method internally. This is a little more memory efficient because it
can use every byte of flash. The Program Visibility method actually
wastes 1 byte out of every 3 because 24 bits don't map directly to 16
bits. But Program Visibility lets you directly read flash data at
runtime without first copying them over to RAM, which is needed with
non-consts.
My discussion above does NOT tell you how to write to flash memory at
runtime. This is strictly a discusssion of how to store constants in
flash at the time you download your program to the chip. Writing to
flash at runtime is much harder.
Eric
Reply by Eric●January 4, 20082008-01-04
On Jan 3, 9:51=A0am, larwe <zwsdot...@gmail.com> wrote:
> Caution: microwave meal will be hot after heating.
Don't forget that hot coffee is also served hot. I saw a message to
that effect in the McDonalds drive-through recently.
Why is it that lawyers were only born with half a brain?
Eric
Reply by larwe●January 3, 20082008-01-03
On Jan 3, 12:14=A0am, Dan Henry <use...@danlhenry.com> wrote:
> The procedures for other PIC families are likewise described in their
> respective reference manuals and data sheets.
You forgot some text: Your mileage may vary. This posting contains
forward-looking statements within the meaning of the Private
Securities Litigation Reform Act of 1995. Such statements are based
upon the current beliefs and expectations of Usenet and are subject to
significant risks and uncertainties. Actual results may differ from
those set forth in the forward-looking statements. May lose value. Not
FDIC insured. Caution: microwave meal will be hot after heating.
Reply by Dan Henry●January 3, 20082008-01-03
On Wed, 02 Jan 2008 23:01:56 -0600, "aroravaibhav87"
<aroravaibhav87@gmail.com> wrote:
>>On Wed, 02 Jan 2008 10:23:17 -0600, "aroravaibhav87"
>><aroravaibhav87@gmail.com> wrote:
>>
>>>Hi!
>>>
>>>With reference to the doc
>>>http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=38003&start=all&postdays=0&postorder=asc
>>>
>>>,it's possible to write directly into the program memory section in AVR
>>>controller ,I would like to know whether it is possible to follow a
>>>similar kind of procedure for PIC controllers as well.
>>
>>Some PICs yes, some PICs no. Name your PIC.
>>
>>--
>>Dan Henry
>>
>
>currently I am using PIC 30F series ( 30F2010 ),
>but even if it does not support that feature I would be interested in
>knowing the procedure for writing data directly into the prog mem of other
>PICs , as I might switch over to some other PIC .
Programming PIC 30F series flash is described in the reference manual
section(s) downloadable from Microchip. You also need to consult the
data sheet for your particular device since row lengths may vary.
The procedures for other PIC families are likewise described in their
respective reference manuals and data sheets.
--
Dan Henry