Atom Pro 28 EEProm readdm/writedm alignment or timing issues

Lynxmotion Electronics & Software
1

I am trying to get my Brat to be able to store commands that I download from my PC using a VB program that I am in the process of writing. I am running into issues with reliably writing information out to the EEProm. From previous threads I believe the new Pro as 4k of EEProm.

My download function is rather primitive right now, as I am downloading one line with the count of items in the sequence and then a line for each line in the sequence. Each line has the HSERVO values for each of the 6 servos in the Brats movement, plus a time value.

A portion of the code on the brat’s side to receive the information:

GHCEpromStart con 0x110		

;
; now lets try to get some serial input from our Host PC
;
serin s_in, i2400, 250, GCHTimeout, [sdec GHCCnt]
	
; Ok we got a count.  If it is -1 then it is a do immediate!
if GHCCnt = -1 then
; now lets try to get some serial input from our Host PC
	serin s_in, i2400, 5000, GCHTimeout, [sdec GHCVals(0), sdec GHCVals(1),sdec GHCVals(2),sdec GHCVals(3),sdec GHCVals(4),sdec GHCVals(5),sdec GHCVals(6)]
	
	; We got a command!
    gosub movement(tofloat GHCVals(0)) / stepsperdegree, (tofloat GHCVals(1)) / stepsperdegree, (tofloat GHCVals(2)) / stepsperdegree, (tofloat GHCVals(3)) / stepsperdegree, (tofloat GHCVals(4))/ stepsperdegree, (tofloat GHCVals(5)) / stepsperdegree, tofloat GHCVals(6)]				
elseif GHCCnt < 10
	; so a little check to make sure that count is reasonable.
	Writedm GHCEpromStart, [GHCCnt.lowbyte, ghcCnt.highbyte]
		servoZeroT = GHCEpromStart + 2
	DISABLE WKPINT_3 
	DISABLE TIMERAINT 
		
	for t = 0 to GHCCnt - 1
		; read in the number of lines.
		serin s_in, i2400, 5000, GCHT2, [sdec GHCVals(0), sdec GHCVals(1),sdec GHCVals(2),sdec GHCVals(3),sdec GHCVals(4),sdec GHCVals(5),sdec GHCVals(6)]

		; Now lets write out the movement in EEPROM.
		WritedM servoZeroT, [GHCVals(0).lowbyte, GHCVals(0).highbyte, GHCVals(1).lowbyte, GHCVals(1).highbyte, GHCVals(2).lowbyte, GHCVals(2).highbyte, GHCVals(3).lowbyte, GHCVals(3).highbyte, GHCVals(4).lowbyte, GHCVals(4).highbyte, GHCVals(5).lowbyte, GHCVals(5).highbyte, GHCVals(6).lowbyte, GHCVals(6).highbyte]
	ServoZeroT = servoZeroT + (7 * 2)

	next
	ENABLE WKPINT_3 
	ENABLE TIMERAINT

Right now I am using the serin function parse the input. I may change over to try to simply input the line and parse myself.

But back to the issue at hand. Another part of this program then retrieves the command and calls movement with the results. I have it right now dumping the input back to the serial port. The last one output looks like:

4 1166,-4998,-4998,-1166,4998,4998,500 4998,-1166,-4998,-4998,500,4998,500 1166,4998,4998,1166,-4998,-4998,500 1166,4998,-1,-1,-1,-1,-1

Notice the last line, has the -1s. This is consistent with these settings.
My first attempt was with: GHCEpromStart con 500
With this setting the last two items of line 1 were -1 (the first write address that failed may have been 0x200.

My next attempt was to have GHCEpromStart con 100
With this setting the last value of the second line failed. Address failed about: 0x80

Next was: GHCEpromStart con 0x100
With this the count failed to be written

I am not sure if I am begin very clear here. But the basic question is: Are there alignment or timing issues involved with writing to the EEPROM?

Thanks

2

A side comment:
When I try my first download from the PC VB program to the Brat it reboots the brat. I then put it back in the appropriate mode for it to accept the input and then it works. Then when I switch back to the Atom Pro IDE and do a connect to the terminal, it again does a reboot of the brat. I believe this has to do with the serial DTR. Do you know of an easy way to selectivly not causing these reboots?

If not it is workable…

3

I2C eeprom chips have a write buffer on them. If you try to write more data than the buffer has room for at one go(ie one writedm command) the data will not be written correctly. I recommend you change your long writedm command into multiple commands that each write only 8 bytes at a time. * bytes is a safe size because I’ve never seen an eeprom with less write buffer than that. If you still have problems I’ll have to see more of your program. Could be you are defining arrays incorrectly(to small) and are trashing ram locations or could be your serout command is not sending the data. I doubt either of these cases though because the -1s you are getting from thee eeprom indicate a blank location($FF byte sent signed will be -1)

Kurte:
When programming the atom has to be rebooted to get into programming mode. When you connect to the terminal window we also automaticly reboot the atom. You will have to use a different terminal program if you can’t have the reboot each time you connect.

4

Thanks,
What EEProm is used on the Pro28? I remember you mentioned that it had 4K bytes, is this correct or is it 4k bits? If I look at the h83664 pdf (page 265), then it looks like 4k bits. It looks like you can do 1 byte writes or page writes of 8 bytes. The documentation looks a bit interesting in that if you write multiple bytes. The three LSB bits of the address are incremented for each byte written and that it wraps around within the same page. Do I need to make sure that my writes are aligned on 8 byte boundries?
Thanks again

5

It’s a 24something32. The something could be a “c” or an “aa”. Also not all 2432 i2c eeproms have the same buffer size. Thats why I suggested 8 bytes max in a writedm. You can readdm as many as you want, but when writing you can’t write more at once than the buffer size.

6

Thanks again :slight_smile: !
I updated my program, both on the VB side as well as the Pro side to input the positions in degrees. +90 to -90. So it fits in one byte. Now with 6 servos + 2 bytes for time, it equals 8 bytes per item in the sequence.
I output the count now at: GHCEpromStart con 0x10E
So the first sequenced item starts at 0x110 (aligned).

This morning I was able to download a 4 item sequence that did a forward step and it worked :smiley:

Kurt

7

Glad it’s working. I don’t think you need to write on an 8byte boundary. But that could be the case.