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>

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.

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 "You can find more info ", H'0A' db "here.", H'0A' db "
", H'0A' db "Meer informatie vind je ", H'0A' db "hier.", 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

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}

On Fri Apr 29 10:17 , 'Bob Ammerman' <spam_OUTrammermanTakeThisOuTverizon.net> sent: {Quote hidden}>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 > 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

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

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.

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}

Bob Ammerman <.....rammermanKILLspam@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

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.

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

On 4/29/05, Olin Lathrop <olin_piclistKILLspamembedinc.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

> 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 .....peterKILLspam.....whacky-scientist.com

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

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. > > > >-

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}

> 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