 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Guest
|
| Need Help, PSP pic to pic connection. |
 Posted: Thu Mar 23, 2006 11:14 am |
 |
|
I am in Senior Design I at oklahoma state university. We were given the project of replacing a usb connection with a bluetooth one on a pre existing device (we'll call it device A). The USB chip on device A used a PSP connection (minus the CS) to have information sent to it and recieved from it. To avoid having redesign device A we decided to make another device (device B) that would use a pic to translate between device A and the bluetooth device (serial communication with RTS and CTS flow control). We haven't been able to make major modifications to the code on Device A because it is in assembly witch is very difficult for us to understand since we haven't used it much. anyway, I'm trying to use the PSP routines in CCS to activate the write cycles. Since there is no CS from Device A, I connected the WR input from device A to both WR and CS on the pic of Device B. Basicly, nothing is working when it comes to the Write from device A cycle. The interupt is activating, but I am only getting one byte (it should be a packet). Also, the byte that I'm getting is the same as the last byte that I just finished sending to it (the ports on port D aren't changing). So basicly, I'm having the interupt activate when it should, but it is only activating once and it's not reading a new byte. This makes me think the problem isn't with my code but rather is bigger problems with the design or my understanding of device A. Here is my code for device B. Focus on the PSP interupt that writes. I am making it through my serial (write to Device A) interupt just fine (don't know if its actually recieving it though). Oh, and don't worry about flow control yet as I'm just trying to ping the device.
Questions I have:
-what pin and what action activate the PSP interupt?
-What pin and what action activate the Serial Interupt?
-Shouldn't the pic on Device A be able to drive the D ports to different values after I have outputed my own value onto it?
| Code: | #include <18F452.h>
#device ICD=true
#device adc=10
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#use delay(clock=40000000)
#fuses NOWDT, NOPROTECT, BROWNOUT, NOPUT
#use rs232(baud=9600, parity=N, xmit=PIN_C6, rcv=PIN_C7, bits=8, stream=PC)
#use rs232(DEBUGGER)
#define BUFFER_SIZE 96
#define RXF PIN_A0
#define TXE PIN_A1
#define RD PIN_E0
#define WR PIN_E1
#define CS PIN_E2
//#define RTS PIN_A0
//#define CTS PIN_A1
char serialData[100] = "";
char pspData[100] = ""; //stores input from the psp
char temp[5] = "";
int i = 0; //integer used for loops
int pSize = 0; //used to store the overal packet size ([size] +4)
int nextIn = 0;
int nextOut = 0;
int isBusy = false;
#int_RDA
RDA_isr()
{
output_HIGH(TXE);
disable_interrupts(INT_PSP); //disables the PSP interput to prevent errors
for(i=0; i<4; i++) //reads in the first 4 bytes of the packet
serialData[i] = fgetc(PC);
pSize = serialData[3] + 4; //gets the size byte from the packet
//adds four to make it total size of the packet
for (i=4; i < pSize; i++) //reads in the remaining packets
serialData[i] = fgetc(PC);
for(i=0; i< pSize; i++) //reflect the packet back to the PC
fputc(serialData[i], PC);
for(i=0; i< pSize; i++) //prints the packet in the debug monitor
{
sprintf(temp, "%x ", serialData[i]);
puts(temp);
}
puts(""); //prints and extra line
/*when the psp ports are added, the following should be uncommented*/
for(i=0; i<pSize; i++) //writes to the WIB
{
output_d(serialData[i]); //sets the data
output_LOW(RXF); //says there is no longer data that needs to be written
while(input(RD)) {} //waits for RD to be low
while(!input(RD)) {} //waits for RD to be high
}
pSize = 0; //resets pSize to 0
enable_interrupts(INT_PSP); //renables interupt for psp
if(!isBusy)
output_LOW(TXE);
}
#int_psp
void psp_isr()
{
pspData[nextIn++] = input_D(); //save input to buffer
if(nextIn == BUFFER_SIZE) //if next in is at end of buffer size
nextIn = 0; //equal 0
if(nextIn == nextOut) //if next_in equals next_out
{
output_HIGH(TXE); //buffer is full
isBusy = true; //if buffer is full, isBusy true;
}
}
void main()
{
setup_adc_ports(NO_ANALOGS);
/* setup psp */
setup_psp(PSP_ENABLED);
enable_interrupts(INT_PSP);
/* setup Serial */
enable_interrupts(INT_RDA);
enable_interrupts(GLOBAL);
puts("Start of Program\n");
//set_tris_a(0x01);
output_HIGH(RXF);
output_LOW(TXE);
while(true)
{
if((nextIn != nextOut) || isBusy) //checks if buffer has data
{
//output_high(RTS);
//while(!input(CTS)) {}
fputc(pspData[nextOut], PC);
//output_low(RTS);
if(++nextOut == BUFFER_SIZE)
nextOut=0;
isBusy = false;
output_LOW(TXE);
}
}
}
|
Thanks for any help you can offer.
Zach |
|
 |
