Ps3 rapid fire studying and understanding project open source

[geraldrubalcava]

Edit: orko007, wow that alot of great info. so you haven't looked over hyper999 code? well then im not sure in what hyper thinks but it would be awesome if you can help us a lot plus only people here who have programmers will use the code. and one of the rules here in this forum is that people cant use it for monitory gain. of if people try to sell it on ebay then that's a big no no:)

well i have a complicated arduino setup. lol its the cheapest way i found. there are arduino clones out there that can be cheaper. i got one for 5 bucks and scavenged a usb to rs232 ttl so that solution was 5 bucks. but i got lucky. the one your looking at seems like a good build. its similar to http://yveslebrac.blogspot.com/2008/10/cheapest-dual-trace-scope-in-galaxy.html but the one you pointed out seems to have a faster one. i know you you feel, for me college drains my pockets lol i guess thats why i want a free ps3 rapidfire solution then to keep buying them. lol

well do you think you cam make one with comparators? so at least i can test one last time? if there is finally success then that works if not them i will start debugging with my o scope too. lol and when you get your you can also do it and i guess that would  be the alternative if it dosnt work. its up to you wann get a oscope? or want to code with comparators? ether way i will be here to test it out. and if anything i will do videos of debugging with the oscope and so you can get a inside look in how i do it 
Post Merge: August 28, 2010, 06:43:36 PMhey! orko007 i understand why u cant post any code lol well true if he gets his oscope them this would be smoothly. but i will also debugg. but thank you tho. one question. so did you use comparators or with analog read? but what you did is gave hope. so if anything can hyper email you the code and you can tell if anything is wrong or any notes? lol well thank you again

[orko007]

Forum Rules are one thing, what people actually do is another. Alot of what is on ebay has com from these forums. Luckily I have alot of unique mods and keep updating them and improving them which keeps my customer base up.

I have looked at one of hypers code posts somewhere on the first page. But here's the kicker. My ASM is very limited so without spending alot of time looking at it and referencing commands I have no idea what is going on, LOL. so maybe this is one point where you can call me a Noob but I use a higher level compiler as I was already familiar with the language.

I did not use any Comparator, I thought about it but the 12F683 has only 1 CCP module and so if I wanted to be able to look at R_Common and L_common using that chip I had to do something else.

I've been working on this literally all day and now I already have it working for ALL of the buttons except L3 and R3. I have it setup so you can enable or disable rapid fire for any button by holding down on the Dpad and pressing one of the buttons. I also implemented our standard rapid fire modes and speed setup. Still to come is burst fire, our jitter mod and a custom mode. In the end once you get the hang of how these controllers work it's actually easier to write code for than the 360. I definitely did not expect to be as far as I am in just 2 days of work.

With how well things have gone I hope to have a complete chip by next weekend that is better than the Intensafire and wont cost $70 or whatever that thing costs, you'll just have to solder some wires instead of just Clipping it on, but it will also work for all controller types.

Again all this would not have happened if I did not have an O-scope to check my work.


P.S. The common line for L3, R3, Start and Back works differently than the other two common lines and from what i have seen I think it will take connections to each of those buttons separately to be able to read and manipulate them. I will do more checking with those later.

Chris

[Hazer]

Thanks Chris. I can appreciate what it takes to offer that much help.

I keep an eye on this post, but I still wont be able to help here other than conceptual advice. If I actually start doing this again, I wont be using anything people can do at home.

Honestly, I have been waiting to get enough free time to make a USB flash chip. The ADC converter does work fast enough, but I would prefer the comparator and just use a PIC that has 3 of them. The reasoning is that the comparator hardware interupt is almost instantaneous. Well, I should say that the ADC capture time is 2 to 4 usec, whereas the typical comparator settling time is 200 nsec. With the ADC, you are constantly checking at a frequency of 2-4 usec not synced with the signal, but the comparator interupt happens directly with the falling edge. Its a faster response.

Anyways, as I mentioned, I wont be making any code unless its to go all out: USB firmware flash, USB conection to PC to configure frerquencies and macros without firmware flash, connection to all buttons. Ive already created a proprietary encoded flash program, but thats where my tinkering has stopped.

Plus, like was said by Chris earlier, you need the hardware too. I have dualshock myself just for testing the signals. Bad thing is the battery is dead. I have to use the USB cable to get it to power on, and I dont have a  PS3. I used that PC USB six-axis driver to configure the controller to my PC so I can see button presses, but I would much rather have a full hardware setup to start doing code. I dont know if the internal power is higher or lower when running purely off the battery.

