Searching \ for '[PIC] db : odd number of expressions, last byte wi' 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=pic
Search entire site for: 'db : odd number of expressions, last byte wi'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] db : odd number of expressions, last byte wi'
2005\04\28@204454 by Jan Wagemakers

flavicon
face
Hello,

I have a problem with a PIC18f452 program. It is written in asm and I make
use of gpasm (0.13.1).

The problem is that when I use a "db" line with an odd number of
expressions, a extra byte with value 0 will be added. According to the
documentation(*1) that I have read this is normal behavior. I have also read
that it is possible to disable this feature with "code_pack".

However, When I try to use "code_pack" it doesn't seems to work (maybe gpasm
doesn't understand "code_pack"?).

My questions:
1. Does gpasm understand "code_pack" and if yes, how do I use it?
  (google for "gpasm code_pack" gives me no results)
2. Is there some other method that I can use to disable this 'feature'?


(*1)
| 5.13 DB � Declare Data of One Byte
|
|    5.13.1 Syntax
|
|           [<label>] db <expr>[,<expr>,...,<expr>]
|
|    5.13.2 Description
|
|           Reserve program memory words with packed 8-bit values. Multiple
|           expressions continue to fill bytes consecutively until the end
|           of expressions. Should there be an odd number of expressions,
|           the last byte will be zero. When generating an object file,
|           this directive can also be used to declare initialized data
|           values. Refer to the IDATA directive for more information.


-- Met vriendelijke groetjes         - Jan Wagemakers -

... RFS: picprog: Microchip PIC serial programmer software (GPL)
   Deb-package is available at <http://www.janw.easynet.be/picprog.html>

2005\04\29@033003 by Jan-Erik Soderholm

face picon face
Jan Wagemakers wrote :

> I have a problem with a PIC18f452 program. It is written in
> asm and I make use of gpasm (0.13.1).
>
> The problem is that when I use a "db" line with an odd number of
> expressions, a extra byte with value 0 will be added.
> According to the documentation(*1) that I have read this is
> normal behavior.

And if so, what is the problem ?
Why do you want to get rid of it ?
What do you want to use the "odd" byte for ?

Jan-Erik.



2005\04\29@114031 by Jan Wagemakers

flavicon
face
Jan-Erik Soderholm schreef: >> The problem is that when I use a "db" line with an odd number of >> expressions, a extra byte with value 0 will be added. >> According to the documentation(*1) that I have read this is >> normal behavior. > And if so, what is the problem ? > Why do you want to get rid of it ? > What do you want to use the "odd" byte for ? Mmm, sorry if my question wasn't clear. I have connected a PIC18f452 to a 3COM 3C509b isa network card(*). I have build a little webserver in this PIC18f452, but have some problems with this extra zero byte. I'll try to explain. The webpage is located in program-memory like this : web db "HTTP/1.0 200 OK", H'0A' db "Server: PIC18F452 + 3COM 3C509b", H'0A' db "Content-type: text/html", H'0A' db H'0A', H'0A' index db "", H'0A' db " ", H'0A' db " ", H'0A' db "", H'0A' db "PIC18f452 + 3COM 3C509B - Webserver - ", H'0A' db "", H'0A' db "", H'0A' db " ", H'0A' db "
", H'0A' db "

PIC18f452 + 3COM 3C509B - Webserver -

", H'0A' db "
", H'0A' db "
", H'0A' db "

", H'0A' db "This website is brought to you by a webserver that is running on a ", H'0A' db "PIC18F452 connected to a 3COM 3C509B ethernet card.", H'0A' db "

", H'0A' db "", H'0A' db "
", H'0A' db "", H'0A' db "", H'0A' db " ", H'0A', D'000' To transmit this webpage I use the following code : ; Dataveld aanpassen : Webpagina in dataveld plaatsen lfsr 1, TCP_start + D'20' ; TCP-header = 20 movlw B'00001111' andwf TCP_data_offset, f ; 4 hoogste bits = TCP_data_offset : reset movlw B'01010000' iorwf TCP_data_offset, f ; TCP_data_offset = 5 (5 32bitswords = 20 bytes) movlw LOW (web) movwf TBLPTRL movlw HIGH (web) movwf TBLPTRH movlw UPPER (web) movwf TBLPTRU ; TBLPTR --> web t1: tblrd*+ ; Lees van adres TBLPTR in TABLAT / TBLPTR++ movf TABLAT, w ; w = het ingelezen karakter iorlw D'0' ; End Of Text? ASCII 0 btfsc STATUS, Z ; Als ASCII 0 dan ... bra t2 ; ... stop. movwf POSTINC1 ; kopieer karakter naar TCP_DATA / FSR1++ bra t1 t2: ; FSR1H:FSR1L = einde data Now, this works without problems, but only when each db-line contains a even number of bytes. Thats why I have inserted a extra space in certain lines. For example, if I change db " ", H'0A' db " ", H'0A' to db "", H'0A' db "", H'0A' it doesn't work anymore because of that extra zero byte. --------------------------------------------------------------------------- I'll give another example : A line with "db H'0A', H'0A'" gives : 063C 0A0A 01694 db H'0A', H'0A' But two lines with db H'0A' db H'0A' becomes : 063C 000A 01694 db H'0A' 063E 000A 01695 db H'0A' I wonder if it is possible (with gpasm) that both gives the result of 0A0A without that extra zero byte. --------------------------------------------------------------------------- (*) -- Met vriendelijke groetjes - Jan Wagemakers - ... UNIX is user friendly. It's just selective about who it's friends are. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist

