AVR Freaks

It started here. And yes, that did work but it got even tighter as the timing is based on a "games". The project is to emulate a video game controller and in this case each game apparently can be more aggressive. I had to give up on simulating the hardware ( 74HCT04 ) as the expected response time is now around 100 ns. The AVR just can not deal with it alone (hence my comment about a co -processor ). I'm very open to suggestions here but I'm afraid 16MHz will not cut it. Happy to go in to more detail on that other topic or this one, should anyone want to dive deeper in to the rabbit hole. 


There is a poorly but useful write up here on the controller I'm trying to emulate.

https://www.raspberryfield.life/...

but see the image here

The select line is from the console and the other are responses to it. In the shortest scene, when the select line falls, I need to rise or lower the other 6 lines accordingly. At the moment they are on PORTD and PORTC, and I may be able to rewire it so they are all on PORTD to save code time, but as I mentioned I must react with in 100-200ns. I tried to react and time it so the 6 pins were set just before the fall but that didnt please all games. I think I'm just going to have to play by the rules and find a faster solution. 

Yes, mainly for lufa support. I was not aware of the 8/16 but not surprised.

CmdrZin, Same of the info is not explained well, and also not in the thread but from what you said I think known more would show why I'm not convinced things will work.

I pretty much do all my prep work before the falls. I then react with a while high then set the ports. I have experimented with ASM and a pin change interrupt with no acceptable results.

one example

WHILE_PULSE_IS_HI_NO_CHECK ( a while loop check a pin state)
PORTD = _low_state_portd_first;       

The issue I'm having is that the fall minus the check is less then 200ns.

123456789012345678

|||||||||||||||||||||||||||||   1--ns segments

~~~~~~~~|_______

Take for example the fall at the second '1' call this the 10th clock if you will. Clock number 12 is where the console makes the check for the other 6 pins.  I do not have 100ns to do the search for fall and set port I need 3 or 4 MCU cycles for that and that adds up over 100ns.

Evidence to the contrary but damn nice find.  I'm well before 2us on my scope. One trick I tried was to set the states before the fall so they were ready but somehow games defeated this. Or at least it didn't work. I almost felt like it was check before and after the poll. I used this trick on PC PACMAN because it was checking to soon after the fall and this trick did work. But on a slow game like Mortal Kombat 3, it would mess things up. Since game 1 was a 3 button and game 2 was a 6 button I change my code based on that. That worked, but I then found another game that failed in yet another way. So as I said above, I'm throwing in the towel on this and going with hardware.

You'd have to do the same on the rise as well.  Have the data ready to go before either type of edge.  However,  not toooo early before the edge

 This is precisely what I tried and came a bit obvious to try it with great hope it would work, alas,  did not.  Many are coming to the same conclusion here. I ordered a few multiplexors to play with and just messing around with the code for fun. Every-time I make one game work, another fails. A hardware add-on in this case will work with my design and I wager it's best.

Going to dive back in the code here for a few reasons.

1) To get a 6 button controller working I'm going to need a few multiplexers and the BOM is getting a bit over budget and taking up too much space. It's not a show stopper but I'd rather this be my backup.

2) I reread avrcandies post and didnt see the links the first time. I know raphnet pretty well and if he pulled it off, it probably worked. He does not have the game collection I do, so ill put it to the test.

3) Reading over his design and what avrcandies said, it may just work. It is going to come down to what N.Winterbottom  said that some games just do not play by the book and I'm pretty sure I have an idea what goes those would be.

4) There are a number of advantages if I make this work.

Though, if no, I have a back up plan. So I'm doing this mainly for the experience and learning exercise.  That said, I wired up the pin change for a test and the c style code the call to the ISR has a 1us delay from reaction to debug. That's slower then my design, so I'm guessing I need to understand a bit more of what is going on here. So I have a few questions.

1) IS a PCINT any slower the INT ?

PCICR |= (1 << PCIE0);

PCMSK0 |= (1 << PCINT7);

vs

EICRA = (1<<ISC00);
EIMSK = (1<<INT0);

?

2) What does this do?

/* Move the vector to the bootloader section where we have direct code for INT0. */
    MCUCR = (1<<IVCE); <---confused by these because mcucr normal talks about bits 0 and 1 being the pin condition to watch for (isc00 and isc01)?
    MCUCR = (1<<IVSEL); <---

Are we making the vector more easily accessible? Will that interfere with my bootloader that is running? How do I do the equivalent for my PCINT ?

3) Currently I'm using c style code. I of course realize ASM will give me more control but is the Pinchange going to jump in to the code any faster just because it's done in ASM ? Perhaps the fact the compiler does not inline the function.

I tried to use the code below to make this work

PCMSK0 |= (1 << PCINT7); // Enable PCINT7
PCICR |= (1 << PCIE0);

MCUCR |= (1<<IVCE);
MCUCR |= (1<<IVSEL);

sei();//enalbe interupts.
_delay_ms(17);
PCMSK0 &= ~(1 << PCINT7);

but all that does is reset my atmega32u4 after 200us.