Anyways, You guys should take Chives suggestion about just testing simple steps to the whole project, not coding everything at once. Untill you know what will work, the rest of the code is useless and would need to be rewritten anyways until you find the hardware/logic that works.

[hyper999]

ok try this
pin7 to rcommon
pin6 to led or oscope (i personally think oscope would be better )

pin6 will be low
the code waits for the first r2 pulse to be detected
then makes pin6 high for 8ms
then starts over

[802Chives]

Chris, I take a little offense to you saying I am not helpful enough, being as we are both coders I cannot find anything that you have posted that is more straightforward then my own... unless you just dont follow the terminology of assembly language and im just not helpful enough to you.  Either way Im a big boy and the tears have stopped, just know that you re-stated a lot of what I have already posted here in this thread in your two posts...

Im glad you have been so successful at getting your code to work, once I manned up and dropped the $1200 on a decent scope I had the intensafire code done and debugged in well under 40 hours, and If you look around the forum you will see myself saying the exact same thing to Hazer and RDC about how suprisingly easy it was and how much cleaner it is then my xbox codes.

If you look in our shop you will notice we dont sell BGR's PS3 device, even though I made the code.  That is because we do not stand behind it quality wise.   The code is very nice, but mediocre in terms of features.  It was however intended for the masses and they dont need rapid fire on start or R3, so if you are trying to take a shot at my code, it wont work because of that fact that that code was flashed 5000 times on the first run, and and I had to make it work so the most people possible will be happy. If i flashed onesy twosy chips, I could make any feature you want including burst, however with BGR's chip I was barely able to put rapid fire on R2, R1, and X in 7 modes including the edit mode and 7 modes is alread too many imho so burst got cut.  The clip is the part of that product i do not like because of both price and the fact that a clip can get jostled when you throw ur controller at the wall.  Im a solder monkey all the way.  Also my code works for all versions of the controller... the clip does not.

I thought about it but the 12F683 has only 1 CCP module and so if I wanted to be able to look at R_Common and L_common using that chip I had to do something else.

You only need 1 comparator for both Rcommon and Lcommon, because both signals are synced. (put one on each channel of your scope)  R2 and Digital Up are in sync... R1 and Digital Right are in sync.. ect.

Polling the ADC can make this code work, but I agree with Hazer, the comparator is still a better solution.  The only reason I used R2 is because it was for a clip and an extra pin was no big deal to add and the code for IOC is much simpler then using ADC or a comparator.


Sorry hyper and gerald for getting side tracked, there are ways to use your microphone input on a soundcard, as an opensource oscilloscope.  You will have to make probes for it, but I think in this situation it will be sufficient.  I have never used a USB scope, but it looks intriging.  What I really am trying to say is that you dont need a $1200 scope to do this, there are much cheaper alternatives because your really only dealing with speeds on the order of 10khz and not the 100mhz that $1200 gets you.

[orko007]

Hazer,

