How to change IrDA speed?

Mat17 · Post by **Mat17** » Tue Dec 12, 2006 3:49 am

Hi,

I'm the dev of PspIrda. It's an homebrew to transfer files between your PSP and devices compatible with the IrDA OBEX protocol (mobiles, pc, palm, PSP, ...) . You can try it here http://www.mediafire.com/?9meawtewtzm . It's a first release so the GUI is simplistic but it has a quite good compatibility (it works with most Nokia and siemens and I'm working to improve it).

The main problem is the speed. It's really slow as it uses the default IrDA speed : 9600bps. IrDA speed is negotiated between the 2 devices and in theory can go much higher, up to 115200bps.

I'm sure the PSP IrDA port can go up to this speed but I don't know why.

I've looked everywhere on the web before asking my question but I can't get an answer. So here it is : How can I configure the IrDA speed?

the answer is certainly some sort of ioctl but how exactly? Don't know.
ps2dev is full of talented dev so if you have any idea please tell me.

MaT

Post by **TyRaNiD** » Tue Dec 12, 2006 6:57 am

Well the PSP's IRDA is accessed through a UART so it might be possible to change the baud rate but only in kernel mode. You could try the following code:

Code: Select all

#define PSP_UART5_DIV1 0xBE540024
#define PSP_UART5_DIV2 0xBE540028
#define PSP_UART5_CTRL 0xBE54002C
#define PSP_UART_CLK   96000000
void pspIrdaSetBaud&#40;int baud&#41;
&#123;
    int div1, div2;

    /* rate set using the rough formula div1 = &#40;PSP_UART_CLK / baud&#41; >> 6 and
     * div2 = &#40;PSP_UART_CLK / baud&#41; & 0x3F
     * The uart4 driver actually uses a slightly different formula for div 2 &#40;it        
     * adds 32 before doing the AND, but it doesn't seem to make a difference
     */
    div1 = PSP_UART_CLK / baud;
    div2 = div1 & 0x3F;
    div1 >>= 6;

    _sw&#40;div1, PSP_UART5_DIV1&#41;;
    _sw&#40;div2, PSP_UART5_DIV2&#41;;
    _sw&#40;0x60, PSP_UART5_CTRL&#41;;
&#125;

However I have no idea if that will remotely work :)

Mat17 · Post by **Mat17** » Tue Dec 12, 2006 8:48 am

Thank you for your answer!
I will try it as soon as possible.

TyRaNiD, you are my hero :)

MaT

Mat17 · Post by **Mat17** » Sat Jan 13, 2007 1:39 am

Hi,

So I tried what you gave TyRaNiD but I have to say that It doesn't work :(
My PSP crashes when I call this function.

So, as I found in another forum thread, I added sceSysregUartIoEnable(5); at the begining of my code. This single line also crashes my PSP.

In your code you say that the IrDA port is on the UART5. I looked at every documentation I had and I found nothing that mentions this.

So my question are:
- Is really IrDA on the UART 5? Is really the base address 0xBE540000?
- Do you think this port act like a classic serial port?
- There is a irda.prx in the 3.02 firmware that is not in the 1.5? What does it mean?

My homebrew (PspIrDA) is mainly good, old C so I not really familiar with the specific PSP stuff (sce...). I'm a bit stuck rigth now.

MaT (Tryng to speak correctly English :)

Post by **TyRaNiD** » Sat Jan 13, 2007 2:35 am

What crash do you get ? And are you running in kernel mode ? None of those bits and piece will work (they will crash) if you are not in kernel mode :)

Mat17 · Post by **Mat17** » Sat Jan 13, 2007 4:19 am

TyRaNiD wrote:What crash do you get ? And are you running in kernel mode ? None of those bits and piece will work (they will crash) if you are not in kernel mode :)

No my app was not running in kernel mode.

I've just tried in kernel mode and it doesn't crash.

When I set the speed to 9600bps the app works normally but when I change the speed (19200bps for example) can't read what the phone send so something happen.

I have to investigate. It's a good start.

Thanks again

MaT

chrismulhearn · Post by **chrismulhearn** » Sat Jan 13, 2007 5:25 am

Checkout this thread: http://forums.ps2dev.org/viewtopic.php?t=5123

Its got code for talking directly to the serial port on the headphone jack. probably works the same, just change the base address.

Oh the code for changing the baud rate seems to be missing.

int serialport_setspeed(struct serialport * port, unsigned int baudrate) {
*(port->baudh) = (96000000 / baudrate) >> 6;
*(port->baudl) = (96000000 / baudrate) & 0x3f;
unsigned int x = *(port->control);
*(port->control) = x|0x00000006;
}

Mat17 · Post by **Mat17** » Thu Feb 22, 2007 4:55 am

I've tried to write and read directly on the irda port by reading and writing at 0xBE540000 (quite the some code as in the sdk for sio) and it works.

But when I try to use this method in my app (PspIrDA), I can't respect the protocol timing . this problem does not appear with sceiowrite/read method.

Do you think there is some buffering that slow down the sending of data packet?

gbj1 · Post by **gbj1** » Thu Feb 22, 2007 8:05 pm

