Fast Scan Matrix 2

[robinfawell]

The Fatar 88 key piano uses 176 switches. Two switches are used for each key. They are labelled MK (0-10) and BR(0-10), total 22 switches. They are used in matrix fashion with two sets of "strobes" labelled T0 - T7.

My solution to dealing with the matrix is to connect the MK and BK signals to J3DOUT and J4DOUT (Only 4 outputs are used with J4DOUT) The LH keyboard signals T0-T7 are used as inputs to J3DIN and the RH ones to J4DIN. All 16 inputs are used. This means that we have a 16 bit word, one byte for the LH section and one byte for the RH section.

S32 MIOS32_SPI_TransferBlock

The function shows that 8 bit words can be transferred to or from the SR combination of DIN /DOUT. I have a few queries about this operation.

1) I assume that it transfers the LH byte followed by the RH byte ie the 1st 16 bit word. This followed by the 2nd 16 bit word and so on.

Is this correct?

2) Each alternate 16 bit word MK need to be compared (using exclusive-or) with the subsequent MK scan and the same with the the BR scans. This means that two buffers will needed for MK (current and last) and two buffers for the BR scans.

Is this feasible?

3) How would I test that the transfers are taking place? Has MIOS Studio any facilities for this type of testing?

4) I've looked fairly hard but I cannot find any examples of the use of SPI Transfer Block. Let me know where to find an example. The WebSVN shows an example entitled SRIO but although it refers to the SRIO operation is shows only encoder operations.

5) I'm not sure whether the function SPI Transfer Block automatically provides the shifting of the Dout strobe.

What data should be entered in the "u8*send_buffer" parameter when used with DIN/DOUT?

I will be very grateful for time spent in answering my queries.

Thanks, Robin

[Duggle]

This is how I'd do it:

// This hook is called (automagically by mios32) after the shift register chain has been scanned//

void APP_SRIO_ServiceFinish(void){}

I believe this answers your question (3). Inside this hook I'd call

MIOS32_DIN_SRGet(sr)

for each 8bits of input row (in shift register sr) and xor them to detect changes as you suggest in (2).

Oh and of course the matrix column is activated prior to the get operation in

void APP_SRIO_ServicePrepare(void){} with a calls to

MIOS32_DOUT_SRSet(sr,value)

as required in order to select the required row

I think the shift out operation happens at the same time as as the shift in so youd want to be sure that the new column selected was stable during the read.

One way of doing this is to read and process the input on the the second SRIO scan with the column select outputs stable from the previous scan.

hope I didn't overcomplicate the underlying concepts

cheers.

Edited August 28, 2010 by Duggle

[robinfawell]

Thanks Duggle

I agree that the Din and Dout functions are easier to understand. They will be easier to test than the SPI_Transfer_Block.

However I think that for the final version I should use the above function as part of SRIO_ScanStart function.

I am puzzled by the Transfer Block function. It looks a if it is transferring 8 bit data. I have a 16 bit X 16 bit SR.

Does this mean that this will be transmitted as 32 bytes?

Is each 16 bit Din divided into 8 bits?

My switch scheme uses the full 16 bits for the DIN inputs and only 12 separate DOUT's. Is it possible to define the Len parameter to reflect this?

If anyone can answer the above questions your help will be appreciated.

Robin

Edited August 29, 2010 by robinfawell

[Duggle]

Is each 16 bit Din divided into 8 bits?<br><br>My switch scheme uses the full 16 bits for the DIN inputs and only 12 separate DOUT's.

Is it possible to define the Len parameter to reflect this?

Think of the data sent to DOUT and the data read from DIN as an array of memory, ready for your app to use.

It is organised and addressed (by the MIOS functions) as 8bit bytes because this maps directly to the 8bit wide SR devices in the DIN and DOUT chains.

So for the above scenario I would wire 2 DIN SRs to the 16 inputs and 2 DOUT SRs to the 12 select lines. There will be 4 pins of the second DOUT chip unconnected (open cicuit).

You code will not be activating these bits (for the purpose of reading a switch row) because they are not connected.

Now, although it will be possible to address the memory array as 16bits wide there will be a minuscule performance benefit in doing so. I say this because it would allow you to access the switch 16bit input word in one function call instead of two. All the other processing associated with the note event detection will be the same. Therefore I suggest the performance benefit will be maybe a few microseconds (literally) in an app where the input events evolve over many milliseconds.

