concept how to make psptouch screen

[galaxy3arth]

I think the attiny84 mlf may be a better choice. can the usi be used for both its communication with the psp and for its "UART"? just wire the reset to one of the extra pins and when the code is written tell it that if a certain bit value is sent, to reset? if UART connection can be set this way then it will simplify this alot. so with this concept design above are we taking voltage from the serial with a step up transformer or are we getting voltage from external battery?
Post Merge: January 23, 2011, 01:02:15 PMif the at-tiny84 already has usi then doesn't it have some kind of on board serial communication code we could just modify. the mlf package will also give us extra pins maybe after testing the extra pins could be used to expand the serial port into like one or two more on the bottom of the touch screen addon.   

[1TONpete]

The power would come from an external battery which we use the same plug we use to charge the psp. hence the power port on our device. with extra battery we could include the programmer also maybe. depending on space.
Post Merge: January 23, 2011, 10:23:05 AMthink future expansion. Wireless remote could be added , maybe video out for the slim version. mic for skype.
btw this could be done without replacing faceplate if one wanted . Just pop out the acrylic lcd cover on the faceplate one allready has, and make a small notch in the faceplate bellow the the start button to allow the ribbon cable to escape out the faceplate.
the trick for the install is making the bottom part. The skype phone plastic shell comes in 2 versions fat and slim. Use the skype plastics and install our hardware.
Anyone Got any details on analog nub through sio? found some code that might do it but I have not looked for any kind of schematic for wiring yet.
Post Merge: January 23, 2011, 10:44:28 AMsample code from macro fire
this is from the analog file.

Code: [Select]

void *mfAnalogStickProc( MfMessage message )
{
switch( message ){
case MF_MS_INIT:
st_enable_movement         = true;
st_analogstick.deadzone    = 40;
st_analogstick.sensitivity = 1.0f;
st_analogstick.originX     = PADUTIL_CENTER_X;
st_analogstick.originY     = PADUTIL_CENTER_Y;
break;
case MF_MS_INI_LOAD:
return mfAnalogStickIniLoad;
case MF_MS_INI_CREATE:
return mfAnalogStickIniSave;
case MF_MS_HOOK:
return mfAnalogStickAdjust;
case MF_MS_MENU:
return mfAnalogStickMenu;
default:
break;
}
return NULL;
}

void mfAnalogStickIniLoad( IniUID ini, char *buf, size_t len )
{
const char *section = mfGetIniSection();
int deadzone, sensitivity, originx, originy;

st_enable_movement = true;

inimgrGetBool( ini, section, "AnalogStickMovement", &st_enable_movement );
if( inimgrGetInt(  ini, section, "AnalogStickDeadzone",    &deadzone )    ) st_analogstick.deadzone    = deadzone;
if( inimgrGetInt(  ini, section, "AnalogStickSensitivity", &sensitivity ) ) st_analogstick.sensitivity = (float)sensitivity / 100.0f;
if( inimgrGetInt(  ini, section, "AnalogStickOriginX",     &originx )     ) st_analogstick.originX     = originx;
if( inimgrGetInt(  ini, section, "AnalogStickOriginY",     &originy )     ) st_analogstick.originY     = originy;
}

void mfAnalogStickIniSave( IniUID ini, char *buf, size_t len )
{
inimgrSetBool( ini, MF_INI_SECTION_DEFAULT, "AnalogStickMovement",    true );
inimgrSetInt(  ini, MF_INI_SECTION_DEFAULT, "AnalogStickDeadzone",    40 );
inimgrSetInt(  ini, MF_INI_SECTION_DEFAULT, "AnalogStickSensitivity", 100 );
inimgrSetInt(  ini, MF_INI_SECTION_DEFAULT, "AnalogStickOriginX",     PADUTIL_CENTER_X );
inimgrSetInt(  ini, MF_INI_SECTION_DEFAULT, "AnalogStickOriginY",     PADUTIL_CENTER_Y );
}

