PSPZ Project WIP

[jube]

hi guys, promised a psp touchscreen schematic a while ago, so here it is!
Its become part of a larger project which i have called PSPZ for want of a better name!
PSPZ objectivs
1.add touchscreen + software drivers to run on cfw only
2.add gsm phone+low rate (56k) gsm modem
3.re-case psp+additional components, move game buttons to seperate remote (ir,cos want a ir port for multi-remote function ) pad, leaving a sexy prada_phone style brick.
4.add additional battery life.

The circuit implements 1, and 2, but the modem/phone is not finished cos still hunting EXACTLY how mic is handled by the slim, so just ignore that part of circuit for a while !! ( not shown but modem switches analog mic/left channel when call in progress ) Note 1 !!!!! micro to drive all subsystems, this is deliberate cos need something SMALL!!!!
3 and 4 are quit trivial so am leaving em to the end ( ir implemented by pic and ir i/o module, ic2 or spi prob , )

Problems
1. am bit-banging the serial to the psp, (no USART on this micro) and software-recieving sio data from the psp, ( twice cos also paasig data through to modem )loads the micro to much and is just not good!!
2. no esd/emc protection, t.s. straight to micro pins, NOT GOOD !!!!
3. ripple/noise rejection in software only, not ideal
4. re-casing !!!!!!!!!!!!, going to be a b#%#ch
5. touch screen not transparent enough.


am now on the psp software part, will be asking for help but no longer a totall noooooob ( yeay !)

[jube]

(edit.. will post a re-sized immage :) as requested :) )

[jean]

[EDITED to seem less an idiot than i am...] You could try the escape technique to multiplex streams (it allows to mix segments of different length). Let's say an escape sequence begins with "/" and ends with ";" and that a "/" char can be handled through the escape sequence "//;"...if so, you can send arbitrary data and extract context from command coded inside escape sequencies. e.g.: /devicea;data of device a /deviceb; data of device b /devicea; .....

PS: oh, my....please resize that image!

[hlide]

oh, my....please resize that image!

or just make it an URL to clic.

the only part I may be interested in is about touchscreen. I'm quite curious about the details : which touchscreen you plan to use, how do you communicate with PSP, etc.

[jean]

There's a site that sells touch-sensitive films for about 20€...they comes with 4 contacts like the model shown in the big picture above. Someone once thought to replace analog stick with that, but a more elegant solution involves a micro (like a pic) that samples the two x,y values and send they over serial to PSP(i demonstrated with openKeyboard that such micros can be powered with SIO V+ only). Pic code doing this is quite trivial and parts not too expensive, but i never get involved because its use would be limited to dedicated apps. If i manage to finish my OSKHook pikey plugin, maybe this could be a funny and useful toy to build. [EDITED to seem less an idiot than i am...]

[jube]

yea sorry about the immage, it makes this post a real pain to read !! i have no idea how to resize-it, or should i post a new thread? wit smaller immage?

what i mean by bit banging is that am using software in the pic to simulate a USART, ( well 2 actuaaly ), cos this pic 's not got one!

data stream...

picside serial streams. ( 4 i/o pins)
1.)pass through ( 14400,n,8,1) for serial modem
2),5 byte position code internally generated from touchscreen a/d values (900,n,8,1)
3) IRDA data port controll sequences (900,n,8,1), from remote/game pad

this is encoded into a 32 byte data packet with crc, controll byte etc.. decoded by psp sio ( in the prx ) to the functions that require the serial data

psp_side data streams,

1) Calibration routine/data to pic touchscreen controller ( 900,n,8,1)
2) extendet AT commands to modem for dialing/sms etc ( 14400,n,8,1)


same encoding

( buffering of 32 bytes each side )


All this data shifting is taking a fair bit of pic instructions so thats why said not ideal, but hey it works ( on my test bed which is a bit different from the circuit above but functually identical )


Any 4 wire resistive matrix touchscreen can be used, min 700R accross any axis cos not using external fets on the ts supply lines

As for why?

Love the psp, if you look at the specs compared to most pda's it rocks!! but it lacks the features i want, so decided to add em!!, besides need a new phone !

But all this technical stuff is just a start!!, the har part will be re-casing, the final result MUST be smaller and sexier then the original psp, the gsm modem is tiny ( same unit used in phone-watches ) but still might have to ditch the umd which am loathed to do.

[jean]

I love the PSP,too and i would like to play with touchscreen sooner or later...my "why" was referred to the fact I completely misunderstood micro for microphone!!!! Very sorry (what a shame!)

Jean

[jube]

AH!!!

Got you jean,

no, all the analog voice/mic signals stay analog, the voice modem has its own voice/mic input/outputs, they are just mixed ( opamp mixer on modem ) into the psp mic/headphones lines during a call, this is controlled with the extra pic pin dedicated.

Have not really thought of docs yet, can release preliminary pic code, am writing in HI-TEC c, on MPLAB 8, prog with ICD2.