2005\04\29@131836 by Bob Ammerman

picon face
A couple of points: 1: There is no reason to include the H'0A' bytes. HTML doesn't require them. 2: Rather than try to prevent the zero bytes from being embedded, just ignore them when copying your data. In this case you'd need to use a different value as your 'end-of-text' marker (perhaps 0xFF). Bob Ammerman RAm Systems {Original Message removed}

2005\04\29@134127 by Harold Hallikainen

face picon face


On Fri Apr 29 10:17 , 'Bob Ammerman' <spam_OUTrammermanTakeThisOuTspamverizon.net> sent:

{Quote hidden}

On point #1, I agree that HTML doesn't require them, but I believe HTTP does
require newlines in the header (at least that's my understanding from writing
perl cgi scripts).

On point #2, I think you're stuck because of the word orientation of the 18f452.
At the end of the DT assembler directive, the assembler wants to "finish off a
word" so the next instruction is word aligned. You could use DT to define a
series of shorter strings terminated with 0x00 (and the assembler might add
another 0x00 after yours to get to a word boundary), then call a send string
routine several times, pointing to the start of each string. Another approach
would be to (as mentioned above), use another terminator (such as 0xff), and
throw out 0x00s as they come up in your table. This'd let you define one long
string using a bunch of DTs. The extra 0x00s added by the assembler would be
thrown out by your routine that reads the table.

Good luck!

Harold

2005\04\29@141625 by olin_piclist
face picon face
Harold Hallikainen wrote:
> On point #2, I think you're stuck because of the word orientation of
> the 18f452. At the end of the DT assembler directive, the assembler
> wants to "finish off a word" so the next instruction is word aligned.

Not is you use UDATA_PACK (or whatever the exact name is).

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\29@143504 by Jan-Erik Soderholm

face picon face
Olin Lathrop wrote :

> Harold Hallikainen wrote:
> > On point #2, I think you're stuck because of the word orientation of
> > the 18f452. At the end of the DT assembler directive, the assembler
> > wants to "finish off a word" so the next instruction is
> word aligned.
>
> Not is you use UDATA_PACK (or whatever the exact name is).

"code_pack".

MPASM manual, DS33014H, section 4.10, page 65.

http://ww1.microchip.com/downloads/en/DeviceDoc/MPASM_&_MPLINK_33014h.pdf

(Sorry, Microchip has disabled "copy" from the PDF. sight...)

Regards,
Jan-Erik.



2005\04\29@150512 by J. Gromlich

flavicon
face
Not sure what you mean by > > (Sorry, Microchip has disabled "copy" from the
PDF. sight...)
I just downloaded the PDF to my machine.  Download for reading and then SAVE
to HD.
Worked for me.

RJG

> {Original Message removed}

2005\04\29@152204 by Jan Wagemakers

flavicon
face
Bob Ammerman <.....rammermanKILLspamspam@spam@verizon.net> schreef:

> 2: Rather than try to prevent the zero bytes from being embedded, just
> ignore them when copying your data. In this case you'd need to use a
> different value as your 'end-of-text' marker (perhaps 0xFF).

Ok, I have just subscribed myself to the gnupic mailingslist. I'll ask
there if gpasm <http://gputils.sourceforge.net/> supports 'code_pack'. If
not, I'll rewrite my routine to ignore those zero bytes.

BTW, I'll like to thank everybody for there help!


--
Met vriendelijke groetjes         - Jan Wagemakers -

- Debian GNU/Linux 3.1 - Up : 122 days

2005\04\29@174557 by Jan-Erik Soderholm

face picon face
Roy J. Gromlich wrote :

> Not sure what you mean by > > (Sorry, Microchip has disabled
> "copy" from the PDF. sight...)
> I just downloaded the PDF to my machine.  Download for
> reading and then SAVE to HD. Worked for me.

For me to. No problem with *that*.

But the "Copy" option in the "Edit" menu is/was disabled
so one can not mark a section of text and just copy
it to the clipboard.

Now, it *could* have something to do with the fact that
the latest MPASM manual ("H") is in PDF 1.6 (Acrobat 7.x)
format while the former ("G") is in PDF 1.2 (Acrobat 3.x)
and my Reader is 5.x... :-)

Anyway, I do think that there is an option when creating
PDF:s to disable the "Copy" option in Acrobat Reader...

Jan-Erik.




2005\04\29@175937 by olin_piclist