Not sure if you remember but last year we were PM'ing back and forth over on X-S about the COD5 Patch and Viking chip. Well i actually moved forward on that and designed a completely encrypted USB mod off the 18LF14K50. See attached picture. I finally have most of the issues worked out I'm just waiting right now in some of the updated PCB's to arrive before I start to sell them.
Now if Only I could find out where I could get a clip type adapter made up for the 360 (similar to intensafire's ps3 clip) it would make that installation alot easier. I would eliminate 14 of the 17 wires that need to be soldered.

As for this project yes the comparator would be faster and I will probably use the same 18LF14K50 chip in a PS3 USB mod which has two comparators which could be used for the L and R common lines. I believe that the R3, L3, Start and Back will need individual connections anyway. Even if it did not the smallest PIC with 3 comparators and USB is 28pins (18F26J53) and twice the cost if the 18LF14K50.
You would still need to use the ADC but just not as often since you could trigger off the comparator.

I probably won't make any more progress today as I have my NFL fantasy draft this afternoon. Then I need to work on things to ship for tomorrow. But I will be working to finish this up during the week.

I do hope you guys get it working, but I dread the flood to ebay of all your hard work. Also like both Hazer and and Chives said you should start out by flashing an LED. I actually did this as well to help me get started.
Post Merge: August 29, 2010, 08:26:55 AMChives,

I am sorry about that, my intent was not to discount things you have said and after I posted and re read it I thought it might come across that way. I just wanted to get them moving in the direction of using only one pin for the mod as that is what they ultimately wanted.

We both have chosen not to post our own code here for our own reasons, but this thread has been very helpful to me and I wanted to give back some of my own findings.

As for your code for BGR mods I assumed you codded whatever they asked for and as I said I keep myself in business by continuous improvement. I always want to have more features than the other guy but keep it easy to use. Now if only I had the marketing skills of BRG I would be all set.

Again my intent was not to be offensive and I apologize for that.

You also did just spark a "A DUH" moment in me though with your comment.

You only need 1 comparator for both Rcommon and Lcommon, because both signals are synced. (put one on each channel of your scope)  R2 and Digital Up are in sync... R1 and Digital Right are in sync.. ect.

I am actually only triggering off of the R common because I did see that they were sync'd. After the trigger I am using the ADC on both to read the state of each individual button, which will still be needed, but I don't know why I did not think of using the comparator for just the trigger. I will have to try switching that around this week and give it a go.

I used to hate the PS3 controllers but after this weekend, I wish that the 360 controllers where designed this way.

[geraldrubalcava]

Great hyper! i will test this put with my first controller and with my oscope. actually im getting everything ready now and im so exited  i will show you guys a pic if i can of the software. but hopefully the arduino adc is fast enough to read 5 ms. lol

hum i understand you guys cant post anything too specific because ther are probably some of you who wrote code for some other people.

orko007, Hazer, chives, modder matt and everyone ! you all have given great info about the rapidfire, even enough to get this started off and even further, thank you. i truly belive this post is woth sticking because of all the info.

and i dont know why orko007 has to mention his new chip. but i guess it was just getting distracted. but all of you are smart guys. hum i envy your coding skills (im more of a hardware guy) and you guys have to understand that we have ps3 so sometimes in theory it works but in games it dosnt. but i cant stress enough all the help you guys have given. Thank you!

[orko007]

I only mentioned it because Hazer said he would only get into it making a full USB mod and we had previously talked together about USB mods over on X-S for the 360. Sorry if it came off as trying to plug my product, but it's not even for sale yet.

[802Chives]

Chris no worries, it just felt like I was called out a bit... or it might have been the hangover i was battling this morning    reguardless im here to help everyone learn, and in this situation i feel like i am teaching these guys how to work through writing a code, which is much more valuable then just the opensource ps3 rapid fire. 

I got another one for you... you dont need to use an ADC to see the state of the buttons, it can be done digitally.  All you need ADC for is identifying the beginning of the wave train from there you can tell if buttons are pressed or not digitally.

[geraldrubalcava]

all right i probed pin 6 but i keeped getting a high state. im not sure in whats wrong but it was just outputting digital high. i will have a video in how im working with the oscope.

FILE0129

as for the usb product that would actually be pretty sweet!  i would buy if i had money lol and you guys all are great! so chives you still think we should go with two pins for reading R2 then write on rcommon? or something like comparators (a fancy way to do it).

[802Chives]

I still think you should get two pins working (using R2 and Rcommon) and then move on to a comparator or ADC solution. 

a simple loop code will verify if the pic can see R2, where RA0 is R2 line and RA1 is an led or better yet your scope probe:

Code: [Select]

BEGIN
      BTFSS    GPIO,RA0
      BSF       GPIO,RA1
      BTFSC    GPIO,RA0
      BCF       GPIO,RA1
      GOTO     BEGIN

just set RA0 as a digital input and RA1 as a digital output.  If you monitor the RA1 output you should see when the R2 line is low which signals the beginning of the signal train. (may not be visible to human eye in this method)

[hyper999]

ok well i think that the reasons that it only shows high are because
1. the resolution of your oscope
2. the time it takes for the pic to manipulate the pin
because it keeps it high for 8ms before starting over and the whole signal is only 10ms long

however on a brighter note the fact that it is high shows that it is detecting the pulse and the reason that the previous codes didnt work was because the they were polling the pin for low then waiting for it to go high again before reacting whereas i should probably just delal for 500usec after it has gone low instead in a minute i will assemble chives's code for you and and the led test code again but with a shorter dely befor it makes the pin low again

and @orko i to dread the flood to ebay but unlike the other codes on here i will be making the effort to publish it under a creative commons licence to deter ebayers

Post Merge: August 27, 2010, 08:03:01 PMalthough on second thoughts it could be because its detecting all the button pulses as r2 try hooking it up to the oscope again and see if the signal changes when you press random rcommon butons(r1 r2 /\ [] O etc)
Post Merge: August 28, 2010, 04:13:36 AMok heres the code hook them both up like so (but not at the same time)
pin7 rcommon (and then after r2 if you can)
pin6 oscope

also whilst you have them connected to rcommon check if pressing the other buttons affects the signal

and @gerald can you send me alink to the info for your arduino scope?
Post Merge: August 29, 2010, 08:27:59 AMok more codes to test YAY lol compr2ledtest and compr2ledtest both use comparators and are wired up the same as the others

[geraldrubalcava]

yea i was thinking my scope speed was too slow Edit it goes (200khz) so it might be fast enough i just need to modify the software on my pc but i will see if i can speed up the post posses. hum yes well the second chanel was steady so im sure that it wasn't a battery fluxuation.

second yes some buttons got presses randomly when attached by the oscope. so i guess there is somthing happening.

third its great that you are trying to publish it under creative commons license. most ebay dealers if they steal your code imagine ( 20 sellers trying to sell the same thing) they will hardly get any business because there is too much market. (brothers a business major lol) so u better put it under cc! lol

i will check the buttons right now and so for all of those codes do i use the same pins? great! here is the arduino scope http://code.google.com/p/arduinoscope/

[hyper999]

1.yes same pins
2. there should be no random button presses with these codes or the previous one
3. i meant while attacthed to the oscope press buttons (with your finger) on the controller and see if the signal on the oscope changes

[geraldrubalcava]

here is my test results for the coparator with led wait test. lol i will have the future codes testing up in a bit

FILE0132

[hyper999]

I think the blips are just noise but try all the other codes and can you  hook up your scope to rcommon and see what voltage all the buttons are when pressed / unpressed cos i need to know so i can setup the comparator properly

also just curious what voltage does r2 go to when pressed? and then when unpressed?

[geraldrubalcava]

sorry if i responded late. well the first two codes keeped giving me a steady digital high. well if you can write a code that complimates my scope? well i will give a second round to the codes and record them with and without button press.

[hyper999]

all of these codes were meant to compliment your scope :/ but can you post vids please

@chives i looked into the soundcard oscope as i have a spare soundcard but it will only work with ac signals and only up to 1.7v so i think i might buy a cheap arduino clone for the same setup as gerald

[802Chives]

gerald, you are able to see the signal that hazer posted earlier in the the thread of Rcommon correct?  As well as the signal that is produced from R2? 

[geraldrubalcava]

well i am currently uploading the vids. lol my camera takes 120 frames per second at 720p so its ganna take a while lol sorry. but yes the arduino itself is able to pickup the signal coming from Rcommon. its not perfect like Hazers chart but similar. i will check the signal from R2 too. but i will have all the vids hopefully up pretty soon sorry for the delay, (calculus classes are exhausting).

ok here is just the test of the Rcommon with my oscilloscope.
FILE0133

here is my test with R2 signal
FILE0134

[RDC]

What a PITA, lol, and I know diddle about coding, so it was even worse. I've been messing with this off and on for awhile now, try a few things outs, scope it and see it fail, miserably, then get fed up and let it sit a few days before repeating the entire process again, code, flash, scope, fail, repeat. What really grinds my gears is I could swear that what I did in code this time I'd already tried before, but it's all such a mess of trying this and that out now I can't remember half of what all didn't work.



This has the R1 button disabled for sure, at least here anyway, then R2 and /\, which are on either side of it, still work just fine, as do the rest of the buttons.

So this CAN be done, lol.

I personally could care less about R/F, it's not my thing at all, and most of the time some new one comes out I find the install diagrams have my pics in them anyway, used without asking permission. I was just after the challenge of trying to do this, even though I can't code for spit, but I just couldn't leave it alone and am finally glad I've gotten to this point, which is all the farther I'm going with it as again, R/F isn't my thing at all.

If anyone would like to test/confirm this (please do) the R1_OFF.hex is attached. Pin 3 connects to COM2/TP18 (it's TP26 on the MSU_V2, MSU_V2.5 (Six-Axis) MSU_VX (DS3) versions only) then Vdd and Vss, that's it, R1 shouldn't work at all and the rest of the buttons should.

[802Chives]

@gerald, that signal is bunk... your going to have a hard time being able to tell what is going on if you cant even see the original signal.

@hyper,  I wouldnt go out and buy an arduino scope quite just yet...

[geraldrubalcava]

I agree with chives, hold on of buying a arduino. it might be cheaper but not what you realy looking for. and the signal aprears to be bunk, i know :/

for RDC i will try your R1 disable code. il get back to you in a few hours.

[hyper999]

yh lol i changed my mind as soon as i saw that vid

@RDC can you post the source for that code?

and what do you guys think of this oscope? its a clone of seeedstudios opensource one and looks good enough for anything id need http://cgi.ebay.co.uk/ARM-DSO-Nano-Pocket-Sized-Digital-Oscilloscope-2-8-/300458819103?pt=Radio_Control_Parts_Accessories#shId

[802Chives]

So this CAN be done, lol.

ur a funny guy :P  One of our members Exofire was the first (to my knowledge) to have an Rcommon only RF on the market... and another great looking guy around here also has succeeded as well .

[802Chives]

and what do you guys think of this oscope? its a clone of seeedstudios opensource one and looks good enough for anything id need http://cgi.ebay.co.uk/ARM-DSO-Nano-Pocket-Sized-Digital-Oscilloscope-2-8-/300458819103?pt=Radio_Control_Parts_Accessories#shId

seen those on deal extreme:

http://www.dealextreme.com/details.dx/sku.39753

check the comments... seems to get decent reviews.  Hard to beat $80 for 1mhz...., but for $180 you can get into a 40mhz USB scope:

http://www.dealextreme.com/details.dx/sku.37062

I like the idea of the portable one and price is right. 

[hyper999]

i think i will get this one and i will be getting it from ebay cos im  in the uk

[orko007]

I got another one for you... you dont need to use an ADC to see the state of the buttons, it can be done digitally.  All you need ADC for is identifying the beginning of the wave train from there you can tell if buttons are pressed or not digitally.

I did not try that only because the buttons are analog and each press is going to give you a different voltage and it is possible to press a button light enough to get it to activate in the game but not give a digital low reading. but for the most part a normal pressure press of the button (past the tactile feeling "bump") will give a digital low reading.  Also R2 already sits digital low when at rest so you pretty much have to use the ADC to check for any activity.
if anything the way I set it up if I ever wanted to make something different happen based on how hard the button is pushed I could do it.

also just curious what voltage does r2 go to when pressed? and then when unpressed?

I didn't see anyone answer this but for R2 when not pressed it sits at 1.3v and pressed depends on how hard you press it. a full pull of R2 will goto 0V but in a game it will start to fire at around 1.1V - 1.0V.

All of the other buttons are 1.6v at rest and an average press gives you around 1.3v but again they are all analog so a harder press will give a lower voltage.


Also if RDC were to post his source you could just take what he has done and put it into a loop so it pulls R1 high for a few cycles, like his code does all the time now, then just do nothing for a few cycles. That was the basics of how my first success happened.

p.s. I have spent the last two days working up code to do burst fire (only for R1 or R2) but is was very much a pain compared to just normal rapid fire or even burst fire on the 360.  I would probably be easier using a comparator but I have yet to mess with that yet, most likely later this week.

[RDC]

ur a funny guy :P  One of our members Exofire was the first (to my knowledge) to have an Rcommon only RF on the market... and another great looking guy around here also has succeeded as well .

I've seen the chip you worked on, and am also familiar with the Exofire one since they use some pretty familiar looking pics in 'their' install diagrams.

What I meant by "So this can be done" was just that it has been eluding me personally for awhile now and that I finally got it. I don't write code, can't code for squat and probably never will to any decent degree, and I was starting to think I'd have to be at it for some time until I learned a whole lot more so I'd able too get it or wait until someone else showed exactly what needed to be done, at which point it wouldn't have been any fun to try and figure out after that, which is all I was after on this, so it was more of an 'ah-ha' kinda statement. That's also why I mainly do Hardware hacks and did that side of the CGnome Project and left the coding to someone that knew what they were doing.

I honestly have no desire at all to proceed any further with this, as after this point it's just pressing a button over and over, and R/F really just doesn't appeal to me at all. It might if I was paid for it, or at least compensated for the use of the controller pics as that's done nothing but make others profit from my work, which if thought about would get anyone a bit testy, and there's way too many people investing time, effort and money into R/F controllers that I'd really like to see them do, or at least try, something new that might actually be useful to some gamers that are after more than a controller that pushes the button for them over and over again. But I seem to be in the minority there, which is fine, I'm just not the type of gamer that has to get every achievement point or trophy in a game that there is to get or think that a controller that shoots 1/sps faster than the other guys will make all the difference in the world. That's no knock on you or anyone else that's spent time figuring out how to do it and get it as good as it can be (except the lazy thieving types) but it's still just pressing a button over and over again, and even the more 'complex' controllers that pull off a game glitch are just an extension of that in my book, and again no offense to anyone that does it, I'm just not into it and all I was after here was seeing how the first part of it was done as that was starting to drive me nutz since I knew it already had been.


@ hyper999 - I'd look for a good used Analog O-scope. I have an (old) Fluke 97 50MHz ScopeMeter, that's the screen shot from earlier in the thread that Hazer posted, then an Analog 60MHz one (that's the pic I posted a bit ago) and both are Dual channel also, which is pretty nice for some things, but an Analog scope will let you see a lot clearer what a Digital one just kinda does. A newer Digital scope would be a lot better than the Fluke 97 I have, and for what they cost they better, but you should be able to get you a decent used Dual channel Analog one for a reasonable price. They each have their advantages/disadvantages, just so long as it works for you is all that matters though.

As far as the source goes, I'm just reading the AN3 pin. If it's a shade under the vRef (Vdd) then start your wait time to skip R2 and so forth as described by others, but if it's not then loop until it is, that should get you to the point where I'm at and it's only 3 lines of code in Basic, no idea how to do it in Assembly or C, barely know how to do it in Basic. The overhead code meant I had to set the 500us wait time, to skip over R2, to around 380us, and it still 'wiggles' back and forth a tiny bit, not staying spot on the R1 button, but it doesn't cause any issues so far from what I can tell as R1 is completely masked and the other buttons all work as normal.

You can't treat a button press as a voltage change when using only the COM2 line, the controller doesn't really work that way, what you have to do is start off right at the beginning, or as close as you can get, of the falling edge of R2. So you're looking for the voltage to be under vRef (Vdd, 2.8v) but not just at any spot, right at the very beginning of it, the falling edge. After that you can 'read' the voltage of it and see where it's at if you wanted.

[802Chives]

Orko: 0.8V is the digital high threshold for a schmitt trigger, so R2 is not a digital low to start.  all the buttons on Rcommon and Lcommon can be read digitally... I know because I have tested it.

You are correct however that the buttons need to be pressed normally in order to register, but no more firmly then in normal use (a light press will not be seen digitally).  you could take advantage of the pressure sensitivity using ADC as sony does, but I cannont see an application where you would want to at this point, not for turning RF on and off and cycling modes.

I think these guys may be getting off track by the arduino oscope not giving them the resolution they need, once they can see the signals they will be moving in no time.


RDC: I can understand your fustration with people using your pics in their product sales, if it makes u feel better i always know where they come from   I share your sentiment for Rapid Fire, I do not use it, and when I have it makes me worse so I think it is very gimiky (with acception to rapid fire on X for 1942 for PS3)  Making macros for buttons is really simple with micro's as well, but like you I also would like to see more.  The Usb Flash version of a mod chip is a great idea,  Viking and Consolecustoms are not the only ones tossing that idea around either, but it will be the PC GUI for making a custom controller and a slick interface that will prevail in the end.

Gerald and Hyper:  I dont want to muddy the waters anymore, but there is another pic interupt feature that can be used for triggering the beggining of this wavetrain, and that is External Interupt feature for the INT pin (I believe it is GP2).  that interupt can be triggered for either falling edge or rising edge of a signal.  I would have to look at the spec some more to see what the threshold for the falling signal is for this interupt, but it would undoubtedly work for R2 and maybe Rcommon

Edit:  RDC,  everytime I see you write that you would not be a good coder, I cringe,,, you would be a great coder and you already know the electricity so you are already way ahead of the game. That picture you just posted, you wrote a suedo code loop there that is easily converted to assembly which I am assuming you did.  The rest of the code would be no harder then breaking it down into similar seudo code and tackling it piece by piece... IDK, but if I were you I would go through the 12 tutorials that come with a PicKit2 and Low Pincount demo board from microchip and then re-evaluate whether or not you should code.