Hey jean, you finished your pi-key code?, you posted it anywhere? would be relly interested to see what you did !!!!!!

[jube]

hlide..

the system concept is actually working ( although at moment only displaying ts position on a pspdebug screen :), my tesbed is based on a pic dev board and only differs from the above circuit in that its using level shifters ( its a 5v testbed )

all.....

the concept can be applied with any microprocessor up to the job, save youself some grief and use one with 2 usarts !!, i just chose a pic cos it seems very popular among the homebrew crowd

[jube]

Hey jean,

My turn to appologise !!!, just read your post about escape sequece data stream merging PROPERLY!!, frigin good idea !!, needs a bit of development but changing my stream handling ovet to that system, thanks for suggestion!!

[jean]

I know this method can seem too complex to apply, but it allows for an infinite number of streams to be multiplexed, and if the number of streams is small, there's quite no overhead. Unknown streams are discarded transparently.
I'm quite used to finite-state-machine parsers/lexers...let me know if you need some help to implement this thing: maybe we could do something reusable... To be performing, this should be done through a fsm implemented with function pointer matrix, but to understand the principle, here's something simpler you can test in the meanwhile...
just some pseudo code:

Code: Select all

#define INSTREAM 0
#define INESCAPE 1

#define ESCAPECHAR '/'
#define ENDCHAR ';'

state = INSTREAM;
for (;;){

    char ch = getChar();

    switch(state){
        case INSTREAM: 
           switch(ch){
              case ESCAPECHAR: nextState = INESCAPE; clearEscSeq(); 
                                            break;
              default: addToProperStream(ch);
                          break;
           }
           break;
        case INESCAPE:
           switch(ch){
              case ENDCHAR: nextState = INSTREAM; execEscSeq(); break;
              default: addToEscSeq(ch);break;
           }
           break;
    }
    state = nextState;
}

void execEscSeq(){
   switch (escSeq){
       case "devA": currentStream = 0; break;
       case "devB": currentStream = 1; break;
       case "devC": currentStream = 2; break;
       case "devD": currentStream = 3; break;
   }
}

void addToProperStream(char ch){
    switch (currentStream){
        ...
    }
}

enjoy!
jean

[jube]

yep definatly the way to go !!

I like the fact that when whichever stream is not active there is no overhead to the psp-micro connection, whereas with the packet the overhead is fixed. Ok with this system no crc and controll byte, ( there would be no way to signal a particular byte belongs to the controll byte/word ? ) is possible but since the micro is in direct connection ( no appreciable wire lengh ) we can make the electrical connection very clean and noise free and just rely on accurate comms without error checking at all ( ok still could put crc on the USART code and psp sio.prx side but thats cutting our bandwith by half, only experementation will show if thats actually needed in real life.

looking at pic code to conver at mo, thanks for code snippet !!

[jean]

In future, i will provide a more performing fsm if you like the idea (i made a c# code generator for handling such situations). I think no error checking is needed at all. Think about the fact that your escape sequencies could be just one byte allowing for 256 streams muxing; on a side note, you could choose [enter] for escape-char, and '=' for escape-end obtaining someting like

Code: Select all

1=blablabla
2=bliblublo
...

that's concise, synthetic and readable (for debug purposes...)
Take into consideration that you have to bother a little to make pic do some buffering, just to avoid producing too small segments of data between escapes.
i.e. we don't want something like

Code: Select all

1=b
2=b
1=l
2=l
1=a
2=i
...

because escape overhead would become expensive. (problem: on pic, if you wait to have a buffer filled to send it, a communication with a device could not end exactly on a buffer boundary, delaying the transmission to host of the last chars to the next communication with device - if any. So a little timeout mechanism is needed, too)

For what concerns micro code, i felt comfortable with mikroC, take a look into openKeyboard sources...

jean

[jube]

hi all!!, long time no post. Been busy hacking honda motorcycle ECU's but finally got the touch screen working!!

All the code is good, here is a video was convinced to make. The good news is that the actuall unit will be ready to market very soon, both in add-on form and integrated.

Will be posting all technical stuff so peeps can maybe add the drivers to homebrew games etc?, i have just about completed a keyboard driver.


<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/5SUpHTbLFHU&hl ... ram><param name="allowFullScreen" value="true"></param><embed src="http://www.youtube.com/v/5SUpHTbLFHU&hl=en&fs=1" type="application/x-shockwave-flash" allowfullscreen="true" width="425" height="344"></embed></object>

[jube]

ok try this link instead!!!

bloody utube!

http://www.youtube.com/watch?v=5SUpHTbLFHU

[adrahil]

nice :)

[J.F.]

That's really good work! Very cool. :)

[jas0nuk]

Wow, amazing. Nice work :)

[Cpasjuste]

I agree that it's a really cool poject, keep up the good work :)

[jube]

thanks loads guys !!

its really nice to have support from ones peers.

