Prev: Let's design a fake Perpetual Motion machine
Next: Currently Googling for Breakdown V of PTFE and Kapton
From: Paul E. Schoen on 13 Mar 2010 20:39

"Paul E. Schoen" <paul(a)pstech-inc.com> wrote in message
news:CQWmn.72789$1n5.54190(a)newsfe04.iad...
>
> "Paul E. Schoen" <paul(a)pstech-inc.com> wrote in message
> news:CGWmn.72788$1n5.50230(a)newsfe04.iad...
>>
>>
>> It seems reasonable that a BSF instruction might have a problem for an IO
>> pin, compared to a standard memory register, because it must (in one
>> cycle) read, modify, and write the modified byte to the port. This will
>> certainly take longer than an internal file register. I am surprised that
>> the code does not automatically use the LAT register, but there may be
>> compatibility issues. The 12F and 16F chips do not have the LAT
>> registers, but they also probably do not have a 64MHz option.
>
> Interesting trivia: From the datasheet in PORTA:
>
> "Reading the PORTA register reads the status of the
> pins, whereas writing to it, will write to the PORT latch."
>
> It does not say this about the B or C ports. But you are using Port A, as
> I recall...

But the problem is that a bitwise operation must first read something, and
in the case of BTSF PORTA,n it probably reads the actual port, while BTSF
LATA,n reads the memory in LATA, which is a solid digital value. PORTA
itself is essentially analog, and the internal logic takes a sample which
may not be a good logic level.

Paul

From: Jan Panteltje on 14 Mar 2010 08:32
On a sunny day (Sat, 13 Mar 2010 21:08:07 -0500) it happened Spehro Pefhany
<speffSNIP(a)interlogDOTyou.knowwhat> wrote in
<00fop5lngqjgcuvg7kgv3n4qv7du5ms8s1(a)4ax.com>:

>>I think it is not the only bug either.
>
>It isn't a "bug", more of a quirk. But there are usually plenty of
>real errata to go around.

Na, it is a bug.
The PIC outputs 16 MHz clock when doing a bsf PORTA,X, and then when an other
bsf instruction happens to port a, it *clears* output bit x.

The 16 MHz clock should not be there, there is no 4 MHz clock when running without the PLL.

This is my first PIC 18 experience, so I did read the data sheet first, and found this on page 80,
the data sheet is really funny:
EXAMPLE 8-1: INITIALIZING PORTA
CLRF PORTA ; Initialize PORTA by
; clearing output
; data latches
CLRF LATA ; Alternate method <--------------------------------
; to clear output
; data latches
MOVLW 030h ; Value used to
; initialize data
; direction
MOVWF TRISA ; Set RA<5:4> as output


So I thought 'Funny that they write this as one piece of code in an example, and no as 2 different pieces of code,
almost like you need BOTH', but gave it no further thought.
The alternative method LATA would require me to rewrite some code, so I used the first method, PORTA.

Now suppose you see this in the manual of your new car:
To indicate change of direction use the direction indicator lever on the steering wheel,
Alternate method is to stick your left hand out of the window for a left turn,
and ask you passenger to stick the right hand out of the window for the right turns.
One would think: I use the lever.
But then, when driving it, you find out that the lever does not work above 50 mph, so you need to use your hands.
A VERY close examination of the service manual shows the power level of the electrical system drops
so much above 50 mph that the indicator light electronics no longer works.
Now that would give some commotion...
Makes you wonder if TOYOTA USES PIC MICRO CONTROLLERS IN THEIR SPEED CONTROL SYSTEM.
From: Jamie on 14 Mar 2010 11:24
Jan Panteltje wrote:

