Post by thread:[PIC]:Cryptic data directives

I´m planning to use strings on the F877 for the first time and use it´s ability to store two 7-bit ascii in each program word. However I can´t find some clear descriptions on the differences between the MPASM directives DATA, DA, DW, DB, and MPASM help is very unclear. I wish to learn all data directives and their use once and for all. I have done simple experiments and searched for documents, but can´t nail it down. I know i have read it somewhere but have forgotten where. Can somebody please give me a hint? /Morgan Morgan Olsson spam_OUTmorgans.rtTakeThisOuTtelia.com Morgans Reglerteknik, Hällekås, 277 35 KIVIK, SWEDEN tel +46(0)414-446620, fax +46(0)414-672324 -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Look in the MPASM user's guide. There they have the descriptions as well as the "syntax". Best regards, Steve Steven Kosmerchock Radio Frequency Systems Phoenix, Arizona USA (WORK) http://www.rfsamericas.com http://www.geocities.com/researchtriangle/lab/6584 "Great spirits have always encountered violent oppposition from mediocre minds."--A.Einstein {Original Message removed}

Kosmerchock, Steve wrote: >Look in the MPASM user's guide Oh, thanks, I thought I did not have one but you made me look in the ICD box, and there it was. Apparently it is the DA directive we are supposed to use for storing strings in 14bit program words. So I tried, and now I am even more confused.... I read in MPASM user´s guide DS33014G, page 44: " da "abcdef" will put 30E2 31E4 32E6 3380 into program memory " Happily I tested and it worked like told, except the last word "3380" did not get generated!? i tested da "abcdefg", (added "g") and now also the "3380" do get generated, meaning "abcdef" is generated, but not "g". weird. OK, I left that cooking a while, and added the next line in the given example: " da "12345678",0 will put 18B2 19B4 1AB6 0000 into program memory " I read that several times. Do you see th efunny thing: Microchip example say only "123456" get put into memory, then it skips "78", then add a word "0". OK, I typed the example in, but now MPASM generates it all: 18B2 19B4 1AB6 1BB8 0000, note the "1BB8" Go figure... I can´t se anywhere they explain why MPLAB sometimes do not compile two characters, and sometimes do, nor can i anderstand why that mechanism is reversed from the book when i compile thet exact example. AAAAHHH I don´t get it! Somebody have a clue? BTW, testing is done using latest MPLAB 5,20, including MPASM 2.61, and compiling a project for a PIC16F877 by adding to a working project. /Morgan -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

I wrote: >I read in MPASM user´s guide DS33014G, page 44: >" >da "abcdef" >will put 30E2 31E4 32E6 3380 into program memory >" > >Happily I tested and it worked like told, except the last word "3380" did not get generated!? Actually the six letters shall only generate three program word, right, byt why do th eexample show a fourth?? >i tested da "abcdefg", (added "g") and now also the "3380" do get generated, meaning "abcdef" is generated, but not "g". weird. Wrong, it is the "g" that is generated. Seems just Micrichip ment to type "abcdefg" but lost the "g" in the manual. I now have tested "abcdefgh" and now it generates 30E2 31E4 32E6 33E8, which looks OK, but i have not evaluated. Probably the next weird thing I described is also a typo by Microchip, but now they forgot the whole generated word "1BB8" Two errors in two consecutive examples! That is definately *not* aiding their users... Don´t they proof read before printing? Yuck! Is maybe a newer revision on the web? I could not find. /Morgan -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Oh, and on the subject of data directives: from MPASM 2.61 readme: ------------8<------------- KNOWN PROBLEMS ---------------------------------------------------------------------- SSR 4049: Default radix setting does not affect macros. Macros definitions will not overwrite the radix set in the list directive. SSR 4065: MPASM assembler will word align DB's and DW's. The work-around is to enter all DB's on one line, breaking the line at a word boundary. ------------8<------------- I just don´t understand about DW. Can it be NOT word aligned?? /Morgan -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Morgan Olsson wrote: > Two errors in two consecutive examples! That is definately *not* aiding their users... > > Don4t they proof read before printing? Nope. The manuals, particularly examples, are filled with errors, revision after revision. There are also lots of other 'gotchas'. That's why this list is so popular <G>. Robert -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Morgan Olsson wrote: > > Oh, and on the subject of data directives: > from MPASM 2.61 readme: > KNOWN PROBLEMS > ---------------------------------------------------------------------- > SSR 4049: Default radix setting does not affect macros. Macros definitions > will not overwrite the radix set in the list directive. > > SSR 4065: MPASM assembler will word align DB's and DW's. The work-around > is to enter all DB's on one line, breaking the line at a word boundary. > ------------8<------------- > > I just don4t understand about DW. Can it be NOT word aligned?? Have a DB, then a DW. On some processors (8086?) a word can be fetched across an address boundary, but it slows down the fetch. Since the PICs don't have the architecture to support this, word boundaries are forced on all data fetches. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.