Macro Controller

[SethMods]

Guys, in the next few months I am going to try to build a macro controller mod.

My goals are to be able to have 4 individual modes (up to 10 seconds each) recorded to EEPROM.
The digital buttons that I want the mod to monitor and control are A,B,X,Y,RB,LB,RJ,LJ.
And then I want to monitor and control the 6 analog inputs from the two triggers and two joysticks.

I plan on using the PIC18F14k50 just because I am already familiar and comfortable with it.

I'm wondering if anyone has any advise/thoughts on the matter. And if anyone can warn me of any possible pitfalls.

[Modded Matt]

Your name is not E is it?

LOL I have one.

[KingMike_OS]

i have 4 can't be any better then what viking got out ..  i don;t  think there is market for it ... cost too much takes too long to install .
No Common Waste of Time

[SethMods]

I know of a good way that it can be better than Viking's.

It can cost less than $399.95.

I'm pretty sure my XBox cost less than that.

[Modded Matt]

The Viking Macro controller has been discontinued due to lack of interest. They are selling off stock. It was a good product, but cost too much to make.

[SethMods]

The Viking Macro controller has been discontinued due to lack of interest. They are selling off stock. It was a good product, but cost too much to make.

That's bizarre to me. I already have mods that can be programmed via a computer. I plan on ripping that functionality out (for now) adding a 6 Port DAC and an EEPROM and calling it good.

I don't expect my cost for the mod to be more than $20.

But I guess when you are as skilled as those guys if you aren't making at least $30/hr then you are just wasting your time.

[Modded Matt]

regardless of who you are if your not making 25-30 per hour minimum u are wasting your time and should go back to school or find new work.

[Rodent]

regardless of who you are if your not making 25-30 per hour minimum u are wasting your time and should go back to school or find new work.

yea good luck with that finding a job , whether you got a degree or not  trying to make that kind of money  so many people out of jobs they can pic and chose who they want and if that person isnt who they want the fire them and get someone else... economy just sucks for jobs... and not everyone is going to have a job making that much money an hour, I dont care how skilled your are or how good you are, your replaceable!!!

edit: even working for yourself is hard to make that all the time and getting people to pay you for it is another thing ... you pay for what you get

[SethMods]

I guess that's the positive of being a hobbyist. At the end of the day I don't have to turn make a profit. I'm in it for the learning and experience.


But back on topic, I've decided to drop the PIC18F14k50 and move up 8 pins to the PIC18F24J50. (In the future I plan on adding back USB Programmability.)

Also, I've not been able to find DACs that I feel will work for this project. Instead I'm going to move to a LED Driver.

Here's the one I spec'd out.
http://search.digikey.com/us/en/products/PCA9634PW,118/568-4066-1-ND/1534155

It can drive 8 ports using PWM. I figure with an appropriately sized cap this will be equivalent to an 8 bit DAC.

[Hazer]

So here's my take:

Vikings mod costs so much for the following reasons: The design was done right the first time, which means it was thoroughly tested before finalizing the hardware, but in a short time period. This was professional work. And costly. It also used the higher end PIC24 USB device with separate analog out for controlling the sticks. If I remember correctly, there are two PCBs one of which is flexible. The development cost was high. The hardware cost is also high. The install is also pretty intensive even with a clip-on to reduce some of the soldering.

You were right to ditch the 18F14K50. While you have just enough outputs to control the triggers, the ABXY, shoulder, and stick-clic buttons, you do not have enough for multiple tacts or true remapping/rapidfiring of those buttons (you can only force a press, you cannot force a release).

Now on the PS34, this chip 'could' be a macro chip, but it would take real skill to fit the macro in such a small memory space.

Staying on-topic, the X360 controller would need a 40-pin chip with a good portion of memory to do a rightful macro mod. But let me get to one point: In my opinion, forget about the analog part completely. There is alot of work and code synchronization in reading and outputting analog signals along with all of the digital without bugs, and the hardware is external also. But what you get in return doesnt fit with the effort. Alot of my RL job is comparing what can be done with what it costs and what you get in return. At most, if you create the analog portion of a macro just like viking, you can possibly get some funky anti-recoil macros that few (if any) people would use or help create without the original author. But the effort to create that (and also what it would take to make the PCB with multi-chips and install it) would be wasted.