face picon face
Jan-Erik Soderholm wrote:
> Anyway, I do think that there is an option when creating
> PDF:s to disable the "Copy" option in Acrobat Reader...

That sounds rather silly, since the information is on your disk and nobody
can control it.  If Acrobat Reader insists on not allowing you to copy text,
that will only guarantee someone will write a reader that won't, and post it
on the net.  The net result will be that Adobe and those people who turn on
copy protection look like horses' behinds.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\29@181925 by Mark Rages

face picon face
On 4/29/05, Olin Lathrop <olin_piclistspamKILLspamembedinc.com> wrote:
> Jan-Erik Soderholm wrote:
> > Anyway, I do think that there is an option when creating
> > PDF:s to disable the "Copy" option in Acrobat Reader...
>
> That sounds rather silly, since the information is on your disk and nobody
> can control it.  If Acrobat Reader insists on not allowing you to copy text,
> that will only guarantee someone will write a reader that won't, and post it
> on the net.  The net result will be that Adobe and those people who turn on
> copy protection look like horses' behinds.
>

That's exactly how it works!  I use the open-source "xpdf" on my Linux
system. Amazingly, it honors the "no-print" and "no-copy" codes,
although some distributions patch the source code to remove the
restrictions.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2005\04\29@192948 by Peter van Hoof

flavicon
face
> That sounds rather silly, since the information is on your disk
> and nobody
> can control it.  If Acrobat Reader insists on not allowing you
> to copy text,
> that will only guarantee someone will write a reader that
> won't, and post it
> on the net.  The net result will be that Adobe and those people
> who turn on
> copy protection look like horses' behinds.

It's true though, at creation time there is full control of the
copy function and  what is even more annoying the print function
can be disabled. I bought a manual for a scope on ebay and it has
the print and copy disabled and for reading and using the wiring
diagrams it's horrible.


TTYL

Peter .....peterKILLspamspam.....whacky-scientist.com


2005\04\29@203114 by Marcel Duchamp

picon face
Olin Lathrop wrote:
> Jan-Erik Soderholm wrote:
>
>>Anyway, I do think that there is an option when creating
>>PDF:s to disable the "Copy" option in Acrobat Reader...
>
>
> That sounds rather silly, since the information is on your disk and nobody
> can control it.  If Acrobat Reader insists on not allowing you to copy text,
> that will only guarantee someone will write a reader that won't, and post it
> on the net.  The net result will be that Adobe and those people who turn on
> copy protection look like horses' behinds.

Check Microchip document 51265g.pdf (Using MPLAB ICD2 brochure).

It has useful information on the ICD2 target cable pinout.  It shows pcb
board connector pinout, schematics showing proper and improper
utilisation of the ICSP lines, and other topics.

I attempted to use the Adobe Acrobat snapshot copy tool to copy some of
the graphics and put them into a document for inhouse purposes.  Sorry,
denied.

Checking the Document Properties box, it has content copying or
extraction set to Not Allowed.  So, I used Irfan View screen copy
function to get what I needed despite the efforts of some bright
marketing wonk at Microchip.

>The net result will be that Adobe and those people who turn on
> copy protection look like horses' behinds.

Indeed.
MD

2005\04\30@044447 by ThePicMan

flavicon
face
At 20.35 2005.04.29 +0200, you wrote:
>Olin Lathrop wrote :
>
>> Harold Hallikainen wrote:
>> > On point #2, I think you're stuck because of the word orientation of
>> > the 18f452. At the end of the DT assembler directive, the assembler
>> > wants to "finish off a word" so the next instruction is
>> word aligned.
>>
>> Not is you use UDATA_PACK (or whatever the exact name is).
>
>"code_pack".
>
>MPASM manual, DS33014H, section 4.10, page 65.
>
>http://ww1.microchip.com/downloads/en/DeviceDoc/MPASM_&_MPLINK_33014h.pdf
>
>(Sorry, Microchip has disabled "copy" from the PDF. sight...)

There are password breakers for that. As easy as stealing the feeding-bottle
from a baby (just way less painful for your conscience :) ).


>
>Regards,
>Jan-Erik.
>
>
>
>-

2005\04\30@101817 by Nathan Thomsen

flavicon
face
My best guess is that your problem is caused because bytes of flash in a 18F series PIC are stored in 2 byte sections. For example, each instruction takes either 2 or 4 bytes of code space.  I don’t have any real experience with gpasm or with db so I haven’t experienced this problem before.  As far as "code pack" it could possibly combine two 1 byte db together.

Nathan Thomsen
{Original Message removed}


'[PIC] db : odd number of expressions, last byte wi'
2005\05\01@145312 by Wouter van Ooijen
face picon face
> It's true though, at creation time there is full control of the
> copy function and  what is even more annoying the print function
> can be disabled. I bought a manual for a scope on ebay and it has
> the print and copy disabled and for reading and using the wiring
> diagrams it's horrible.

try ghostview

Wouter van Ooijen

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


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