rberek
Joined: 10 Jan 2005
Posts: 207
Location: Ottawa, Canada
|
|
| Posted: Thu Mar 23, 2006 11:28 am |
|
|
I just had the quickest of looks, but you seem to be expecting an entire packet to appear when the RDA interrupt goes off.
It goes off when you have a single BYTE in the receive buffer. When you use getc() to read it, the buffer is cleared. If you are building a packet, you will have to create a buffer big enough to store the whole packet and write one byte into it each time the interrupt goes off. When you've reached the EOP (end-of-packet) you will have to do any packet processing then. |
|
|
Guest
|
|
| Posted: Thu Mar 23, 2006 12:00 pm |
|
|
When I send to device A, I'm sending an entire packet, but when I recieve from device A, I'm just getting the packet and forwarding through my pic to the bluetooth device. It sounds like you know what is activating the PSP interupt. Could you describ it a little bit more?
Zach |
|
|
Guest
|
|
| Posted: Thu Mar 23, 2006 12:17 pm |
|
|
what I'm expecting is for it to go off several times (once for each byte) and send the entire packet through the buffer to the other end.
Zach |
|
|
zachavm
Joined: 23 Mar 2006
Posts: 9
|
|
| Posted: Thu Mar 23, 2006 12:24 pm |
|
|
Sorry, I didn't realize I was posting as a guest. This is the sn I post under from now on.
Zach |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Thu Mar 23, 2006 12:56 pm |
|
|
| Seems to me that your design is seriously flawed. First, you didn't mention what USB chip that you were using? There is probably more than just raw data going on there. Did the chip require any configuration, special commands, is the USB code in the chip or on the PIC? If there was anything other than user data being passed to the USB chip, then you are going to have to filter the data. INT_RDA is triggered when a byte comes in over a serial port. There is no need to disable an interrupt inside of an interrupt because the interrupts are already disabled. Do you realize than on the first byte of reception, your code will sit and wait in the interrupt routine until the whole packet is received? What happens if you miss a byte? It will sit there until the start of another packet. Your data will be out of sync and never recover! You then transmit the packet back to the PC and then again to a debug monitor! Then you wait for device A to read the data. You are in the interrupt for a very long time! You need to read the datasheet on the PIC. It will tell you what generates the interrupts. You should also add the "EERORS" parameter for the #use rs232 since you are not handling any errors. |
|
|
zachavm
Joined: 23 Mar 2006
Posts: 9
|
|
| Posted: Thu Mar 23, 2006 1:40 pm |
|
|
Okay, I'll try to explain as best I can. My project is just acting as a buffer between a PC and device A. The data comes in through a bluetooth chip (serial), into my pic, and out to device A. The chip that I am trying to replicate is a DLP-USB245M.
http://www.ftdichip.com/Documents/DataSheets/DLP/dlp-usb245m13.pdf
As for the communication, it is only a packet of several bytes:
[sync1][sync2][channel ID][size][packet type][...data bytes...][checksum]
it is unimportant what these bytes are, only that I know what they are. Yes, I have some holes in my code right now, but I'm just trying to ping the other device so that I can know my design is working. then I will proceed to fill in the other holes. Thanks for letting me know that I don't need to disable the interuptes. As for flow control, that is something I am still working on. I know how to do flow control for the PSP connection (RXF and TXE as seen on the USB data sheet), but I'm still working on the RTS and CTS for the Serial connection.
However, I can't use the ERRORs parameter as this is only supposed to be a transparent feed. I may have to re-write the Serial interupt (as you stated) into a buffered |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