Now, if you kept the entire thing digital and made each of the buttons driven from the chip (cut traces so that all buttons could be rapidfired like the triggers) then you would open up the possibilities farther than any glitch controller ever has. And it would require alot less than messing with the analog stuff. This in my opinion would be a true macro (definition: a play-back of sequenced events). You dont need to include the analog functions to be called a macro.

You should also keep USB chips. ICSP is annoying quite frankly. Once you install the circuit, its so much better using the USB bootloader than it is to have to make updates through any other method. Also, once installed, a good code would always leave the adjustability to the user. Locking the options to a specific code sucks.

I have already started working on the 18LF4550 since it is a 40 pin chip that works at 3V and has the simple USB interface the 14K50 has. I will start releasing the baseline codes/asm/schematics as I find time.

In conclusion, I like your motivation and will be anxious to see your work

[SethMods]

Hazer, I appreciate your feedback. I think you know that you continue to maintain the respect of the whole community.

Here are the concerns that I picked out of your post (and my responses.)

Memory Size: For this project I am going to jump ship on Assembly and code in C. The programming seems to me to be very simple. I'll have a timer throw an interrupt every 5ms during record mode. At that point, I will log the 8 buttons states (8 bits total) and the 6 analog readings (8 bits each). So 7 bytes buys you a 5ms sample. All samples will be written to EEPROM via I2C.

For playback I'll use a 5ms timer again and then simply change the state of each pin accordingly.
So, I could be wrong, but this seems to be a heck of a lot simpler than some of my other coding projects. And I expect it will be smaller as well.

Analog Control: Since I plan on using an 8 Output LED Driver for my Analog control. I'll feed the bytes from the recording back to the LED Driver to control the Duty Cycle (and consequently the voltage). It should be a direct correlation where I can use the same byte that the ADC gave me to feed my PWM Duty Cycle. (Hopefully no conversion needed.)

Pin Count: To minimize pin count and also PCB design size, I plan on using I2C on the EEPROM as well. So those two wires for I2C will control the EEPROM and LED Driver. Also I plan on hooking up the tactile switches in a resistor ladder formation and reading the pin with ADC. This will allow me to use just one wire to listen to all 4 tactile switches, and it will throw in an interesting side-effect where the switches will have priorities. So the controller could be in the middle of operating the priority 3 switch and get canceled when the priority 1 or priority 2 switch is pressed.

Also, you mentioned "True Macro" talking about rapid firing a button. I want to make sure that I understand correctly. You are saying that it isn't possible to force a button up? As in, if a person is holding down the B button, then there is no way to rapid fire that B button while it is being held down.

The first solution that comes to mind is to cut the trace that takes each button to "Common Ground" and add a 0603 resistor. ...essentially making a weak pulldown. As long as the weak pulldown was stronger than the weak pullup on the other side of the button and yet still weak enough to allow the Microchip to pull the signal up for a rapid fire, I think that would work. It's probably an extra 30 minutes of installation work per controller, but I think it's do-able.

Thoughts?

[Hazer]

Also, you mentioned "True Macro" talking about rapid firing a button. I want to make sure that I understand correctly. You are saying that it isn't possible to force a button up? As in, if a person is holding down the B button, then there is no way to rapid fire that B button while it is being held down.

The first solution that comes to mind is to cut the trace that takes each button to "Common Ground" and add a 0603 resistor. ...essentially making a weak pulldown. As long as the weak pulldown was stronger than the weak pullup on the other side of the button and yet still weak enough to allow the Microchip to pull the signal up for a rapid fire, I think that would work. It's probably an extra 30 minutes of installation work per controller, but I think it's do-able.

Interesting solution. This would mean a pulldown resistor small enough to trigger the controllers 'low limit' but large enough not to overload the PICs high output to drive it high again. Its worth a shot. The only bad thing is quite a few of the buttons are grounded right at the button, theres no trace to cut. But you can still get in there.

Another way is to have dedicated button inputs and outputs through the PIC. This would allow remapping options in the future.

Good luck.

[SethMods]

Another way is to have dedicated button inputs and outputs through the PIC. This would allow remapping options in the future.