void mfAnalogStickAdjust( MfHookAction action, SceCtrlData *pad )
{
if( st_enable_movement ){
padutilAdjustAnalogStick( &st_analogstick, pad );
} else{
pad->Lx = PADUTIL_CENTER_X;
pad->Ly = PADUTIL_CENTER_Y;
}
}

void mfAnalogStickMenu( MfMenuMessage message )
{
static MfMenuTable   *menu;
static HeapUID       pheap;
static unsigned char sensitivity;

SceCtrlData *pad, pad_dupe;
pad = mfMenuGetCurrentPadData();

switch( message ){
case MF_MM_INIT:
dbgprint( "Creating analogstick menu" );
menu = mfMenuCreateTables(
1,
7, 1
);
pheap = mfMemoryTempHeapCreate( 3, sizeof( MfCtrlDefGetNumberPref ) * 3 );
if( ! menu || ! pheap ){
if( menu ) mfMenuDestroyTables( menu );
if( pheap ) mfMemoryHeapDestroy( pheap );
return;
}

{
MfCtrlDefGetNumberPref *pref_deadzone    = mfMemoryHeapCalloc( pheap, sizeof( MfCtrlDefGetNumberPref ) );
MfCtrlDefGetNumberPref *pref_sensitivity = mfMemoryHeapCalloc( pheap, sizeof( MfCtrlDefGetNumberPref ) );
MfCtrlDefGetNumberPref *pref_origin      = mfMemoryHeapCalloc( pheap, sizeof( MfCtrlDefGetNumberPref ) );

pref_deadzone->unit  = "(0-182)";
pref_deadzone->max   = 182;

pref_sensitivity->unit = "% (0-200)";
pref_sensitivity->max  = 200;

pref_origin->unit = "(0-255)";
pref_origin->max  = 255;

sensitivity = st_analogstick.sensitivity * 100;

mfMenuSetTablePosition( menu, 1, pbOffsetChar( 5 ), pbOffsetLine( 6 ) );
mfMenuSetTableEntry( menu, 1, 1, 1, MF_STR_ASA_MOVEMENT, mfCtrlDefBool, &st_enable_movement, NULL );
mfMenuSetTableEntry( menu, 1, 2, 1, "", NULL, NULL, NULL );
mfMenuSetTableEntry( menu, 1, 3, 1, MF_STR_ASA_DEADZONE, mfCtrlDefGetNumber, &(st_analogstick.deadzone), pref_deadzone );
mfMenuSetTableEntry( menu, 1, 4, 1, MF_STR_ASA_SENSITIVITY, mfCtrlDefGetNumber, &sensitivity, pref_sensitivity );
mfMenuSetTableEntry( menu, 1, 5, 1, "", NULL, NULL, NULL );
mfMenuSetTableEntry( menu, 1, 6, 1, MF_STR_ASA_ORIGIN_X, mfCtrlDefGetNumber, &(st_analogstick.originX), pref_origin );
mfMenuSetTableEntry( menu, 1, 7, 1, MF_STR_ASA_ORIGIN_Y, mfCtrlDefGetNumber, &(st_analogstick.originY), pref_origin );
}
mfMenuInitTable( menu );
break;
case MF_MM_TERM:
mfMenuDestroyTables( menu );
mfMemoryHeapDestroy( pheap );
return;
default:
st_analogstick.sensitivity = sensitivity / 100.0f;

pad_dupe = *pad;
mfAnalogStickAdjust( MF_INTERNAL, &pad_dupe );

pbPrint( pbOffsetChar( 3 ), pbOffsetLine(  4 ), MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, MF_STR_ASA_DESC );

pbLineRectRel( pbOffsetChar( 60 ) - ( 128 >> 1 ) - 1, pbOffsetLine( 18 ) - ( 128 >> 1 ) - 1, ( 256 >> 1 ) + 2, ( 256 >> 1 ) + 2, MF_COLOR_TEXT_FG );
pbLineCircle( pbOffsetChar( 60 ) + ( ( st_analogstick.originX - PADUTIL_CENTER_X ) >> 1 ), pbOffsetLine( 18 ) + ( ( st_analogstick.originY - PADUTIL_CENTER_Y ) >> 1 ), st_analogstick.deadzone >> 1, MF_COLOR_TEXT_FC );

/* ’²®‘OÀ•W‚̈ʒu‚ðŽ¦‚· */
pbLine(
pbOffsetChar( 60 ) + ( ( pad->Lx - PADUTIL_CENTER_X  ) >> 1 ),
pbOffsetLine( 18 ) - ( 127 >> 1 ) - 1,
pbOffsetChar( 60 ) + ( ( pad->Lx - PADUTIL_CENTER_X  ) >> 1 ),
pbOffsetLine( 18 ) + ( 127 >> 1 ) + 1,
( MF_COLOR_TEXT_FC & 0x00ffffff ) | 0x66000000
);
pbLine(
pbOffsetChar( 60 ) - ( 127 >> 1 ) - 1,
pbOffsetLine( 18 ) + ( ( pad->Ly - PADUTIL_CENTER_Y ) >> 1 ),
pbOffsetChar( 60 ) + ( 127 >> 1 ) + 1,
pbOffsetLine( 18 ) + ( ( pad->Ly - PADUTIL_CENTER_Y ) >> 1 ),
( MF_COLOR_TEXT_FC & 0x00ffffff ) | 0x66000000
);
pbPoint( pbOffsetChar( 60 ) + ( ( pad->Lx - PADUTIL_CENTER_X  ) >> 1 ), pbOffsetLine( 18 ) + ( ( pad->Ly - PADUTIL_CENTER_Y ) >> 1 ), MF_COLOR_TEXT_FC );

/* ’²®ŒãÀ•W‚̈ʒu‚ðŽ¦‚· */
pbLine(
pbOffsetChar( 60 ) + ( ( pad_dupe.Lx - PADUTIL_CENTER_X  ) >> 1 ),
pbOffsetLine( 18 ) - ( 127 >> 1 ) - 1,
pbOffsetChar( 60 ) + ( ( pad_dupe.Lx - PADUTIL_CENTER_X  ) >> 1 ),
pbOffsetLine( 18 ) + ( 127 >> 1 ) + 1,
( MF_COLOR_TEXT_FG & 0x00ffffff ) | 0x66000000
);
pbLine(
pbOffsetChar( 60 ) - ( 127 >> 1 ) - 1,
pbOffsetLine( 18 ) + ( ( pad_dupe.Ly - PADUTIL_CENTER_Y ) >> 1 ),
pbOffsetChar( 60 ) + ( 127 >> 1 ) + 1,
pbOffsetLine( 18 ) + ( ( pad_dupe.Ly - PADUTIL_CENTER_Y ) >> 1 ),
( MF_COLOR_TEXT_FG & 0x00ffffff ) | 0x66000000
);
pbPoint( pbOffsetChar( 60 ) + ( ( pad_dupe.Lx - PADUTIL_CENTER_X  ) >> 1 ), pbOffsetLine( 18 ) + ( ( pad_dupe.Ly - PADUTIL_CENTER_Y ) >> 1 ), MF_COLOR_TEXT_FG );

pad_dupe.Buttons |= padutilGetAnalogStickDirection( pad_dupe.Lx, pad_dupe.Ly, 0 );
{
unsigned short test_cross_offset = pbMeasureString( MF_STR_ASA_TEST_DIR ) + pbOffsetChar( 1 );
pbPrint( pbOffsetChar( 3 ), pbOffsetLine( 24 ),  MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, MF_STR_ASA_TEST_DIR );
pbPrint( test_cross_offset + pbOffsetChar( 5 ), pbOffsetLine( 23 ), pad_dupe.Buttons & PADUTIL_CTRL_ANALOG_UP    ? MF_COLOR_TEXT_FC : MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, PB_SYM_PSP_UP );
pbPrint( test_cross_offset + pbOffsetChar( 7 ), pbOffsetLine( 24 ), pad_dupe.Buttons & PADUTIL_CTRL_ANALOG_RIGHT ? MF_COLOR_TEXT_FC : MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, PB_SYM_PSP_RIGHT );
pbPrint( test_cross_offset + pbOffsetChar( 5 ), pbOffsetLine( 25 ), pad_dupe.Buttons & PADUTIL_CTRL_ANALOG_DOWN  ? MF_COLOR_TEXT_FC : MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, PB_SYM_PSP_DOWN );
pbPrint( test_cross_offset + pbOffsetChar( 3 ), pbOffsetLine( 24 ), pad_dupe.Buttons & PADUTIL_CTRL_ANALOG_LEFT  ? MF_COLOR_TEXT_FC : MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, PB_SYM_PSP_LEFT );
}
pbPrint( pbOffsetChar( 3 ), pbOffsetLine( 27 ),  MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, MF_STR_ASA_TEST_MOVE );
pbPrintf( pbOffsetChar( 5 ), pbOffsetLine( 28 ), MF_COLOR_TEXT_FC, MF_COLOR_TEXT_BG, "%s (X,Y) = ( %03d , %03d )", MF_STR_ASA_TEST_MOVE_RAW, pad->Lx, pad->Ly );
pbPrintf( pbOffsetChar( 5 ), pbOffsetLine( 29 ), MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, "%s (X,Y) = ( %03d , %03d )", MF_STR_ASA_TEST_MOVE_ADJ, pad_dupe.Lx, pad_dupe.Ly );

if( ! mfMenuDrawTable( menu, MF_MENU_NO_OPTIONS ) ) mfMenuProc( NULL );
break;
}
}

