I'm glad to announce that i was able to reprogram ChatPad's firmware and send some strings to the PSP via SIO interface.
BAD NEWS:
1) everybody willing to have the chatpad working with his PSP have to reprogram it as i'm doing...all software is freeware, but you need programmer hardware (at least an homemade JDM programmer like mine)
2) forget about backlight...it draws too much current [FIXED: the chatpad is now working with full backlight...]
GOOD NEWS:
1) IT WORKS WITHOUT BATTERIES!!!!
2) it only needs three solderings
3) the required hardware (without plastics fitting into the xbox controller) is very small and nice
Current firmware i flashed does only send the string "OK.." to a console program, but i already coded the translation map for each charachter present on the keyboard, and a working firmware will be released asap, together with all hardware info i figured out.
Now, as i already said in another post, if someone dealing with pspIRkeyb or pikey (or what the heck is belonging to the use of a keyboard under PSP platform) needs some special functions or whatever, please tell me BEFORE i begin writing the hard part...i would avoid rewriting the whole code again in the end.
Seeing a lot of people trying to do the same thing i managed to do, to use their chatpad with PCs or Palms, i plan to release upgrades in the future, so if anybody is interested in contributing the "Open Keyboard Project" in any way, feel free to contact me.
jean
Open Keyboard Project
Open Keyboard Project
Last edited by jean on Mon Feb 25, 2008 10:05 pm, edited 1 time in total.
Nice project jean. Here are some pictures of a chatpad (for others like me that are not familiar with it):
http://nuxx.net/gallery/v/acquired_stuf ... 0_chatpad/
http://nuxx.net/gallery/v/acquired_stuf ... 0_chatpad/
A T6 Torx driver is all that is needed to open the Xbox 360 Chatpad
Luckyly i managed to open the chatpad without that tool and it opened without effort - no scratches... a small flat tool will be enough (since torx is exagonal you only need a flat screw driver little enough to fit into it... i HATE three segments screws)...A T6 Torx driver is all that is needed to open the Xbox 360 Chatpad
hmm, looks pretty good, especially if the outer casing is removed and the internals reboxed, flashable pic so asume thats how jean is re-programming.
Did you say you were going to post the micro code when your done? You writing in asm or c?, post the mplab project complete if you want and i will see where i can help, have a range of compilers at disposal ( hi-tec etc ) so just chose the ide/toolchan
Did you say you were going to post the micro code when your done? You writing in asm or c?, post the mplab project complete if you want and i will see where i can help, have a range of compilers at disposal ( hi-tec etc ) so just chose the ide/toolchan
The first code i wrote is little enough to compile with free version of mikroC...it produces middle assemblies too and porting to MPLAB's C is a piece of cake. The real pain in the a** was flashing... you need a programmer with voltage control (or, like i found, a normal JDM leaving GND unconnected...don't ask me why, but it works). Pic 16f883 can be programmed with PicPgm or with WinPic (the last one requires the devices configuration to be updated with this definition i created for the purpose [dammit, my FTP is going mad...will post this as soon as it heals...hope other links are working]) through JP1 connection. If my website returns up, i will post schemes, tricks etc...
For the moment chatty is dissected on my desktop :) but i plan not to use white plastics...once done i will cover back of the keyboad with plastic cutted from a CD's jewel case covered with black adesive...original screws (the little ones) will help holding it down....but i'm not sure....maybe i'll cut upper white part (the one gray keyboard fits in) to have more rigidity - it will be small as well..Very nice, are you using any of the white moulded part as part of the new case
Here's the video of me connecting the chatpad to PSP and taping nonsenses.... :) please notice it's backlit with the only power supplied from SIO port....
http://www.youtube.com/watch?v=DYfvaC9T7O4
And here's an archive with some of the docs i've prepared...
[[link removed]]
Hereby i plan to insert a "config mode" accessible holding [people] button for long...it will show options as typed text, so you can see what are you doing if you run a console program... some ideas:
baudrate (1-9): 2400, 4800, 9600, ...
backlight: always on, always off, on for 5 secs after a type, on for 10 secs after a type
alts: hold and type, press once and lock until a type
non-char: send non printable data, don't send non-printable data (shift press, people press, ...)
repeat: repeat pressed keys quick, repeat pressed keys slow, do not repeat pressed keys
mode: pure serial, escaped pressed/released, raw
remote control: accept commands on rx line, do not accept commands on rx line
Only plain serial send is implemented by now, someone should tell me WHAT a driver expects to receive in "advanced mode"....
Oh, and -i forgot- ....here's a serial console, if you don't have one to try...
[[link removed]]
press x to swap between codes and chars...
jean
http://www.youtube.com/watch?v=DYfvaC9T7O4
And here's an archive with some of the docs i've prepared...
[[link removed]]
Hereby i plan to insert a "config mode" accessible holding [people] button for long...it will show options as typed text, so you can see what are you doing if you run a console program... some ideas:
baudrate (1-9): 2400, 4800, 9600, ...
backlight: always on, always off, on for 5 secs after a type, on for 10 secs after a type
alts: hold and type, press once and lock until a type
non-char: send non printable data, don't send non-printable data (shift press, people press, ...)
repeat: repeat pressed keys quick, repeat pressed keys slow, do not repeat pressed keys
mode: pure serial, escaped pressed/released, raw
remote control: accept commands on rx line, do not accept commands on rx line
Only plain serial send is implemented by now, someone should tell me WHAT a driver expects to receive in "advanced mode"....
Oh, and -i forgot- ....here's a serial console, if you don't have one to try...
[[link removed]]
press x to swap between codes and chars...
jean
Last edited by jean on Thu Jul 17, 2008 6:16 pm, edited 1 time in total.
hi could you post your source for the psp terminal prog please?, for those of us still learning our way round psp programming.
Also did you emulate the remote data comms with the psp to fool psp to keep the remote power on, i was reading somewhere that power is of if no valid data from remote within 5 sec?
Am making mplab project for design, for people.
notes.
Remember to implement delay/debounce algorithum ( plenty example on net )
You will prob have to allow for multiple keypress ( change "modes" by ctr and something etc... you just chose, not important for compatibility ) so code will be bit more complex but nothing OTT.
Implement as many characters displayed on keys as possible, you have no code space probs so go nuts with the lookup table.
Modes.
1)IR compatibility mode. Data packet to emulate popular ir kbd ( targus ? )
2)Terminal mode, standard terminal
3)Advanced mode... implement all your cool/complex ideas that may be cool but a bit hard to integrate into pikey/irkbd
4)....X) Modes for other systems
Code
pspIRKBD needs to be updated to include chatpad as one of config options then devs can re-link/complile with ease. For pikey a simple change to sio input module will do.
Also did you emulate the remote data comms with the psp to fool psp to keep the remote power on, i was reading somewhere that power is of if no valid data from remote within 5 sec?
Am making mplab project for design, for people.
notes.
Remember to implement delay/debounce algorithum ( plenty example on net )
You will prob have to allow for multiple keypress ( change "modes" by ctr and something etc... you just chose, not important for compatibility ) so code will be bit more complex but nothing OTT.
Implement as many characters displayed on keys as possible, you have no code space probs so go nuts with the lookup table.
Modes.
1)IR compatibility mode. Data packet to emulate popular ir kbd ( targus ? )
2)Terminal mode, standard terminal
3)Advanced mode... implement all your cool/complex ideas that may be cool but a bit hard to integrate into pikey/irkbd
4)....X) Modes for other systems
Code
pspIRKBD needs to be updated to include chatpad as one of config options then devs can re-link/complile with ease. For pikey a simple change to sio input module will do.
If pspirkeyb is altered to have a chatpad driver, then pikey doesn't need anything special done - just recompile with the new pspirkeyb library.jube wrote: pspIRKBD needs to be updated to include chatpad as one of config options then devs can re-link/complile with ease. For pikey a simple change to sio input module will do.
Ok, yesterday i was too tired to type anymore, but i announced i have some specific questions:
scancodes:
now, chatpad is outputting ascii codes as the button is pressed, without repeatition, altering case (if you type [shift]+[t] it will output "T") but for serious usage, device driver sould care about this, receiving from keyboard only scancodes on press and release events...that's not difficult; the question is: does pspirkeyb have its own scancode translation tables? (sorry, i could have take a look by myself, but i cannot do everything by myself...i don't have the time) I mean...if there's no problem, i could output an arbitrary scancode (let's say 1 for [1], 11 for [q] and 47 for [red]) with the most significant bit set to 1 for "press" event, 0 for "release" event (129 = [1] pressed). Someone can help me wasting the littlest time i can and say what a keypress event would look like in a well known ir keyboard? Maybe it's useless i code something similar but not equal to it.
audio:
well, no problem for an hardware passthrough, or even having the audio connector's tip cut (i saw it on deniska's site) to leave speakers on, but i think it would be better to force speakers on or off in software from the psp driver (there's a deniska's post about this somewhere)... someone can investigate if this is possible without interfering with normal programs operations?
remote emulation:
Good idea!! i don't think it would be difficult to implement it relying on the code you can find here (http://nil.rpc1.org/psp/remote.html)...but it's not my first priority now (if you can use pikey, who cares about remote emulation...)
POWER SAVING:
by now chatpad is running 4Mhz continuously scanning keys, backlights always on. Well, i think that
1) light can be configured to shut after 5sec from last press/release event (eventually configurable or switchable on the fly) what do you think? maybe it's a bit overkill...maybe we can turn on or off only holding [shift] for instance...
2) sleep - FOR THOSE PLAYING AROUND WITH MICROS: i could set speed 31Khz, set PORTB to raise interrupt on change, and set PORTA to all zeroes...so if something changes, i can "wake" the micro, set speed to whatever is needed, do a couple complete scans, send results and then set 31khz again...everything works fine until multiple presses occur on the same line and the mcu is in sleep mode...let's say i'm holding [r], then mcu goes to sleep, then i press [t]...the last press would not be detected. But (believe me) we need power saving. What would you do? maybe mcu can be put into sleep mode only if there are no key pressed and so on....
on psp side someone could begin implementing something like this... (accepting scancodes as 1-47 with the bit7 set or reset for press/release, forcing speakers on). I will surely help, but don't have the time to do it all by myself (i have to develop firmware on)
PS: no problem for the console sources...but it's only using the SIO driver i already posted. Anyway, I will post it..
scancodes:
now, chatpad is outputting ascii codes as the button is pressed, without repeatition, altering case (if you type [shift]+[t] it will output "T") but for serious usage, device driver sould care about this, receiving from keyboard only scancodes on press and release events...that's not difficult; the question is: does pspirkeyb have its own scancode translation tables? (sorry, i could have take a look by myself, but i cannot do everything by myself...i don't have the time) I mean...if there's no problem, i could output an arbitrary scancode (let's say 1 for [1], 11 for [q] and 47 for [red]) with the most significant bit set to 1 for "press" event, 0 for "release" event (129 = [1] pressed). Someone can help me wasting the littlest time i can and say what a keypress event would look like in a well known ir keyboard? Maybe it's useless i code something similar but not equal to it.
audio:
well, no problem for an hardware passthrough, or even having the audio connector's tip cut (i saw it on deniska's site) to leave speakers on, but i think it would be better to force speakers on or off in software from the psp driver (there's a deniska's post about this somewhere)... someone can investigate if this is possible without interfering with normal programs operations?
remote emulation:
Good idea!! i don't think it would be difficult to implement it relying on the code you can find here (http://nil.rpc1.org/psp/remote.html)...but it's not my first priority now (if you can use pikey, who cares about remote emulation...)
POWER SAVING:
by now chatpad is running 4Mhz continuously scanning keys, backlights always on. Well, i think that
1) light can be configured to shut after 5sec from last press/release event (eventually configurable or switchable on the fly) what do you think? maybe it's a bit overkill...maybe we can turn on or off only holding [shift] for instance...
2) sleep - FOR THOSE PLAYING AROUND WITH MICROS: i could set speed 31Khz, set PORTB to raise interrupt on change, and set PORTA to all zeroes...so if something changes, i can "wake" the micro, set speed to whatever is needed, do a couple complete scans, send results and then set 31khz again...everything works fine until multiple presses occur on the same line and the mcu is in sleep mode...let's say i'm holding [r], then mcu goes to sleep, then i press [t]...the last press would not be detected. But (believe me) we need power saving. What would you do? maybe mcu can be put into sleep mode only if there are no key pressed and so on....
on psp side someone could begin implementing something like this... (accepting scancodes as 1-47 with the bit7 set or reset for press/release, forcing speakers on). I will surely help, but don't have the time to do it all by myself (i have to develop firmware on)
PS: no problem for the console sources...but it's only using the SIO driver i already posted. Anyway, I will post it..
Think jf is the man to implement the changes to pspirkbd to accomidate chatpad and the man to give you a full rundown on one of the supported ir kbds, the packet format, how it handles transitions etc. May even be the info you need in the pspirkbd docs, havent looked yet myself.
Remove light function altogether for now untill we investigate the power handling ( specifically current ) of the sio port, maybe keep overall current drain to levels we would expect from a real remote around 50ma im thinking ( maybe 75ma considering its 2.5ish v )
As for sleep you have answered most of the questions yourself, keep code as is just implement a delay to sleep, thus a user would have to press a key for eg..5 sec before system sleeps and you lose the second key, a situation you can just ignore for this proto run.
By way not seen the video, you are using a slim arnt you?
Remove light function altogether for now untill we investigate the power handling ( specifically current ) of the sio port, maybe keep overall current drain to levels we would expect from a real remote around 50ma im thinking ( maybe 75ma considering its 2.5ish v )
As for sleep you have answered most of the questions yourself, keep code as is just implement a delay to sleep, thus a user would have to press a key for eg..5 sec before system sleeps and you lose the second key, a situation you can just ignore for this proto run.
By way not seen the video, you are using a slim arnt you?
Most IR keyboards use a data packet that's something like this:
0xC0 GROUP_CODE SCAN_CODE 0xC1
They invariably always use 0xC0 and 0xC1 for some reason. A few don't send anything but the scan code. The scan code uses values less than 0x80 for key downs, and ORs 0x80 to the code for a key up (there's one keyb that doesn't do that, but all the rest do). When they use 0xC0/0xC1, they also skip the scancodes 0x40/0x41 to avoid any confusion as to whether it's a scan code or the packet markers.
The group code is used to identify the key in general, like if it's a number or a letter or a punctuation key. It's universally ignored by everyone, and some keyboards don't bother sending it. pspirkeyb does use tables to translate the scancode into key codes. Each driver uses its own tables. It's pretty simple to add a keyboard to the library.
So you have your choice - you could make it simple, like some keyboards:
SCAN_CODE
or you could make it more like most keyboards:
0xC0 GROUP_CODE SCAN_CODE 0xC1
or you could go for the gusto and add extra fields like the Palm:
0xC0 GROUP_CODE SCAN_CODE1 VERIFY_CODE1 SCAN_CODE2 0xC1
The Targus likes to send streams of 0xFFs before and after the data packet... I guess in case your receiving devices cannot pick up the 0xC0 in time to lock to the stream. So with the Targus you get:
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xC0 GROUP_CODE SCAN_CODE 0xC1 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF...
I can tell you now, you don't need that for the PSP. It has no trouble picking up bytes immediately. I suggest that you just send a code for each key and ignore things like the shift. Pressing 'T' should send the same code regardless of whether you're pressing shift or not. It's up to the the driver or app to interpret what shift means. Maybe it makes a/A, or maybe it makes a/CURSOR_LEFT. It all depends on what keys the keyboard has and how the driver author wishes to map the available keys to missing keys.
0xC0 GROUP_CODE SCAN_CODE 0xC1
They invariably always use 0xC0 and 0xC1 for some reason. A few don't send anything but the scan code. The scan code uses values less than 0x80 for key downs, and ORs 0x80 to the code for a key up (there's one keyb that doesn't do that, but all the rest do). When they use 0xC0/0xC1, they also skip the scancodes 0x40/0x41 to avoid any confusion as to whether it's a scan code or the packet markers.
The group code is used to identify the key in general, like if it's a number or a letter or a punctuation key. It's universally ignored by everyone, and some keyboards don't bother sending it. pspirkeyb does use tables to translate the scancode into key codes. Each driver uses its own tables. It's pretty simple to add a keyboard to the library.
So you have your choice - you could make it simple, like some keyboards:
SCAN_CODE
or you could make it more like most keyboards:
0xC0 GROUP_CODE SCAN_CODE 0xC1
or you could go for the gusto and add extra fields like the Palm:
0xC0 GROUP_CODE SCAN_CODE1 VERIFY_CODE1 SCAN_CODE2 0xC1
The Targus likes to send streams of 0xFFs before and after the data packet... I guess in case your receiving devices cannot pick up the 0xC0 in time to lock to the stream. So with the Targus you get:
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xC0 GROUP_CODE SCAN_CODE 0xC1 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF...
I can tell you now, you don't need that for the PSP. It has no trouble picking up bytes immediately. I suggest that you just send a code for each key and ignore things like the shift. Pressing 'T' should send the same code regardless of whether you're pressing shift or not. It's up to the the driver or app to interpret what shift means. Maybe it makes a/A, or maybe it makes a/CURSOR_LEFT. It all depends on what keys the keyboard has and how the driver author wishes to map the available keys to missing keys.
I wonder if you could power one of the LEDs by transmitting garbage serial out,
and into a capacitor. Might not be worth the runtime overhead, but it's an idea.
I'm looking at one on eBay Australia at the moment.
Thought they were a part of the controller, but they are just an add on,
which hopefully makes it cheaper.
and into a capacitor. Might not be worth the runtime overhead, but it's an idea.
I'm looking at one on eBay Australia at the moment.
Thought they were a part of the controller, but they are just an add on,
which hopefully makes it cheaper.
If not actually, then potentially.
current drain surely drops battery time down my shoes, but it should be not a problem for hardware integrity, since the chatpad's alimentation section has a so called "charge pump" that act as a sort of isolator, in fact you can test 4.00v on pic regardless of the tension you supplied (2.5 in our case)maybe keep overall current drain to levels we would expect from a real remote around 50ma im thinking
yeah, I know...in normal operation mode i will only send scancodes press/release events, but i would like to do as i'm doing for the "pure serial" mode... so for the moment i will probably go for single byte scancodes with MSB to signal press/release.I suggest that you just send a code for each key and ignore things like the shift
By way not seen the video, you are using a slim arnt you?
I own a phat, and that's what i'm using for my tests...no idea for slim, sorry.Which psp slim remote pin are you using for +ve ? which for DGND ? i have seen some debate on the matter
I'm controlling leds from pic's PORTC...bit 0 is for general backlight, subsequent (in an order i did not wrote down and don't remember) are to independantly control shift, green, people and red backlights.And, of course, i could half-power each of them in PWM fashion... I connected PSP's TX to chatpad's RX but i'm not using it at the moment...in future we could pass commands forth and back to flash leds, store configurations, etc... One good idea is: when the connector is inserted, the PSP side driver could send something; if chatpad answers, then send some config commands to chatpad and force speakers on...I wonder if you could power one of the LEDs by transmitting garbage serial out,
Oh, for some reason i keep forgetting to post this: if you like to try this thing on your own you should compile the source i already posted...i could post the .hex ready to flash, but i don't know if mikroC license allows it (anyhow, the version of mikroC i'm using is free to download). I must investigate. If someone has problems feel free to PM me. For the brave that are already experimenting, note this:
1) only free pic programmers that supports 16f883 are picPgm and winPic
2) winPic actually doesn't support 16f883, but it's configurable...i made this configuration to enable it to flash chatpads: [[link removed]]
3) whatever programmer software you use, configuration word is $20D4
4) whatever programmer software you use, if your programmer hardware doesn't support voltage control, try leaving GND unconnected during reflash. If you wonder what voltage control is, see this: http://users.tpg.com.au/btkelly/jdm_b.htm (anyway, if you wonder what voltage control is, maybe you shouldn't do this hack on your own...i'm not responsible of fried chatpads!!)
Jean
Last edited by jean on Thu Jul 17, 2008 6:16 pm, edited 1 time in total.
Hey jean, did I miss the reason why you have to reprogram it at all?
I had a look at one today, It's not called a Chatpad over here, but I think
it's the same thing. Is yours black? THe keyboard is grey on this one, and
I'm not sure if the LEDs are even there. It's about $48 Au.
I had a look at one today, It's not called a Chatpad over here, but I think
it's the same thing. Is yours black? THe keyboard is grey on this one, and
I'm not sure if the LEDs are even there. It's about $48 Au.
If not actually, then potentially.
The package is called the Messenger Kit. It includes the ChatPad and Headset (a microphone and one ear piece). These are all terms/names from the US package I just bought from WalMart (for $30 US). It looks just like the one in the pictures linked by Gizmo above - a white shell with grey keyboard and keys. You can't tell that the keyboard can be lit unless you activate the LEDs in a darkened room. There's a picture of that in that linked page, too.Art wrote: I had a look at one today, It's not called a Chatpad over here, but I think
it's the same thing. Is yours black? THe keyboard is grey on this one, and
I'm not sure if the LEDs are even there. It's about $48 Au.
well i cannot swear we couldn't reverse/use the original protocol, but i've tried and given up....much better to be in total control of the firmware and output standard codes....like J.F. said, you're probably looking at somewhat else than xbox's chatpad....i'm not using "standard" ps2 little keyboards with the circuit i posted in that other thread because of power requirements (i don't whant to carry around a 10 cm keyboard along with a 20cm battery pack...) I think that once we come out with a standard firmware/procedure and "official" proven suggested reflesh practices, it shouldn't be so hard for people to obtain their "Open Keyboard"...in addition to this, i'm fond of this nice little keyboard!!!
Well all becomes clear!!!!
Was wandering how the hell they powered a 5v pic and the other stuff from a 2.5 v source ( 1.95 v from the slim !!! ). A charge pump!!, cheap buggers could't spring for a propper buck converter. Still though it works so one cant complain.
A load is a load though, ( although this one is bloody dirty, scope it up if you have the chance and check the rms ripple, at full load, if its excessive lets say making up 20% of the dc value, bang a low ESR ( tant? ) cap in paralell with a electrolytic accross the supply near the connector ) and its being fed from a topside fet i bet which odviously has a Max Idrain rating too, depending on this device and current limiting in the drive circuit you may or may not burn out your fet with over current situations.
Looking at your work so far i think there is quite a bit of protection in the drive circuit ( which would figure, the designers would have taken EMC and ESD into account and both those point to elaborate overcurrent protection ) so your prob fine, and the other inputs should be quite robust prob with transorb/diode protection ( or perhaps buffered with something that has those built in ) again for EMC/ESD.
Good work so far, but since you have a phat why not just use ones of the many sexy ir kbd's ? Does the flakyness of the ir port wind you up or something :)
PSP Terminal source ?
Was wandering how the hell they powered a 5v pic and the other stuff from a 2.5 v source ( 1.95 v from the slim !!! ). A charge pump!!, cheap buggers could't spring for a propper buck converter. Still though it works so one cant complain.
A load is a load though, ( although this one is bloody dirty, scope it up if you have the chance and check the rms ripple, at full load, if its excessive lets say making up 20% of the dc value, bang a low ESR ( tant? ) cap in paralell with a electrolytic accross the supply near the connector ) and its being fed from a topside fet i bet which odviously has a Max Idrain rating too, depending on this device and current limiting in the drive circuit you may or may not burn out your fet with over current situations.
Looking at your work so far i think there is quite a bit of protection in the drive circuit ( which would figure, the designers would have taken EMC and ESD into account and both those point to elaborate overcurrent protection ) so your prob fine, and the other inputs should be quite robust prob with transorb/diode protection ( or perhaps buffered with something that has those built in ) again for EMC/ESD.
Good work so far, but since you have a phat why not just use ones of the many sexy ir kbd's ? Does the flakyness of the ir port wind you up or something :)
PSP Terminal source ?
They? Do you mean me? :) XBox is outputting 3- 3.6v.Was wandering how the hell they powered a 5v pic
To say the truth, according to the 16f883's datasheed, the pic works with just 2v - some milliampere. The charge pump is put there adjust comm levels or at least to feed backlight leds, i guess. Please note that i'm feeding chatpad as an xbox would do (i mean...on the same lines) but i'm doing serial communication directly on the pic's tx/rx pins avoiding buffering stages (for those unconfortable with circuits, here buffering has an electronic mean related to load balancing..nothing to share with FIFOs)
PS: here's the console code...it's a very simple version...i'm writing another
[[link removed]]
Last edited by jean on Thu Jul 17, 2008 6:17 pm, edited 1 time in total.
Ah got you !
Wow i should really look at the data sheets !!!, had no idea pic would opperate at those levels, thats very usefull info for my project!! In which case just ignore what i posted before , the cp in that config is not going to dirty the supply up to much at all.
In fact going to have to revisit microchip as searious micro's for real applications, have been working with arm7/9 for so long now have ignored pic altogether for 5 years !! If micochip got one of their products into an xbox accesorry then there must be something there, normally they are so damn expensive copmared to eg nxp lpc series that i just ignore em !
THANKS FOR CODE !!
Wow i should really look at the data sheets !!!, had no idea pic would opperate at those levels, thats very usefull info for my project!! In which case just ignore what i posted before , the cp in that config is not going to dirty the supply up to much at all.
In fact going to have to revisit microchip as searious micro's for real applications, have been working with arm7/9 for so long now have ignored pic altogether for 5 years !! If micochip got one of their products into an xbox accesorry then there must be something there, normally they are so damn expensive copmared to eg nxp lpc series that i just ignore em !
THANKS FOR CODE !!