> On a sunny day (Sat, 13 Mar 2010 21:08:07 -0500) it happened Spehro Pefhany
> <speffSNIP(a)interlogDOTyou.knowwhat> wrote in
> <00fop5lngqjgcuvg7kgv3n4qv7du5ms8s1(a)4ax.com>:
>
>
>>>I think it is not the only bug either.
>>
>>It isn't a "bug", more of a quirk. But there are usually plenty of
>>real errata to go around.
>
>
> Na, it is a bug.
> The PIC outputs 16 MHz clock when doing a bsf PORTA,X, and then when an other
> bsf instruction happens to port a, it *clears* output bit x.
>
> The 16 MHz clock should not be there, there is no 4 MHz clock when running without the PLL.
>
> This is my first PIC 18 experience, so I did read the data sheet first, and found this on page 80,
> the data sheet is really funny:
> EXAMPLE 8-1: INITIALIZING PORTA
> CLRF PORTA ; Initialize PORTA by
> ; clearing output
> ; data latches
> CLRF LATA ; Alternate method <--------------------------------
> ; to clear output
> ; data latches
> MOVLW 030h ; Value used to
> ; initialize data
> ; direction
> MOVWF TRISA ; Set RA<5:4> as output
>
>
> So I thought 'Funny that they write this as one piece of code in an example, and no as 2 different pieces of code,
> almost like you need BOTH', but gave it no further thought.
> The alternative method LATA would require me to rewrite some code, so I used the first method, PORTA.
>
> Now suppose you see this in the manual of your new car:
> To indicate change of direction use the direction indicator lever on the steering wheel,
> Alternate method is to stick your left hand out of the window for a left turn,
> and ask you passenger to stick the right hand out of the window for the right turns.
> One would think: I use the lever.
> But then, when driving it, you find out that the lever does not work above 50 mph, so you need to use your hands.
> A VERY close examination of the service manual shows the power level of the electrical system drops
> so much above 50 mph that the indicator light electronics no longer works.
> Now that would give some commotion...
> Makes you wonder if TOYOTA USES PIC MICRO CONTROLLERS IN THEIR SPEED CONTROL SYSTEM.
I wouldn't worry too much about it. If you ever had worked on the 6502
processors, I have a pile of old books that talk about the Jump indirect
(Vectoring address) that clearly states, you can store the vector
address anywhere how ever, it does not work if you do a page boundary
overlap.. You get an incorrect address and no, the assembler or
assemblers I've used, never flagged this as an error nor does any books
I've ever referenced state this.

I can only assume that it was intended by design to happen and maybe
some where along the line, it didn't or, got screwed up later down the road.
Years ago, I wrote my own custom 6502 assembler and one of the things
I did, was to have it test for the page boundary error for a jmp index
instruction.! If it was to take place, I inserted a NOP instruction.




From: Nobody on 18 Mar 2010 08:57
On Sun, 14 Mar 2010 10:24:56 -0500, Jamie wrote:

> I wouldn't worry too much about it. If you ever had worked on the 6502
> processors, I have a pile of old books that talk about the Jump indirect
> (Vectoring address) that clearly states, you can store the vector
> address anywhere how ever, it does not work if you do a page boundary
> overlap.. You get an incorrect address and no, the assembler or
> assemblers I've used, never flagged this as an error nor does any books
> I've ever referenced state this.

Amongst those of use who grew up with the 6502 (particularly with the BBC
Micro), that issue was common knowledge. As for a reference, the BBC Micro
Advanced User Guide, section 5.6, page 37, says:

There is a bug in the 6502. When the indirect address crosses a
page boundary the 6502 does not add the carry to calculate the
address of the high byte.

i.e. JMP (&19FF) will use the contents of &19FF and &1900 for
the JMP address.

http://www.bbcdocs.com/filebase/essentials/BBC%20Microcomputer%20Advanced%20User%20Guide.pdf

The fact that almost every computer programmer of my generation in the UK
owned a copy of that book probably accounts for it having been common
knowledge.

The situation in other circles may have been different. The other
6502-based micros of that era (Commodore, Apple, Sinclair) weren't so
accomodating of technical users, and typically didn't come with an
assembler or a circuit diagram as standard.

From: Jan Panteltje on 18 Mar 2010 09:55
On a sunny day (Thu, 18 Mar 2010 12:57:15 +0000) it happened Nobody
<nobody(a)nowhere.com> wrote in <pan.2010.03.18.12.57.13.937000(a)nowhere.com>:

The situation in other circles may have been different. The other
>6502-based micros of that era (Commodore, Apple, Sinclair)

Sinclair Z80, ZX81, and Spectrum were Z80 basesd and had not that bug :-
Z80 has no bugs as far as I know, and I coded a lot for it.
It has many 'hidden' instructions though.
Wrote a disassembler for it:
http://panteltje.com/panteltje/z80/index.html

I never used the 6502 myself.



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Let's design a fake Perpetual Motion machine
Next: Currently Googling for Breakdown V of PTFE and Kapton