I would suggest implementing the scanner using the provided MIOS SR functions (for the most rapid development). Then, if you wish, explore alternative, customised functions and measure the improvements.

cheers

[robinfawell]

Thanks again Duggle

I have not been clear in my last message. I have attached the interconnection diagram between the keyboard and the 2 DIN's and the 2 DOUT's.

There are 2 Fatar connectors (20 pin), 2 DOUT Connectors and 2 DIN connectors.

MK0 and BR0 correspond to the lowest 8 notes, MK10 and BR10 to the highest 8 notes.

I have chosen the pin allocations to preserve the natural order of the keys as much as possible.

I have assumed that the 1st scan is J3 D0. This will give the 1st set of switches (MK0) data from the lowest 8 notes on J3DIN (D0-D7) and the 5th set of switches (MK5)data to (D0-D7) J4 DIN.

The 2nd scan J3 D1 involves the 2nd switch data (BR0) from the 1st group of notes to J3 DIN and the 5th switch data (BR5) to J4 DIN.

I am trying to figure out the order of the data storage. It makes sense that the sequence is MK0, MK5, BR0, BR5, MK1, MK6, BR1, BR6 etc etc. However this is an assumption. I will need to know this to generate the correct notes.

The second question relates to the unused signals D4-D7 of J4 DOUT. I am guessing that defining the len parameter in term of SR stages (in my case 16) translates as 32 bytes. Maybe I could shorten the SR value to 12 to shorten the overall scan. This still leaves the unused 2 bytes J4 DOUT D2 and D3 for other purposes.

I hope this a little clearer.

Robin

Fatar Midibox Matrix Board MIOS32.doc

[Duggle]

Before going too much further, in your Doc near the top you have J3DIN then the IC PIN assignments for a DOUT chip. The function of the signals makes sense to be DOUT.

Another thing to clarify. I would have thought that the keyboard has a simple change over contact switches: (albeit wired as a matrix)

That the terminal labelled BRn is the normally closed contact, MKn is the normally open contact, and the Tn is the switch common.

When the BRn opens, a timer decrements, until MKn closes at which time you have the velocity for the note event.

Is it correct that the Tn is connected to the switch common of every 12'th Key (makes sense because it covers octaves) btw you only have BR/MK 0 to 10 on your table.

A few points that are self evident:

The DIN modules have a pullup resistor so you will energise the Tn terminals with a 0V output on only one Tn terminal allowing to scan the MKn BRn for an octave in one SRIO cycle.

A 0V on a DIN pin represent closure of that particular MKn BRn switch contact.

If you are not sure about the switch make/break action as well as the matrix configuration, all can be deduced with a multimeter continuity buzzer.

Now, from what I've stated, are my assumptions and understanding right (or on the right track)?

[robinfawell]

Fatar Midibox Matrix Board MIOS32D.doc

Dear Duggle,

Thank you very much. The table has several errors. I had mixed up the Pin Nos both for DIN and DOUT.

You were also right about BR operating before MK. I have checked this. The new table reflects this.

The switches are as shown in the attached circuit of the Fatar 88 keyboard. The 1st Switch BR closes first. The 2nd switch MK closes with further depression of the key. Both switches are normally OC. Both switches are SC when the key is pressed. The terms BR and MK (Break and Make, I suppose) are misleading. I prefer 1st switch / 2nd switch.