const PadutilAnalogStick *mfAnalogStickGetContext( void )
{
return &st_analogstick;
}


[galaxy3arth]

use tokyodrifts ps2 controller on psp stuff has every thing you need and heres the schematic.
if its wrong let me know because I didnt know much about any of this before I started the thread. I cant do any coding I am telling you now I do not know more than slightly informed about assembler. I need somebody else to do this based on the schematic. the UART may be wrong (I have no idea how to use them or what they look like o anything I just know what it does). forgot the VCC and GND for the UART just imagine one ( I am pretty sure UART has these, common sense, but I again dont really know)
I kept the electrolytic capacitor it cant hurt anything
Post Merge: January 23, 2011, 02:08:31 PMthe squares are test pads, and there is another ground at the bottom of the attiny84MLF
Post Merge: January 23, 2011, 02:09:55 PMif it cant be done this way as far as UART then I can just move the rx and tx for psp to some other pins.

[TokyoDrift]

could you please stop posting code all the time!?
it's not helping at all

okay, it works like this: PSP <-UART-> USI - AVR - ADC <-Touch Interface-> TouchScreen
so we need 6 IOs of the avr + GND + VCC + pullup on reset + cap on VCC/GND
apart from that you need a boost converter for the battery
you can also make the UART lines accessable from outside so that one could easily interface the bootloader on the avr for flashing
do NOT integrate a usb programmer, this is just useless, needs power and is an overkill
do NOT integrate hardware for a software usb, it wont work
this is basically a design with 2 ICs: the AVR in MLF and a boost converter in the smallest package we can find
do NOT use dip packages, only for prototyping maybe
I checked the MLF package, we can make it single sided (pretty sure, maybe some 0 Ohm resistors needed?)
do NOT copy'n'paste code, it won't work, get a coder
do NOT overload the AVR, PSP has enough power to calculate macros and stuff, AVR doesn't
USE a protocol, don't just stream data to the PSP

