Monitor running Switch matirx with 28x2

Hi All

I want to monitor a 8x8 switch matrix existing in a keyboard that is being scanned at 250Hz. I was thinking to tap into the inputs from the rows and columns and feed them to a port each. So i would look at the rows wait for a low on one of the eight lines and when detected look at the columns to see which was low to determine what switch was being pushed.

Would this be possible on a 28x2, would there be enough time to monitor for a low on the row inputs and when detected look to the column inputs to see which column it was?

If this would be possible can i get a few pointers as to where to start?

Or can someone advise a better solution?

Thanks
Daniel

Should be possible, I would do it exactly as described ...

cool thanks hippy

So you dont see an issue of speed cropping up when comparing the rows and columns ? In the back of my mind i was thinking i would not have enough time to detect a bit change in the rows and catch the correct column as it was low but i guess the only way is to mock it up and see once i try and get my head around writing the code to do it lol

Thanks alot for the quick response, im fairly new to the software side of things so i find it very hard to put all my ideas together but we will see..

Run at the fastest speed there should only be a hundred or so microseconds between detecting the switch going low and the strobe being read. If it is marginal it could be worth trying ...

Possibly read pinsB, pinsC and pinsB again, so you cover catching the strobes before or after and figure out which it is from the two pinsB readings.

I reckon the odds are in your favour.

ive run into an issue while just starting to get this done.

I was going to use port B and port C to monitor the matrix however im using C.3 and C.4 the I2C pins to read an RTC. Can someone suggest a way around this? i need to use two complete ports but also need to use the I2C pins for the RTC.

Is there a way to mix port pins? so perhaps i could use PortB and most of PortC but swap out C.3 and C.4 for two PortA pins?

Or as im using the clock program in its own slot and would not be using the I2C function while im monitoring the matrix could i get around this issue using hardware and share C.3 and C.4 for both functions?

The best solution would probably be to software bit-bang I2C on the A.x pins.

Thanks again hippy

Seems i might be taking on something that is beyond me, but i can only try.

Is there a guide for dummies on how to bit-bang the ds1307 RTC ? Possibly some examples somewhere ?

I don't know if there are full examples for bit-banged I2C and DS1307 but there's some code for doing bit-banged I2C here which was extended to be used with a DS1307 ...

http://www.picaxeforum.co.uk/showthread.php?16503

That's for the 08M but it should be possible to convert that for any PICAXE using any pins for the I2C bus and extend to read or write to the DS1307.

Great thanks hippy there wasn't alot i could find on this but that sample will work well. There must not be a lot of need to bit bang an RTC as your code is all i could find when i looked myself..

As it is i have again stumbled as i need yet more i/o than the 28x2 can supply with using up the two ports for the matrix. So i have decided to move the matrix monitor section to a dedicated 20m2 and use that to solely detect the switch inputs and send serially to the 28x2 using background receive.

Do you think the 20m2 would be as capable as the 28x2 at monitoring the matrix considering that will be its sole job? it will monitor, determin the input and send serially the key number that it detects out for the 28x2 to recieve in the background?

Thanks for all your advise, very much appreciated
Daniel

It's hard to say if a 20M2 is up to task. It's not been determined of the 28X2 is and that would still need to be prototyped.

The 28X2 reads all of a set of silicon port bits in one hit and can run at 64MHz with an external 16MHz crystal so it has the greatest possibility of success.

The 20M2 doesn't read its port bits in one hit; the firmware reads a variety of silicon port bits then collates those into pinsB and pinsC values which is slightly slower, and it only runs up to 32MHz. That could be enough to stop it succeeding where a 28X2 would.

Didnt know that the M2 didnt read all of the port in one go, that might be an issue with reading the columns.

Im almost done with the 28x2 and if it runs well and all is good on that i'll change it to the 20x2 and use that as a dedicated monitor to send out the detected key number.

Thanks hippy

DanielH said:

Didnt know that the M2 didnt read all of the port in one go, that might be an issue with reading the columns.

Click to expand...

Looking at the Microchip datasheet for the 20X2 it appears that the ports are remapped in firmware with this chip as well - Like the 20M2 it will not read all of the port pins at once. I suspect that you would be better using the 20X2 for your main program and using your 28X2 as the dedicated monitor for the keyboard.

Circuit is correct; 14 and 20-pin PICAXE chips map multiple PICmicro ports/pins to PICAXE ports/pins to make it more convenient for the PICAXE user and users of earlier fixed I/O PICAXE variants. Basically so C pins are on the left, B pins are on the right, where left was traditionally input pins and right the outputs.

This pin mapping should in most cases be invisible and inconsequential to the PICAXE programmer. The time taken to do the mapping is minimal and part of the firmware but it can have an effect on highest-speed operations such as capturing strobed data because not all pins are sampled in one go.

Starting with the 28X2 then trying the 20X2, even 20M2 perhaps, is a good way to proceed. Having a separate keyboard handler sending data with HSEROUT is also a good design decision as that allows the handler to better catch all keyboard strobing and avoids synchronisation issues if background serial receive is used to take those key presses in.

Thanks guys'

I should really have looked at the data sheet to see the pinouts but i just assumed that the x2 parts would all be the same my silly mistake..
For now ill get it working on a 28x2 as best i can, then see if i can use a lower specd chip.

I do have one question about HSEROUT though. Ive read the description and I really dont think i understand how it works ( its benefit ) compared to serout. I understand Hserin over serin but not the other way.

DanielH said:

Thanks guys'

I do have one question about HSEROUT though. Ive read the description and I really dont think i understand how it works ( its benefit ) compared to serout. I understand Hserin over serin but not the other way.

Click to expand...

My understanding of it is that SEROUT is implemented via firmware; that way it can be used on most pins. HSEROUT uses the hardware serial port of the underlying chip; the main advantage of this is that the speed is more consistent than the firmware bit-banged approach. There have been several discussions about the accuracy of the baud rate of SEROUT; HSEROUT is more reliable where timing-critical communications are involved. Because HSEROUT uses the hardware serial port it is only available on the designated pin.

The other benefit of hserout is that you can set it to practically any speed. I have used an 08M2 to drive a DMX512 lighting controller at 250kbits/s!

The other advantage is that HSEROUT initiates sending a byte then immediately continues, so the PICAXE can be executing the next command while that byte is still being transmitted.

Cool, thanks for the descriptions guys..

It looks like the only chip that will let me use 2 full ports and the Hserout pin at the same time will be the 40x2. Ill have another look through the data sheets as im hoping im wrong.. Once i get it running on the 28x2 Maybe i can get away with just serout, first i should get it up and running though. HSEROUT might not be needed.

Thanks again

hippy said:

The other advantage is that HSEROUT initiates sending a byte then immediately continues, so the PICAXE can be executing the next command while that byte is still being transmitted.

Click to expand...

This true, but there is a gotcha to be aware of.

If you HSEROUT a single character, like 'A', then the the code continues straight away.

But if you output multiple characters in one HSEROUT, like 'ABCD', then the code has to wait until the last character is sent to the UART.

The time this takes is dictated by the baud rate, so you can be 'locked' for quite a while if the baud rate is slow.