Hey guys, just thought I’d post up a little thread on this.
I’m putting together an autonomous header file for the new controller!
I’m using code samples taken from here (CD) and written by myself.
The PRIMARY core to this is to get a version of CopyCat out for the new controller. For those who don’t know what CopyCat is, it’s a program that takes driver input and dumps it to EEPROM, and plays it out when auto mode is triggered. Well, I only had a very basic version for the last controller that would record like 25 seconds of input and play it out. The new controller will be able to record almost 10 minutes of driver input (two drive values) and will be able to be splitted into lots of different slots. So, you could have like, 5 prerecorded auto modes at 30 seconds each, and have a digital dipswitch panel or something to switch between them. Great, isnt it? I’m also adding in functions that run an array of movement data, which is tricker to plan out, but still simple for those who like to tinker. And, I’m trying to come up with some sort of sensory-driven-array type of object-like mode. Wow, what a type!
I also suggest that while recording auto modes, don’t use interrupts. I’ve taken the code sample from a previous post (btw, thanks to whoever wrote it, can’t jump back to it right now) and it won’t write right (aw man…) if you interrupt it. 
or at least there’s a chance it won’t.
But, I guess you could use the CopyCat in collaboration with sensory or something on the interrupts while playing it back. That’d be kinda cool.
So anyway, I’ll post it once it’s done. Hope it’ll help some of those new teams out there get something up and running without too much knowledge of memory handling and so forth. Auto mode should be alot more fun to watch this year 
That is really cool man 
Good luck. Sounds like a great project also
Thats why in the manual it says to disable interrupts before writing…
See my EEPROM writing code here for an example.
Similar should also apply for writing to the FLASH. (which if you aren’t already using, would be a way to get more storage space…)
I think thats the code sample I pulled, I’ll be sure to add your name to the list of credits!
Thanks for the help!
I was just wondering how does the copycat work.
I can figure out that you have an array and a counter, and the arrays store all the data from the joystick but how do you make it so that the array doesnt lose its values when we power off? And i was trying to look at a CopyCat program from last year but most of the download links have error so if some one has the code from last year i will love to see it
Well, the data isn’t stored in a “variable” array, It’s stored in EEPROM memory. The EEPROM doesn’t reset when it loses power.
I’m having lots of trouble getting the new controller to Accept the Read/Write functions.
Random Dude, Can you explain how they work a little bit?
From what I uderstand, you send an x and y address to read/write, and a char variable to read/write.
You convert char to int with (int)Char (where char is the char variable) right?
So, how do you convert int to char?
And, am I mistaken about the x,y address? It would mean that there’s a 256x256 bit “array” being used, no?
I’m just trying to understand a little bit more.
My current auto modes just pull data from arrays. They work fine, but the problem is getting that driver input to stay. If you dump driver input to an array, it’ll be gone when you reset.
You stated tat I could possibly use the Flash memory as well. Would this be any easier?
I’m just trying to get something basic going here.
addrH, addrL are the high and low bytes of the address respectively. The memory address is 10 bits long. The lower 8 bits are in addrL. The upper 2 bits are in addrH (addrH.bit.2 through addrH.bit.7 should be 0).
So I suppose you could picture it as a 4x256 array if you want to.
I wrote the code with two seperate bytes, simply because i was lazy and didn’t want to have to break the 16bit word into two bytes.I’ll change the functions and put them at the end of this message.
Now as to typcasting (that is when you convert one variable type to another). You can use the
x = (int)y;
syntax for any type by simply replacing ‘int’ with the type in question.
so to typecast to a unsigned char
x = (unsigned char) y;
unsigned char readEE(unsigned short address) {
EEADRH = ((address>>8)&0x03);
EEADR =(address&0xFF);
EECON1bits.EEPGD =0;
EECON1bits.CFGS =0;
EECON1bits.RD =1;
return EEDATA;
}
void writeEE(unsigned short address,unsigned char data)
{
EEADRH = ((address>>8)&0x03);
EEADR =(address&0xFF);
EEDATA = data;
//following as per spec. sheet
EECON1bits.EEPGD =0;
EECON1bits.CFGS =0;
EECON1bits.WREN =1;
INTCONbits.GIE = 0;
EECON2 = 0x55;
EECON2 = 0xAA;
EECON1bits.WR = 1;
INTCONbits.GIE = 1;
EECON1bits.WREN = 0;
}
–
I don’t have the EduBot with me, but the code should work…
Thanks, I’ll work on integrating it later.
Ok, I am a little confused. I thought the EDU RC dosn’t have an auto mode.
Well, by default, you can have the eduRC run autonomously. You don’t need an auto switch to write something to function autonomously. But if you are searching for a true autonomous user bit, it does have one. Check the alias file and its in there. (Thus it is quite certain auto is back in 2004)
I’m just using switches to cut on/off and select auto modes right now.
How about turning off all interrupts except the high-priority interrupt then synchronizing yourself to IFI’s interrupt? After new data comes in from the master processor, you should have at least 16ms to write your data block before the next interrupt. I can write some example code if needed. I’d like to see this work 'cause it’s a really neat idea.
-Kevin
That’s a neat idea. If you can write some code to get it working, that’s be great. From what I understood though, the write functions can malfunction if any interrupts are enabled…
I’d think they’d only be worried about the interrupt, not whether it’s enabled or not. Maybe try turning-off all interrupts for 16ms? On new packet data from the master, set a timer and start writing EEPROM data while keeping an eye on the time. At 16ms stop writing and re-enable the interrupts.
Hey, IFI, will this work?
-Kevin
Actually, my write function above does turn off interrupts using this line:
INTCONbits.GIE = 0;
This:
EECON2 = 0x55;
EECON2 = 0xAA;
EECON1bits.WR = 1;
is the only critical section of the write function. Since interrupts are disabled during that time there should be no problems. I haven’t tested this while using iterrupts but this is stolen directly from page 81 of the PIC18FXX20 Data Sheet.
I’m also working on a copycat type program as well for my team… we used one similar to copycat except i used an external timer to make it work. Also I wasn’t aware of copycats existance before I wrote it either… yay me.
Anyways… I won’t have the chance to touch our Edubot until Sunday, and I have been working on some routines, and in ifi_picdefs.h the following says:
extern volatile near unsigned char PIE2;
extern volatile near struct {
unsigned CCP2IE:1;
unsigned TMR3IE:1;
unsigned LVDIE:1; /* Reserved - Do not use */
unsigned BCLIE:1; /* Reserved - Do not use */
unsigned EEIE:1; /* Reserved - Do not use */
unsigned :1;
unsigned CMIE:1;
} PIE2bits;
extern volatile near unsigned char PIR2;
extern volatile near struct {
unsigned CCP2IF:1;
unsigned TMR3IF:1;
unsigned LVDIF:1; /* Reserved - Do not use */
unsigned BCLIF:1; /* Reserved - Do not use */
unsigned EEIF:1; /* Reserved - Do not use */
unsigned :1;
unsigned CMIF:1;
} PIR2bits;
Where EEIF is “Write operation complete – must be cleared by software” and EEIE is “Enable Write Operation Interrupt bit”. Both are marked reserved.
So by this I’m assuming that:
We cant clear the bit that means the write operation is complete either? (EEIF)
We cant use interrupts to tell when its finished doing the write? (EEIE)
Or am I reading this wrong and theres something I’m missing… because as noted in the PIC documentation, a EEPROM write operation can take up to 4ms to complete. This would mean that we can only write a byte So anyone know about this?
I’m also working on a copycat type program as well for my team… we used one similar to copycat except i used an external timer to make it work. Also I wasn’t aware of copycats existance before I wrote it either… yay me.
Anyways… I won’t have the chance to touch our Edubot until Sunday, and I have been working on some routines, and in ifi_picdefs.h the following says:
extern volatile near unsigned char PIE2;
extern volatile near struct {
unsigned CCP2IE:1;
unsigned TMR3IE:1;
unsigned LVDIE:1; /* Reserved - Do not use */
unsigned BCLIE:1; /* Reserved - Do not use */
unsigned EEIE:1; /* Reserved - Do not use */
unsigned :1;
unsigned CMIE:1;
} PIE2bits;
extern volatile near unsigned char PIR2;
extern volatile near struct {
unsigned CCP2IF:1;
unsigned TMR3IF:1;
unsigned LVDIF:1; /* Reserved - Do not use */
unsigned BCLIF:1; /* Reserved - Do not use */
unsigned EEIF:1; /* Reserved - Do not use */
unsigned :1;
unsigned CMIF:1;
} PIR2bits;
Where EEIF is “Write operation complete – must be cleared by software” and EEIE is “Enable Write Operation Interrupt bit”. Both are marked reserved.
So by this I’m assuming that:
We cant clear the bit that means the write operation is complete either? (EEIF)
We cant use interrupts to tell when its finished doing the write? (EEIE)
Or am I reading this wrong and theres something I’m missing… because as noted in the PIC documentation, a EEPROM write operation can take up to 4ms to complete. This would mean that we can only write a byte and then randomly guess when the operation is complete?
Anyone have any ideas about this?
I don’t profess to be good at wrighting code, But I had a thought, could you
save the info from driving to ram in the “record” mode and then use the EEprom write code to store that info EEprom. Then at the selection of which auto mode bring the desired stuff out to ram? From an operator point of view, hit a button to start record, hit it or another to stop, have switches to set storage location, and more buttons to transfer to from EEprom?
Yeah… thats what we did last year… (essentially). Except it was a lot more automatic than what you were talking about.