[TokyoDrift]

oh btw, don't forget the external clk source
the schematics are weird, use eagle or kicad or something pls

[TokyoDrift]

1: how would a touchscreen usually interface the psp so that there are touchscreen drivers available?
2: if there were touchscreen drivers, why would we even bother making this
3: have u ever seen anyone seriously using linux on their psp?
4: why do you think we'd want to use linux on our psp when we're obviously making this for GameOS?
and so on...

btw, the electrolytic capacitor hurts because it's a big ass component...

[galaxy3arth]

sorry man I dont have those so could I download it from the internet or not.
I dont plan on doing anything involving usb. ( the psp is not a host and never can be)
I get what you mean for the UART now thanks
DIPs are just too bulky and there is no need for them so I never considered using one.

Post Merge: January 23, 2011, 02:24:40 PMI get what you mean I will get rid of the capacitors.

[HiddenVenom]

1. USB/MiniUSB
2. Learning project? I dunno.
3. https://help.ubuntu.com/community/PSP
4. Sorry, I had no idea you were using GameOS. However most non-windows operating systems are UNIX-like.

[galaxy3arth]

yo guys this is a thread for touchscreen psp development not a sympathy board. KEEP ON TOPIC. no offense to hidden venom or anyone else but keep this bull:censored: off the thread.
Post Merge: January 23, 2011, 02:32:25 PMGEEZ arguements, what are we? three