in about a week time will post the serial packet format etc, i am planning to distrabute some development units for free to programmers who have touch screen application/game in mind ( and who are going to release their app/game ) the dev units will be functually identical to finished units but will be a lot rougher hardware wise.

I myself am writing a danzief port to be re-compiled into code that just requires a touch screen osk. Also on pikey but will have to talk to jf/jean about that one !!

[KickinAezz]

2.add gsm phone+low rate (56k) gsm modem

THis just adds a bulk of weight; Not of much use these days.

ALso make sure the dev units work with Phat PSP. :)

[jube]

damn, should have posted about that!!

Dropped the gsm phone/modem a while ago, cost wise its just a no go!! and it would have taken a blutooth port aswell to make the idea trully sexy which just did not sit with the wifi ( given the shit ariel the psp has )

Have retained the ir port, i think a touch powered learning remote app will be a killer!!

[KickinAezz]

damn, should have posted about that!!

Dropped the gsm phone/modem a while ago, cost wise its just a no go!! and it would have taken a blutooth port aswell to make the idea trully sexy which just did not sit with the wifi ( given the shit ariel the psp has )

Have retained the ir port, i think a touch powered learning remote app will be a killer!!

Bluetooth + IR + Touch = Kick asswsome! :D

[Cpasjuste]

If i can get a dev sample unit, i would be happy to improve my shell application (mypspmenu) to use it :)

Ps : Where are you from ?

[jean]

2.add gsm phone+low rate (56k) gsm modem

I was wondering about that, and i have very interesting ideas about gsm telephony (for voice, not modem for the moment). Everyone can get a nokia 3200 at no price (i have 4 scattered around my house). Like the greater part of mobile phones it has a nice serial port in wich you can feed standard AT commands (i.e. ATDT 00393281234567 to call +39 328/1234567, AT+CMGR 1 to retrieve a message... see a list here: http://www.activexperts.com/activcomport/at/nokia/) and the voltage level for that serial port does not require level adjustment for PSP to communicate with (i.e. you can connect the two units directy with simple cable). The GSM unit does not require screen or keyboard, so it may nicely fit in the UMD tray. Connect audio [in]/[out] to [added microphone]/[PSP's speakers] and you have a PSP-phone.

Smells like a MOD work uh?

jean

[donavanb]

Would there be any way that you could us the psp as a phone over bluetooth and just like all of the new cars out there that have the microphone on top of the driver seat and bluetooth in the cars radio system

[jube]

jean....... thats EXACTLY the way i added phone, bog standard AT commands and a simple analog MUX to feed the phone analog signals ( audio and mic ) into the psp audio system, use the micro to switch between the 2. I was going to use the gsm engine out of one of these watch phones where the gsm engine is truly tiny!!!! But after a bit of experementation there turned out to be some big problems.

1) actually i used a nokia 3something and even stripped down with no kbd,no ariel and no battery still way to big to fit in umd space.

2)watch phones are still $200+, not pracctical to spend that on this project

3)power drain is significant during call time, too many calls and you will half psp run-time

4)AT commands ( even extended ) dont access blue-tooth functions of phone

5) AT commands limmited in some areas such as adding numbers / contact names etcc

most of the above points can be overcome with a bit of hard work though but myself i abandoned that avenue, if you fancy going down that avenue i have some very cool PIC software for you!! I used MIKRO ( basic and c ) for a while, not bad, but dont work with ICD2 and very primative when it comes to debugging and simulation. Found myself with mplab 8x, and HITEC-PICC pro which although still buggy as hell produces code soooooooooooooooooo compact you simply would not believe, ( i think they use black magic to fit all that code into a 16f818 !!! )

[jube]

will be taking requests for dev units by pm about next monay, when have some ready!!! Will post when that is, and post "driver" code at same time.

[jean]

Well, i was thinking of it this way:
-i have so many cheap GSM phones in my drawers i would never buy that expensive watch-thing....hope one of them will fit in my PSP!! (the difference in size could lead to two different ways: UMD-shaped device so UMD tray could remain in its place, OR a bigger one, that will eventually require UMD tray to be removed)
-power drain, certainly, is a pain in the ass
-bluetooth is cool, but not vital in my perspective
-the homebrew managing phone device mantains a list of numbers (so no need to add they to sim through AT; SMS, too, are retrieved as they arrive, so no need to communicate each time with SIM)

I would like to know exact models of the stuff you're using or plan to use (bluetooth device, touchscreen, ...) as well as where you're from to understand how deep an eventual collaboration could be...

[jube]

well... am from UK but at moment resident in denmark.

Am not going forward with the gsm at all, was just offering to post the data from development i had done before dropping it.

The touch screen is done, well on the way to a commercial product. I ended up doing all the code from published papers and first principals, the GCLD MICRo Basic code and other posted code on the internet was CRAP!!!!!! Fine if your not searious but useless when designing for consumers.

The IR add-on is trivial.

How did the work on pikey go?, did you ever sucessfully replace the osk as you wanted?