I like that idea. I think I might save it as a future upgrade.

I really appreciate your help, guys!

[magic_man185]

Memory Size: For this project I am going to jump ship on Assembly and code in C. The programming seems to me to be very simple. I'll have a timer throw an interrupt every 5ms during record mode. At that point, I will log the 8 buttons states (8 bits total) and the 6 analog readings (8 bits each). So 7 bytes buys you a 5ms sample. All samples will be written to EEPROM via I2C.

For playback I'll use a 5ms timer again and then simply change the state of each pin accordingly.

I must say, I am impressed with your thinking, that is a pretty straight forward way to do macros.  I had briefly thought about doing some kind of macro controller, but I was trying to figure out how you would record it, and I was trying to figure out how to measure pauses between button presses and everything.  Your method is much simpler.  Of course it will take a lot of EEPROM to work, from my calculations, to record a 10 second macro would be like 14K of EEPROM. (1,000ms in a second, 10,000 in 10 seconds.  10,000 ms / 5 ms intervals = 2,000 samples.  Each sample is 7 bytes, so 7 * 2,000 = 14,000 bytes).  If you wanted 4 macros, you would need 56K, so probably use a 64K EEPROM?  Man, with that many samples it seems like it would be hard to keep everything straight and organized, lol.  One thought though, would you really need to be that precise? If you are doing manually recorded macros, people can't press buttons nearly that fast.  I would think even every 100 ms would be fast enough to catch everything.  Of course, if you were using computer generated macros, you could get a lot more precise.

[SethMods]

MagicMan, you are dead on with your math.

Here's the 64K EEPROM I had already spec'd for the job.
http://search.digikey.com/us/en/products/24LC64-I%2FSN/24LC64-I%2FSN-ND/273428

I love the price point!!!


And to keep things simple I thought I would use static "pointers" to each of the 4 macro areas in memory. Otherwise, you are right. Things could get messy really quickly.


As far as the precision, my thought was to be able to record macros in slow motion. I'm thinking half time and quarter time. That way a user could record say a rapid fire macro at 5 SPS and when it is played back at normal speed it could really be either 10 SPS or 20 SPS depending on which timing they selected.

I think you still have a point though that 5ms might be overkill. 100ms would limit a rapid fire to only 5 SPS though since you need a "frame" to pull the trigger and a "frame" to release the trigger (200ms).

And if all goes well I hope to add PC support in the near future. I'm just not that great of a coder when it comes to GUI apps. ...which is why I stick to PHP/HTML for my other mods.

Thanks for the input!

[magic_man185]

Seth,

I didn't know if you were planning on actually manually recording rapidfire, as it would be very difficult for a person to get the timing precise.  I would say manually recorded macros are better for button presses and (if you want it) analog stick controls, while you could use a computer generated macro in order to get rapid fire.

I am with Hazer on the thought that the analog stick control wouldn't be necessary. Also, for the triggers you could treat them as digital pins like Hazer's code does, and not require a full byte to control them. If you did A, B, X, Y, RT, LT, RB, LB, RS, and LS, you could record all of the buttons with only two bytes.

There are a couple of things to keep in mind when looking to use the EEPROM you are looking at.  First, you will not be able to write to the EEPROM 1 byte at a time.  The EEPROM has a 5ms write time, and if you are writing every 5ms the chip might not be able to keep up.  You could do a page write to write multiple bytes at a time.  The only problem with this is that you can only write a single page at a time, so the pointers would be tricky to keep straight (which 32 byte page you are currently on).  Probably the most feasible way to hand that would be to have a counter built in to your code, count up to 32, then initiate a page write and reset the counter. Count up to 32 again and initiate the page write, etc.  Then do a similar counter for read operations, just incrementing your counter with each byte.

Just kinda spitballing some ideas here, I think this could end up being a pretty cool project. (Even though I probably would never build one for my personal use, lol.)

P.S. That EEPROM is cheaper at Newark, http://www.newark.com/microchip/24lc64-i-sn/ic-eeprom-64kbit-serial-400khz/dp/12C2020?in_merch=Popular%20Products, in smal quantities anyway.  If you buy more than 10, it is the same.  Seth, did you know that you can get free samples from Microchip for prototyping?