[galaxy3arth]

I need the libraries for the attiny84 mlf for eagle.
cannot write schematic with out it

[1TONpete]

back on track. No usb agreed. serial port on the bottom to reflash agreed? an extra analog agreed? external power agreed? attiny85 or 84 mlf agreed , uart? I think some mapping has to be done inside the attiny , at least basic button control. let macros and presets be stored in a database or cfg file on memory stick or on psp? Im sorry for the code but  it is a major part of this concept. It also helps in reverse engineering. If we understand how others handle the communication through the sio it can help in the development of the hardware. Do we really know what this port is limited to yet?

[galaxy3arth]

all agreed but its the attiny84 mlf
Post Merge: January 23, 2011, 03:16:19 PMWe need a coder.
and
I...
neeeed... the...eagle...attiny...84...MLF...libraries!
 
or... I... am... going... to write... the next/final schematic.... on paint.
don don don

[1TONpete]

The guy to write this is TyRaNiD. As far lib's ill see what i can find.

[FOOKz™]

If i was your boss and all of you all worked for me I would have fired you guys by now; yeah sometimes theres a discrepancy here and there of opinions.... it's development!! Seeing is believing!! trial and error, post results ether its good or go back to the drawing board.

Please continue on topic. I was loving where this thread was going you guys just have to sort who does what and then when you find good information collaborate on how stuff can be improved/disproved.

tl;dr I never want to see this kind of bad collaboration again, if you're gonna disagree start your own dev thread else please have gracious professionalism when someone is wrong.

[1TONpete]

If i can get my hands on the rest of the neo's code I think I can modify it for our purpose.

[galaxy3arth]

We will be more professional because yes I get exactly what your saying we really would have been fired I actually thought this thread was going to split a couple of times.
Post Merge: January 23, 2011, 03:51:39 PMyeah I think I have some of it wasnt it all in the source?
Post Merge: January 23, 2011, 03:52:57 PMI am going to make another schematic in paint we can just make it in eagle later give me a second.

[1TONpete]

The src used was a demo game not the neo code its self. lol im looking for neo, does that make me morpheus ?
Post Merge: January 23, 2011, 04:10:05 PMSo who can bring "what" to the table?
what are we missing?
What can we do to test what we have so far?
My account at ps2dev wont work can anyone try and contact TyRaNiD?
If we get him I think our problems with code are over. Not to mention he's got all of the dev tools to test and debug all of this.
Once we have a final schematic I will build at least 3 of these to get into the hands of our devs.
Anyone got any idea on root keys? ie digitally signing our software to work with ofw.

[galaxy3arth]

I am totally lost on the implementation of the UART I am lost
somebody edit the schematic so far and add this please
Rx and Tx from psp through the UART to the attiny84 mlf

