Removed Post

Comment

Comment by Jack Sparrow on January 29, 2011 at 12:08am

I actually talked about how PCLATH relates to tabling in my blog post. I'm glad you understand tabling now, though.

Comment by Ritchie Thai on January 29, 2011 at 12:02am

I just read page 7-64 about Tabling and the PCLATH register, and it makes everything clear.

 

My TAs and Prof. really did tell me that there is a limited amount of table memory for each page of program memory. The exact information varied from person to person, but it was very clear that people believed that the retlw instruction is special. I specifically asked about retlw vs movlw, and was told that retlw is special.

 

I will probably bring this up during my next lab session. If you were one of our TAs you could have cleared this all up from the beginning. On the other hand, your explanations aren't actually what made me understand, it was page 7-64, which is referred to in one of the questoins asked on the front page.

 

It seems even the person who understand how this works hasn't managed to get tables working smoothly.

Comment by Jack Sparrow on January 28, 2011 at 11:42pm

I am not in AER201 now, but have been previously. Figure 7.4-2 does not indicate that there is special "table memory" any more than it indicates that your interrupt service routine must be at the end of your code. Nor does the accompanying text on the same page:

Further, in some occasions, the program code can be simplified somewhat if any tables that are created are assigned to addresses in the range H'0005'-H'00FF'. For most applications, these 250 locations provide more than enough room.

Comment by Ritchie Thai on January 28, 2011 at 10:35pm

This has become a tricky discussion. You are not in AER201, so I cannot point you toward the textbook, but if you come across it see page 7-18. It shows the memory organization and states that there is a section of memory reserved for tables.

 

If you tell me the book is lying, I am willing to believe you, or at least call the book into question. If you tell me I have misunderstood the book, I am also willing to hear your clarification and believe it.

Comment by Jack Sparrow on January 28, 2011 at 9:33pm

There is no such thing as table memory. On the PIC16, "RETLW k" translates to the instruction opcode 11 01xx kkkk kkkk, while "MOVLW k; RETURN" translates to the two instruction opcodes 11 00xx kkkk kkkk; 00 0000 0000 1000. The PIC16F877 data sheet says this very clearly on page 136, Table 13-2: PIC16F87X Instruction Set, under the subheading "Literal and Control Operations".

Comment by Ritchie Thai on January 28, 2011 at 5:29pm

I think you misunderstood my description.

 

RETLW stores the literal value in table memory according to every source I have consulted, including 2 TAs and Prof. Emami. The table I generate uses MOVLW, which according to every source I have consulted, the same 2 TAs, does not reside in the table memory.

 

It is a far more inefficient use of memory and processing power, but it does not compete with the rest of the tables for memroy. For example, half the takes taking up 256 characters or 200 (200 from Prof, 256 from a TA) in the table memory, and half takes up 512 lines in the rest of the program memory.

 

This is perhaps an experiment more than anything else.

Comment by Jack Sparrow on January 28, 2011 at 12:35pm

The code this tool generates is of the form

PseudoTableLookup
movwf index # index = W
addwf index, w # W = 2*index = 2*offset
addwf PCL, f # PC = start of table + 2*index
movlw '0'
return
movlw '1'
return
...

while the simplest implementation of a "normal table" (which does not reside on any special bounded region of memory for tables, so your first paragraph is incorrect) is

TableLookup
addwf PCL, f # PC = start of table + index
# dt '01... assembles to:
retlw '0' # 1 instruction equivalent to "movlw '0'; return"
retlw '1' # 1 instruction equivalent to "movlw '1'; return"
...

Aside from the fact that both implementations have the same problems, how is the new code an improvement?