[hyper999]

Could you not PWM the anologs? as long as you only switch between high/low and tristate.

[SethMods]

Could you not PWM the anologs? as long as you only switch between high/low and tristate.

Can you explain?

[Bigandrewgold]

Now, if you kept the entire thing digital and made each of the buttons driven from the chip (cut traces so that all buttons could be rapidfired like the triggers) then you would open up the possibilities farther than any glitch controller ever has. And it would require alot less than messing with the analog stuff. This in my opinion would be a true macro (definition: a play-back of sequenced events). You dont need to include the analog functions to be called a macro.

I dont know if he would have to cut the traces.  I have accidentally disabled the function of an abxy button by forgetting to set the pin to input.  So I could press "A" on the controller but I would not jump on cod.  Could he not take advantage of this and simply for whenever in the macro a button would be unpressed he sets the pin to an output and output high.

and here is a quick code I mocked up in picbasic to demonstrate what I am talking about.  It is for a pic 16f628a with the b on pin 6, the x on pin 3, and the y on pin 2, and those are the 3 buttons which become unusable

picbasic
compiled asm

and this was tested on a cg2 controller, but I dont think cg would be any different

[SethMods]

Andrew, your code ties the X and Y to ground.

Could you tie it to Vdd instead and see if the button is still disabled?

In my testing with the 12f683 it couldn't source enough power to overcome the sink from the button being pushed. (That is to say "the button wins".)

[hyper999]

Can you explain?

I do not know what way round the pots on the actual analogs are but lets for this example say that the wiper pin is high when the analog is pushed up.

So to make the controller go up you set the PIC pin that is connected to the wiper high yes?

so to simulate 50% up could you not rapidly switch the pin between output high and tristate with a 50% dutycycle?

[SethMods]

Hyper,
  You could, but it would be very difficult to keep up with everything. You would essentially be keeping track of 6 individual software generated PWM modules. That's 12 different interrupts to keep everything straight.

I don't know. Maybe it would be worth it in the long run to keep from having to put an extra piece of hardware on the board.

[hyper999]

Hyper,
  You could, but it would be very difficult to keep up with everything. You would essentially be keeping track of 6 individual software generated PWM modules. That's 12 different interrupts to keep everything straight.

I don't know. Maybe it would be worth it in the long run to keep from having to put an extra piece of hardware on the board.

You could use one timer interrupt for all the PWM channels all you would need to do is let it run in the background and change one register for each channel or less depending on how much resolution you decide you want

[SethMods]

I tried to work that through in my mind.



Ok, so I am looking for 5ms resolution for my recording and playback. I'm thinking that I should have at least 10 PWM cycles (or periods) per frame. So the PWM would be running at 2 KHz. Each individual cycle lasts 500 uS.

The example above shows a resolution based on 5% increments of the Duty Cycle. My goal was for 8 bits of resolution, so 256 steps.

That means I need to be checking (and possibly adjusting) the PWMs every ~2 uS (500uS / 256 steps).

I wrote out a little code and estimated as many as 20 instructions to handle one PWM. So 120 instructions for all 6 (worst case). To fit that into 2uS I would need to be running at 240 Mhz.  ...which isn't possible.


I mean these are the settings that I would hope that I would be able to do to make the PWMs "work" for my application. Obviously I don't need 8 bits of resolution. But even playing with some of the numbers and cutting some things back I could only just get things slimmed down to where I was comfortable that I'd have enough processor to handle everything else.

Is there an easier, quicker solution?

[hyper999]

I would say two or three bits resolution in each direction would be plenty

and assuming the displacement of the stick is linearly proportional to the magnitude of the reaction to it by the game, you would only need one complete cycle per 5ms.

e.g 5ms of 50% displacement moves the character say 1metre in the game therefore 2.5ms of 100% followed by 2.5ms of 0% displacement should also move the character 1m right?

[SethMods]

Someone can correct me if I am wrong, but I think using PWM as a cheap DAC you need a capacitor on the output to smooth out the square wave so you truly get an average. And with only 1 cycle per 5ms I would be concerned that the output wouldn't have time to "settle".