[Modded Matt]

i cleaned this thread up a bit. stay on topic please, if you disagree with the way this thread is going let me know and i can split it at anytime. It would be nice if everyone could woork together but that is just not allways doable.

everyone is welcome here to post ideas, develop a mod, or just hang out. but please do so without flaming other members.

[galaxy3arth]

agreed

[FOOKz™]

I am totally lost on the implementation of the UART I am lost
somebody edit the schematic so far and add this please
Rx and Tx from psp through the UART to the attiny84 mlf

The UART is a way to load serial data back and forth because its smaller

I say get some sort of bootloader on a PIC that can process USB i/o to read/write to a small fpga which runs everything you want to run.

its easy to keep open source using a programmable gate array plus it can do a lot of processing in a small package.

uart design compacts all of your circuitry to a few data wires instead of running parallel lines like a matrix. uart is slower but nothing noticeable since performance is not an issue.

[galaxy3arth]

kinda big but I had not considered this.
could you give me an example?

[FOOKz™]

usb/rs-232 it doesn't matter; almost the same thing.

the computer sends/receives data to the uart chip that translates complex commands into a native format within the devices.

the ATTINY84MLF communicates between the uart only when necessary. The computer will try to communicate constantly which the avr (ATTINY84) won't be able to handle all the processing needed to do all that.

now the Rx and Tx i dont know what those do... what are they?

[galaxy3arth]

can the attiny84 MLF be programed to use one of the pins for USI/UART?
I dont see why we cant just use direct Rx Tx to psp and use the ICP for reflashing. why is the UART needed?
is it just for saving space?

[FOOKz™]

can the attiny84 MLF be programed to use one of the pins for USI/UART?
I dont see why we cant just use direct Rx Tx to psp and use the ICP for reflashing. why is the UART needed?
is it just for saving space?

its saving processing power.

[galaxy3arth]

the Rx is the received data
the Tx is the transmitted data
they are the main data lines in the SIOport of psp
only two pins on the SIO port really needed.
 they use the rs232 protocol with adjusted voltages instead of (-5v,+5v) it is (0v,2.5v)

so basically the UART is better for program development and debugging on the AVR?

Would there be a noticable difference if we didnt use the UART?

[FOOKz™]

Would there be a noticable difference if we didnt use the UART?

A huge loss of avr performance because think about this ~ the computer is communicating with the avr without the uart chip So.... you're trying to do 7823478 billion things at once with 1 chip.

you have to detect user input from the touch pad and you have to send that data to the PSP... that pretty much uses all of the chip's resources already but now the chip also would have to communicate with the computer all the time as its connected... so the entire system will run slow since the bitrate of the chip is divided up more.

again the uart only communicates when communication is needed, so when you have rs-232 connected to the uart your uart would send a command to the avr saying "hey buddy, free up some resources we're talking now". then the avr chip reduces clock to the touch screen i/o and then you can configure whatever you have to...

Rx Tx would be only two pins yeah.

[1TONpete]

Question... How would we implement both touch and second nub? As far as programing goes can it be as simple as sending a package to the avr from the psp telling the avr to enable the nub? I dont think we need both the nub and the touch at the same time. How can we switch between the 2?

[galaxy3arth]

so for debugging/reflashing the performance would go down significantly.
part of the problems with the UART I am having is what pin if any on the attiny84mlf do I use for the usi ?
which model of UART should I use (cant really tell)?

Post Merge: January 23, 2011, 05:53:18 PMfor switching between duel nub and touch screen we could just do so from the psp side of things. there would not be much more processing added on as far as the AVR goes.
the AVR would just keep sending the analog info but the psp will just ignore it.

[HiddenVenom]

From a programming perspective:

Just sit waiting for one of them to get input, and the disable the other while it is being used. That way there is no button-pressing. Means that whatever is controlling them both has to be on an (almost) constant loop though.