peek and poke questions

[bowen303]

I have some questions about peeking and poking that hopefully someone can shed some light on. Specifically when it comes to changes to alternate bit rates.

I have peeked the SCI1C1 control register and it returns 0. So i'm assuming that everything is 0 by default? In order to change the mode to 9-bit I was planning on using:

poke(0x1A, 0x10)

I am a little unclear on exact usage on how the register works. (I'm taking a stab in the dark here. register is 8 bits wide, 0x10 is hex. 1 is 0001 and 0 is 0000. putting the 1 in the 4th field? which is why I am using 10...or is this completely off base.) I've looked around for some kind of documentation that would explain this kind of thing and I'm coming up empty.

I am assuming that as long as I don't plan on changing parity then this should be the only change that would be required to change to 9-Bit mode.

Thank You

[kbanks]

I have some questions about peeking and poking that hopefully someone can shed some light on. Specifically when it comes to changes to alternate bit rates.

I have peeked the SCI1C1 control register and it returns 0. So i'm assuming that everything is 0 by default? In order to change the mode to 9-bit I was planning on using:

poke(0x1A, 0x10)


I recommend against blindly poking registers. You should use peek() to get the current register value, use bitwise operations to modify the value, and then poke the new value back into the register.

I am a little unclear on exact usage on how the register works. (I'm taking a stab in the dark here. register is 8 bits wide, 0x10 is hex. 1 is 0001 and 0 is 0000. putting the 1 in the 4th field? which is why I am using 10...or is this completely off base.) I've looked around for some kind of documentation that would explain this kind of thing and I'm coming up empty.


Yes the register is 8 bits wide. For details on the chip the datasheet is your source of info. We are currently expanding the SNAP Reference manual to cover more of the language aspects of SNAPpy.

Looking at the datasheet, I agree that the 0x10 (bit 4) is the one you want to change. So something like:

temp = peek(SCI1C1)
temp |= 0x10
poke(SCI1C1, temp)

would safely change the bit.

I am assuming that as long as I don't plan on changing parity then this should be the only change that would be required to change to 9-Bit mode.

There are at least two other issues:

1) You must be running 2.1 code to "survive" 9-bit mode (parity or otherwise). We found out a while back that turning on 9-bit mode required a change in the UART interrupt handling (an extra status register must be read).

The 2.1 series of firmware has this extra handling added, but the 2.0 code predates this discovery.

2) With 2.1 code, we support parity using the 9-bit feature of the chip, but we have not put any support in for 9 DATA BITS.

The code that reads and writes characters to/from the UART is only working with 8-bits at a time, any 9-th data bit is ignored.

[bowen303]

Thanks for the information. That is exactly what I needed to know.

[bowen303]

Just curious, after updating this register, I should see something besides 0 when I peek it again? I have even tried not using the variable to pass the hex value (passing in 0x16) and the register still comes back as 0.

This is what I have used.

SCI1C1 = 0x1A
global SCI1C1
temp = peek(SCI1C1)
global temp
temp |= 0x10
poke(SCI1C1, temp)
#poke(0x1A, peek(0x1A) | temp)
#poke(0x1A,0x16) <-tried 16 because that is what temp came back as

I made them global so I can print them from another event. when it prints the variables come back as

code to print:
print peek(0x1A)
print temp
print SCI1C1

return values:
Device1000: 0 <- print peek(0 statement
16 <- temp variable
26 <- SCI1C1 variable

I am also curious why SCI1C1 comes back as 26?

[msellers]

Declare your globals first thing before you load them.

global SCI1C1, temp
SCI1C1=0x1A
temp = peek(SCI1C1)
temp |= 0x10
poke(SCI1C1, temp)

Where temp = 16, that is displaying a decimal number which is the same as 0x10.
Where you see SCI1C1 = 26, that is decimal for 0x1A so is to be expected.

For your print in a later function:
global temp, SCI1C1
temp = peek(SCI1C1)
print temp #should give you 16 if bit 4 is set and none others are.

Let me know if this works.

[bowen303]

I'm still not sure I am seeing the register getting updated properly. The print statement is still returning 0 for the value. To be honest, I don't think this is the answer to my problem anymore (9 bit changes), but I sure hate getting beat by a little bit of code. ;) Below is the output I am seeing.

2008-09-08 20:30:37 Device2000: 0 <-- SCI1C1 register (which is temp)
26 <- shows value of SCI1C1
0 <- for grins and giggles I hard coded the hex

Here is the code in it entirety.

from switchboard import *
otherNodeAddr = "\x00\x1D\x12" # <= put the address of the OTHER node here
def startupEvent():
global SCI1C1, temp
SCI1C1=0x1A
temp = peek(SCI1C1)
temp |= 0x10
poke(SCI1C1, temp)

initUart(0, 1) # <= put your desired baudrate here!
flowControl(0, False) # <= set flow control to True or False based on the needs of your application
crossConnect(DS_UART0, DS_TRANSPARENT)
#crossConnect(DS_NULL, DS_PACKET_SERIAL) # tell Packet Serial to STOP using the UART!
ucastSerial(otherNodeAddr)
def setLed(pinState):
setPinDir(2, True)
writePin(2, pinState)

global temp, SCI1C1
temp = peek(SCI1C1)
print temp #should give you 16 if bit 4 is set and none others are.
print SCI1C1
print peek(0x1A)

snappyGen.setHook(SnapConstants.HOOK_STARTUP, startupEvent)

[kbanks]

You need to do the extra peek/poke steps AFTER using initUart()?

(initUart() is overwriting your changes).

[bowen303]

I guess it never dawned on me that inituart is resetting everything back. Makes sense now that you point it out, I just assumed that it was really only changing the baud rate for that particular interface and not everything else.

After a quick copy and paste everything is updating as expected!

Thanks for the help guys!