There is a kernel cache flush after sceIoWrite. Cache delay also happens if I use kprintf() to output something on the screen, but I'm not sure wether it would happen in your case.

Mat17 · Post by **Mat17** » Thu Feb 22, 2007 9:17 pm

gbj1 wrote:There is a kernel cache flush after sceIoWrite. Cache delay also happens if I use kprintf() to output something on the screen, but I'm not sure wether it would happen in your case.

Which cache? Data, instructions or some IO cache?

Is it possible to know exactly which operations are done during a sceiowrite/read? Or can we avoid using cache for read/write operations?

Can this functions ...
sceKernelDcacheWBinvAll();
sceKernelIcacheClearAll();
sceKernelDcacheWritebackAll();
sceKernelIcacheInvalidateAll();
...be of any utility in my case?

Plain C is easy but you come to the hardware it's much more complicated.

gbj1 · Post by **gbj1** » Fri Feb 23, 2007 3:09 am

Code: Select all

sceKernelDcacheWritebackAll&#40;&#41;;

it would help, depends on how the firmware deals with the data frames.
If the data frames are generated immediately after a 'send(pBuf, len)' and there is a timer to raise the 'send' event inside the firmware, it is possible to find a way to flush the cache.
But if the stack was invoked by a timer to handle incoming/outcoming data and the timer is fixed on a 'sampling speed', I think you'd better have a patch on the firmware or just implement another irda protocol stack.

My understanding of your problem:
You can change the port baudrate manually by setting hardware registers, but there happen to be an built-in irda protocol stack in the _firmware. It seems that the stack is fixed on a specific baudrate and it's not flexable. So setting to higher baud-rate won't help, data blocks are generated to fit a 'slow rate'.
So you can receive something if you set the baudrate to 115,200, data were transmitted at 115,200 but it just comes slow, frame by frame, isn't it?

Please correct me if I misread your post.

Mat17 · Post by **Mat17** » Fri Feb 23, 2007 10:41 pm

gbj1 wrote:Please correct me if I misread your post.

My post was not very clear.

PspIrDA implements an (almost) full IrDA stack (from IrObex to IrLap layer) that I have found on the web (BSD license) and that I have optimized for compatibility.

The problem is with the last layer of the protocol, IrPhy, the "physical" layer.

When I use sceiowrite/read calls to send and receive data it works perfectly because the irda port is configured by default at 9600bps which is also the default bitrate of the obex protocol.

But 9600bps is very slow so I want to increase the bitrate up to 115200bps. This is why I started this thread. I've looked through the code sio.c (UART4) and modified it to work with UART5 (IR).

By reading and writing directly at the address of the UART 5 FIFO, I can send and receive bytes via IR. BUT, this is were I'm stuck, writing seems to be buffered so the bytes are sent but too late and so the timing of the protocol (wait before emission/reception) are not respected and the other device stop the communication.

Is it clear? :)

So I'm need help to find:
- what is different between a "sceiowrite" and a "while(_lw(PSP_UART5_STAT) & PSP_UART_TXFULL); _sw(ch, PSP_UART5_FIFO);" ??? cache problem???
- why do I need to call sceioopen("irda0:", PSP_O_RDWR, 0); before writing/reading the UART 5 FIFO??? some magic initialization???
- if it could a problem of interrupt?

A lot of questions...

gbj1 · Post by **gbj1** » Sat Feb 24, 2007 7:57 pm

the most simple way to access a serial port: (fake codes)
while(!txd_busy)
{
_set_txd_busy();
_copy_data_to_txd_buf_();
_flush_buf();
_clr_txd_busy();

}

I think you won't meet any problem if you do the raw port access and immediately flush the data cache.

sceioopen() should initailize the processor register flags to enable uart interrupt as well as internal timer for the baudrate counter.

Post by **TyRaNiD** » Sat Feb 24, 2007 10:11 pm

Not sure if it will help buy you might want to call sceSircsEnd before doing any direct access to the IRDA uart, who knows what that is doing in the background. Still cant you increase the baud rate and then just use the normal sceIoWrite/Read/Open anyway ?

gbj1 · Post by **gbj1** » Sun Feb 25, 2007 1:55 am

It should work if you change the baudrate after the firmware's own initilize. But there might be some difference between a standard uart and an IR(i.e. another IR-LED driver chip)

adrahil · Post by **adrahil** » Sun Feb 25, 2007 3:33 am

unload sircs and irda prxs....

Mat17 · Post by **Mat17** » Sun Feb 25, 2007 5:26 am

adrahil wrote:unload sircs and irda prxs....

Good idea! I'm not a specialist in prx but I will try it

KickinAezz · Post by **KickinAezz** » Tue Feb 19, 2008 7:25 am

Great Homebrew, but this guy disappeared... I tried to contact him via email few times but no responce.

Is anyone else familiar with IrDA obex, who can take over this project?

PS: It's open Source

Art · Post by **Art** » Tue Feb 19, 2008 8:20 pm

Same place as the guy who wrote the web server that kept clapping out after a few minutes.
You know, the one I probably could have fixed had he left his source behind.
Prolly got a job or something :D