That is to say that if you were attempting a 50% duty cycle and the controller sampled the pin at 49% of the way through the period then the output may look more like 80% of Vdd instead of 50%.

I'm not really sure. I've never implemented PWM via software. I've always used the onboard PWM module. And I've never used it for anything other than running LED's. (...where square waves are not really noticeable.)

[SethMods]

Actually, the more I think about it, the more I think that it CAN be done, Hyper.

I think I am going to use the LED Driver for my prototype. And then once I have a proof of concept on everything else try to implement a software PWM.

[hyper999]

Yes to get a true analogue output from PWM you need some sort of filter.

And yes I agree at the end of the day this is all theory, the only real way to determine how much accuracy is required and what the best method is, is through real world testing.

[1TONpete]

This all reads very familiar... keep at it.

[SixtyninNaMoose]

Hi guys,

I'm looking into doing something similar to this. This post is very informative, however I still confused a bit. So this viking uses a macro chip to control all these features and all of the coding is stored on a eeprom after programming? With a DAC you can control some analog features? Now if for instance I wanted to control how the controller reads the analogs current but i wanted the stick to reach full current in half a push in any direction. I could could use a DAC or would an ADC be better? Cuz basically its hard for me to physically push the stick all the way to its end point. So the DAC or ADC would feed the macro binary code and the macro chip would tell the controller that the still is in full push when in reality the sticks on at half push?

Please let me know if you can help me out with this, This would very useful.

[SethMods]

Hi guys,

I'm looking into doing something similar to this. This post is very informative, however I still confused a bit. So this viking uses a macro chip to control all these features and all of the coding is stored on a eeprom after programming? With a DAC you can control some analog features? Now if for instance I wanted to control how the controller reads the analogs current but i wanted the stick to reach full current in half a push in any direction. I could could use a DAC or would an ADC be better? Cuz basically its hard for me to physically push the stick all the way to its end point. So the DAC or ADC would feed the macro binary code and the macro chip would tell the controller that the still is in full push when in reality the sticks on at half push?

Please let me know if you can help me out with this, This would very useful.

So just to clarify ADC and DAC do the exact opposite things.

ADC converts an analog signal to digital while DAC converts a digital "signal" to analog.

They provide for a way for the PIC to interface with an analog signal like the joysticks.

If you wanted a mod that increased the sensitivity of the joysticks then you could do it relatively easy with the ADC and DAC features on a PIC.

You would just read in the voltage using ADC, take that value and "multiply" or "divide" it by some constant(depending on the direction the joystick was pushed) and then send it back out through the DAC for that pin.

The only catch is that you need to find a PIC that has 4 DACs or is capable of steering the DAC to four different pins...since there are 4 different axes for the two joysticks.

It's probably a simpler approach than what is described above.

[SixtyninNaMoose]

Do you think it'd possible for you to help me do this?

[SethMods]

I'm sorry, man, I really just don't have the extra time right now. I'm struggling to get that other (much simpler) project completed for you.

[SixtyninNaMoose]

That's cool, I understand with your work thing and all If you want you can just send me what you have done so far. I recently got a new caregiver who is pretty good, he's been helping with my mod off controller. So he can finish it up fairly easy, I'll still pay for the help either way.

[w02057]

Seth, the MAX5820 DAC (http://www.maximintegrated.com/datasheet/index.mvp/id/4669) would be suitable for your project I think. Two channel, 8 bit, i2c compatible upto 400kHz and low power. They are also pretty cheap. Three of these would allow you to control both axis on both thumbsticks, plus both triggers if you wished to add the ability for the triggers to be controlled precisely, which could be useful for racing games etc.

Hope this helps.

[w02057]

I don't know if this thread is still being looked at, but you may find this interesting: http://en.wikipedia.org/wiki/Run-length_encoding

It's a compression method that could be used to store the button samples in a much smaller EEPROM space. It would also make it possible to work with a single recorded macro in RAM before transferring it into EEPROM i.e. have a large 1kB RAM array, record each button / thumbstick state change and the delays between them into that array, then once you have finished recording write the contents of the whole array to EEPROM in a small number of page writes.

EEPROM requires 5mS per byte / page write if I remember correctly, so it would make much better sense to record the macro into RAM first as your code will most likely not be able to keep up.