The MK and BR signal (from DOUT's) clamp the DIN inputs(T0-T15) to 0.6V,using the DIN input resistor and keyboard diode only when the DOUTs are low (0V).

Yes there is only one connection to BR10 and MK10. Pins 19 and 20 are not connected to the Fatar LH 20 pin connector. The matrix covers groups of 8 contacts see the circuit.

I hope that it is now clearer to you and me!

Robin

PS Luckily the J3 and J4 connections are wired up correctly. I have to change all the BR and MK wiring.the

Edited August 31, 2010 by robinfawell

[Duggle]

Ok, the picture helps greatly.

Its now clear that the Tn left side and Tn right side 16bits can be sampled each and every SRIO cycle by 2xDIN SR chips.

You can energise (pull low) one MKn or BRn line from both left side AND right side every SRIO cycle 22bits total provided by 4xDOUT SR chips.

A thing to be clear about is that the DIN and DOUT use a common RCLK signal. This means that the moment the DIN inputs are sampled the DOUT lines from the previous SRIO cycle will be energising MK/BR.

There are some optimisations that can happen in the sw. For example when a BR closure happens there will necessarily be followed by a MK closure soon after. Also there is a higher probability of an event in adjacent keys. Perhaps you can determine the scan order dynamically from such criteria. I would also add that this is not something to be too concerned with at this stage.

One thing that concerns me slightly is that SRIO has millisecond resolution. You may/want need a little more? In this scenario a soft (slow) keypress of velocity 1 would take 126ms. This seems a little slow, if you have a resolution of 2 units (ie decrement counter by 2 each cycle) then it become 64ms, I doubt anyone would ever notice this velocity "granularity". (I had an early DX7 that never output velocity below 16. It was still a very dynamic midi keyboard controller) Another solution is to reduce the SRIO cycle period in MIOS32 to say 500 or 250us. There is plenty of CPU time available, especially if your application doesn't have to do much. This invloves changes to MIOS32 source codes (maybe ask TK). At some stage I'd probably look into it myself out of curiosity.

Again these optimisations and refinements should not distract you from getting the guts of your project working before optimising!

cheers.

[robinfawell]

ts now clear that the Tn left side and Tn right side 16bits can be sampled each and every SRIO cycle by 2xDIN SR chips.

You can energise (pull low) one MKn or BRn line from both left side AND right side every SRIO cycle 22bits total provided by 4xDOUT SR chips.

I believe that you only need 12 bits of DOUT ie 2 X DOUT chips. 11 bits might look possible. If you examine the table you will see that BR10 and MK10 are on the RH Fatar connector. You cannot drive both BR10 and MK10 with J4 DOUT D2 signal otherwise you will not be scanning.

The Table shows that J3 DOUT will drive BR0 and BR5 together using signal D0, MK0 and MK5 with D1 and so on. J4 DOUT will drive the rest using D0-D3.

If you accept this explanation you may understand why I am concerned with the order of scanning the contacts. However this can be discovered experimentally.

One thing that concerns me slightly is that SRIO has millisecond resolution. You may/want need a little more? In this scenario a soft (slow) keypress of velocity 1 would take 126ms. This seems a little slow, if you have a resolution of 2 units (ie decrement counter by 2 each cycle) then it become 64ms, I doubt anyone would ever notice this velocity "granularity". (I had an early DX7 that never output velocity below 16. It was still a very dynamic midi keyboard controller) Another solution is to reduce the SRIO cycle period in MIOS32 to say 500 or 250us.

Thorsten has made some comments about this in reply to an earlier question in a previous recent thread. He has suggested the following

Note that it is possible to call MIOS32_SRIO_ScanStart() from the application to scan the SRIO more frequently. This will require to remove the

MIOS32_SRIO_ScanStart(SRIO_ServiceFinish); call in vApplicationTickHook - I could add a #ifndef based switch if you want, so that this code doesn't need to be modified.

Instead you would enable this switch in your mios32_config.h file, and call MIOS32_SRIO_ScanStart from a timer function (-> MIOS32_TIMER) embedded into your app.c file at the desired frequency.

As you have indicated it is best to proceed more slowly and use ScanStart in its present form with 1ms period and get the project moving.

Initially I plan to scan all the contacts without worrying about velocity, pin order. Then to scan all 1st contacts. Then 2nd contacts. Then worry about the scanning order. All of this using provided MIOS functions.

Please let me know if you agree with my assertion regarding the No of DOUT's required.

And thank you once again.

Robin

[Duggle]

Thorsten has made some comments about this in reply to an earlier question in a previous recent thread. He has suggested the following

As you have indicated it is best to proceed more slowly and use ScanStart in its present form with 1ms period and get the project moving.

Initially I plan to scan all the contacts without worrying about velocity, pin order. Then to scan all 1st contacts. Then 2nd contacts. Then worry about the scanning order. All of this using provided MIOS functions.

Please let me know if you agree with my assertion regarding the No of DOUT's required.

Yes I now see what you mean in regards to the minimum number of DOUTs actually needed.

By doubling up DOUT connections to you scan LH and RH with the same signals. I count 12 required on the RH side (per circuit). The only advantage of having seperate DOUT for LH and RH side is perhaps the ability to scan different combinations of keys according to an optimised scan algorithm which is probably not going to yield great performance benefits.

Especially if you can scan on demand (very useful knowledge, btw!)

cheers