SRIO, DOUT, DIN, 16 bit , 8bit Confusion

[robinfawell]

I have been reading and re-reading all the elements of the MIOS32 SVN Repository. Traditional Models, SPI, SRIO, DOUT, DIN.

As mentioned previously I am building a digital piano. I want to use a 16 bit DIN and a 16 bit DOUT to scan the keyboard contacts. There are 2 X 88 switches to scan.

s32 MIOS32_SRIO_ScanStart(void *_notify_hook) This function refers at the end to :-

 MIOS32_SPI_TransferBlock(MIOS32_SRIO_SPI,

			   (u8 *)&mios32_srio_dout[0], (u8 *)&mios32_srio_din_buffer[0],

			   MIOS32_SRIO_NUM_SR,

			   MIOS32_SRIO_DMA_Callback);

This shows the two buffers for DOUT and DIN as 8 bit (single bytes). Similarly in Din.c

/////////////////////////////////////////////////////////////////////////////

//! Returns state of a DIN shift register

//! \param[in] sr shift register number (0..15)

//! \return 8bit value of shift register

//! \return -1 if shift register not available

/////////////////////////////////////////////////////////////////////////////

s32 MIOS32_DIN_SRGet(u32 sr)

{

  // check if SR available

  if( sr >= MIOS32_SRIO_NUM_SR )

    return -1;


  return mios32_srio_din[sr];

}

The preamble shows that an 8bit value will be returned.

Question 1

The DIN module reads 16 bits of data with each DOUT strobe. Can and how does MIOS32 deal with this in terms of 8bit values?

Question 2

Has anyone written some code that would be helpful?

Please help me in my confusion!

Robin

[TK.]

I think that the easiest way to clarify this is a small example application which is tailored for your usecase - I can program this :)

But I would have to know how your keyboard is connected to the DIN/DOUT registers - did you already document this somewhere?

Best Regards, Thorsten.

[robinfawell]

Thank you Thorsten.

I have attached the drawing of the Fatar keyboard and the connections to DIN and DOUT.

Matrix Board

This shows that I have connected:-

J3 DOUT Pin1 D0 to BR0 and BR5

J3 DOUT Pin2 D1 to MK0 and MK5

etc

When a key is pressed BRx (1st switch) closes before MKx (2nd switch) closes. When the key is released MKx opens first followed by BRx.

Fatar Circuit

If you examine the arrangement you will see that I could have chosen a 22 DOUT X 8 DIN matrix. However there are restrictions on the length of SR's. Hence the choice of 16 X 16.

On this point is a 12 X 16 matrix feasible? You can see that I have J4 DOUT D4 - D7 unused.

The arrangement shown in the table is not sequential but I think that it may be the best compromise. The pin order and Midi Note will need to be adjusted.

I can utilise the unused J4 DOUT D2 and D3 for the 2 piano pedals and for changing the Midi channels.

I really appreciate your time in helping me.

Regards Robin

Fatar Midibox Matrix Board MIOS32D.doc

[TK.]

Alright, here the application:

http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fexamples%2Ffastscan_button_matrix_16x16%2F

You have to update the complete repository, because I added a new switch (MIOS32_DONT_SERVICE_SRIO_SCAN) to programming_models/traditional/main.c

It's set in mios32_config.h and disables the scan routine which is used by MIOS32

Instead we use our own scan routine now,

In order to keep it simple, we use MIOS32_SPI_TransferByte() accesses directly without DMA and without callbacks.

It's fast enough for your usecase.

The TASK_MatrixScan() task handles the transfers and calls BUTTON_NotifyToggle() whenever a change on the DIN pins has been determined.

This task performs the scan each mS - which means in other words, that the worst-case latency is 1 mS which should be acceptable.

My scope tells me, that the 16x16 scan takes 400 uS (*), which means that the core is loaded by ca. 40% and could do (many) other things in parallel...

(*) speed could be significantly improved by selecting a faster SPI clockrate, but for your usecase the current speed setting is acceptable (and it leads to more robust results!)

BUTTON_NotifyToggle() will be informed about the row, column and pin_value

They will be print in the MIOS terminal like shown in this example:

Once we know, in which rows and columns the keyboard keys are located, a note number can be derived - either table or calculation based.

But for the first experiments the debug messages will be mored helpful.

On this point is a 12 X 16 matrix feasible? You can see that I have J4 DOUT D4 - D7 unused.

unconnected pins won't cause a problem.

Best Regards, Thorsten.

[robinfawell]

Thanks Thorsten

I've checked out the new fast scan program with MIOS Studio and the results are attached. The pin Nos are shown in Red. I've also checked out reducing the number of rows to 13 rather than 16. It works fine, as would be expected.

In addition I've marked in Green the Note Nos. You will see that when the first key A0 is pressed that pin 1 closes followed by pin 2.

The sequence of what happens is shown with an extract from MIOS Studio.

When the key A0 is pressed the 1st switch of the A0 key closes (row 1,col 0, pin value = 0),the 2nd switch closes (row 2, col 0, Pin value = 0).

When the key is released the 2nd switch returns to a pin value 1, followed by the 2nd returning to pin value 1

[3603.390] [bUTTON_NotifyToggle] row=0x01, column=0x00, pin_value=0

[3603.390] [bUTTON_NotifyToggle] row=0x02, column=0x00, pin_value=0

[3603.500] [bUTTON_NotifyToggle] row=0x02, column=0x00, pin_value=1

[3603.515] [bUTTON_NotifyToggle] row=0x01, column=0x00, pin_value=1

Instead we use our own scan routine now,

In order to keep it simple, we use MIOS32_SPI_TransferByte() accesses directly without DMA and without callbacks.

It's fast enough for your usecase.

The TASK_MatrixScan() task handles the transfers and calls BUTTON_NotifyToggle() whenever a change on the DIN pins has been determined.

This task performs the scan each mS - which means in other words, that the worst-case latency is 1 mS which should be acceptable.

My scope tells me, that the 16x16 scan takes 400 uS (*), which means that the core is loaded by ca. 40% and could do (many) other things in parallel...

(*) speed could be significantly improved by selecting a faster SPI clockrate, but for your usecase the current speed setting is acceptable (and it leads to more robust results!)

The exercise has shown the order in which the keyboard switches are scanned and is very useful. It has also helped me to better understand the programming methodology.

For the final version, which will be velocity sensitive, I have always thought that the scan time should as small as possible and that DMA transfer would be needed to achieve this. I understand with the default settings and using DMA a 16 X 16 matrix can have a 220 microsecond scan time. From your scope measurements 400 microS is about twice this.

Duggle discussed this in an earlier message to me. For a very soft key press 128 scans may be needed (if max resolution were to be achieved!). This would take 128 mS at 1mS per scan. Maybe this is too long?

So far, with the 16 X16 matrix I have not seen any evidence of switch bounce using MIOS Studio.

Another thought I have is to investigate "impedance matching" between the DOUT outputs and the DIN Inputs. Has any work been done on this?

This might help in allowing higher frequency clocks. Perhaps some of Duggle' recent work on chaining shift registers may give some pointers.

Thanks Again

Robin

PS Towards the end of Fast scan 16 X 16 there is a STATUS line. What is this for?

 // read DIN, write DOUT

      s32 status = 0;

      u8 din0 = MIOS32_SPI_TransferByte(MIOS32_SRIO_SPI, (select_row_pattern >> 8) & 0xff);

      u8 din1 = MIOS32_SPI_TransferByte(MIOS32_SRIO_SPI, (select_row_pattern >> 0) & 0xff);

Row Col Fast Scan A.doc

Edited October 5, 2010 by robinfawell

[TK.]

Hi Robin,

let's do some additional experiments before deciding if the pins have to be scanned faster, and accordingly a timer function has to be used instead of a FreeRTOS task.

It's also not clear yet, if the scan gets unstable if SPI is clocked faster - it could be that you won't notice any difference, as only two DINs and two DOUTs are connected.

All these assumptions are based on theoretical thoughts, the final result could be much easier that expected! :)

You will find an enhanced version in the respository now which decodes the pins according to your table.

It also measures the delay between pin events.

-> http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fexamples%2Ffastscan_button_matrix_16x16%2F

It would be interesting if the pin numbers are calculated correctly according to your table (I tried to program the required bit-shifting on an easy-to-read way, therefore a bit more code is required, but the compiler will optimize it anyhow so that performance isn't affected)

Then the measured delays are for interest of course.

Please show us the MIOS terminal output when a key is pressed fast (so that a high velocity value should be generated), and very slow (for the lowest velocity)

It's important to see the timestamps/delays for a 1->0->1 transition of both pins (6 debug messages)

Best Regards, Thorsten.

P.S.: the "status" variable was just an artifact, I removed it

[Duggle]

Another thought I have is to investigate "impedance matching" between the DOUT outputs and the DIN Inputs. Has any work been done on this?

This might help in allowing higher frequency clocks. Perhaps some of Duggle' recent work on chaining shift registers may give some pointers.

My investigations in this area are ongoing.

So far Ive found that the signal integrity issues that can limit SRIO clock speeds can be resolved, with various means including:

line driver, pcb layout, transmission line termination.

Ive not yet altered the clock divisor for SPI but speeding it looks up straight forward.

Robin, do you have access to a CRO? Looking at the SCLK line at the end of the chain can provide some indication of how robust transfers will be at a higher clock.

It will also show whether the counter measures are helping the situation by degrees. Just take care that the CRO measurement itself does not change the signal too much. X10 (times 10) probe settings are more "transparent" than X1.

If you don't have access to a CRO, no problem, there will be a little more trial and error, to achieve success (and a little less insight gained).

Are you using SmashTV's PCB's for DIN and DOUT?

I'm ordering a significant number for a project but also to characterise the impedance issues that affect typical MBHP. So far Ive only explored SRIO long chains with a custom layout DOUT configuration. (see blog article)

[robinfawell]

Dear Thorsten

Your reply was very speedy.

I have attached the time stamp data from MIOS STUDIO in a Notepad txt file. It shows 8 lines. The first 4 lines are for a high velocity press and the second four lines are for a very slow press.

I have also checked all keys, I confirm that the Pin Nos are in line with my table.

Best Regards Robin

time stamp.txt

Edited October 6, 2010 by robinfawell

[robinfawell]

Dear Duggle

Thanks for your reply.

Robin, do you have access to a CRO?

Yes I do, but it is a fairly basic one. I haven't used it for some time. I will see if I've got a 10:1 probe for it.

Are you using SmashTV's PCB's for DIN and DOUT?

Yes I have 2 sets of both DINs and DOUTs.

I've been reading Horowitz & Hill (Art of Electronics) they suggest the use of 100 ohms in series with 100 pf from DIN input to ground as an ac termination. I think I've also read that the DOUT impedance is in the order of 50 ohms. In my case there are also an unknown set of diodes with some non-linear impedance when DOUT is low.

I will be pleased to try out anything you think will be beneficial to improve the waveforms.

Regards Robin

Edited October 6, 2010 by robinfawell

[TK.]

As Nils wrote: on a reply, please remove the text between the quote tags, it doesn't need to be duplicated (as you would normaly do when replying to an email)

Could you please write some comments between the debug messages, because I'm unable to find out, when you pressed a key, when it has been released.

Somehow it looks like the keyboard isn't connected correctly, because I would expect that one contact is closed when the key is pressed, another is closed when the key is not pressed. Only this will allow to measure the delay correctly.

In other words: the two pin_values should alternate between pressed/depressed, they shouldn't have the same value.

Best Regards, Thorsten.

[robinfawell]

Dear Thorsten

I've attached a revised MIOS STUDIO debug report. I have checked this twice. I'm not sure what the delays mean. I have definitely shown the high velocity data followed by the low velocity data.

I think that I have deleted the unwanted text>.

Regards Robin

The time between the 1st switch closing and the 2nd switch closing is what determines the velocity. Shorter time means higher velocity and vice versa. It is not a changeover switch. See the Fatar circuit I sent earlier ""matrix_88""

time stamp 2.txt

Edited October 6, 2010 by robinfawell

[Duggle]

Something we need to be very clear about (at the moment): The impedance and signal integrity issues relate to the synchronous serial coms of the SRIO that is SCLK, RCLK and Data In (DIN) and Data out (DOUT) not the parallel out pins of a DOUT module or parallel in pins of a DIN module.

For long chains the signal most likely to suffer from distortion is SCLK as it loops from chip to chip, PCB to PCB, unbuffered. The RCLK has large settle time, and DOUT and DIN signals are buffered at the output of each register chip.

Anyhow, you are not working with long chains. (btw how long is the cable between the core and the PCB''s?)

I suggest the way to proceed is once you get the software reading keys very reliably (albeit with reduced functionality compared to your final application). Then to double the clock rate of the SPI transfers. If I'm not mistaken this will result in a quicker cycle time, enabling you to double the sample rate of your keyboard and achieve your aims (ie resolution of velocity response).

If readings become flakey with a faster clockrate, then we should look at serial coms signal integrity and if necessary remedy with appropriate method (e.g source or series terminations,etc.)

[robinfawell]

Hi Thorsten

Two Switch Velocity Scanning

I have analysed a method to control the sending of Midi On (with velocity) and Midi Off using a Truth Table.

This method assumes that the 2nd Switch DIN Byte is read immediately after the 1st Switch DIN byte.

I'm not sure whether the logic has flaws but it may be useful.

Robin

1st Sw 2nd Switch same scan.doc

[robinfawell]

Dear Duggle

The impedance and signal integrity issues relate to the synchronous serial coms of the SRIO that is SCLK, RCLK and Data In (DIN) and Data out (DOUT) not the parallel out pins of a DOUT module or parallel in pins of a DIN module.

You are right. I wasn't thinking straight.

btw how long is the cable between the core and the PCB''s?

All cables are flat cables with IDC 10 pin plugs. The cable from the Core to the DIN module is about 4 inches. The cable to the DOUT module is daisy chained from the output of the DIN module and is about 2 inches.

This is probably not ideal. It may be better to make one cable with a core 10 pin IDC plug with two connectors at the other end, one for the DIN and one for the DOUT. This would reduce overall length. It would also mean that the signal paths from core to module would be more equal. If equal lengths the 10 pin cable could be split using a crimped terminals at the DIN / DOUT end.

I agree that we should see how far we get using standard modules before adding additional components .

Robin

[TK.]

Thanks Robin, the informations were really useful to understand the mechanism!

The updated version can now be found in the repository:

http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fexamples%2Ffastscan_button_matrix_16x16%2F

The comments should be sufficient to understand how I implemented the "simplified" state machine.

Some more debug messages are print, the velocity is calculated and a note on/off events should be sent.

It would be interesting if this routine is working correctly, and if not: which debug messages are print when a key is pressed/released.

Best Regards, Thorsten.

[Duggle]

Short cable lengths, and small number of DIN and DOUT chips means that you can be fairly confident with your transfers. Wait and see, I suspect if and when you are ready to increase the key sampling rate, that this will be without issue. They're easy to improve if otherwise.

I've seen very significant improvements in the SCLK waveforms with simple addition of a resistor and parallel diode in series with core32 SCLK output.

I'll be adding to the blog article soon with updates.

[robinfawell]

Hi Thorsten

I have tried out the new code. There seems to be a problem. See the MIOS STUDIO Debug message for Key 1 (A0)

[1919.062] [bUTTON_NotifyToggle] row=0x01, column=0x00, pin_value=0 -> pin=1, timestamp=257091 -> IGNORE

[1919.062] (ERROR: string passed to MIOS32_MIDI_SendDebugMessage() is longer than 100 chars!

[1919.171] [bUTTON_NotifyToggle] row=0x02, column=0x00, pin_value=1 -> pin=2, timestamp=257202 -> IGNORE

[1919.187] [bUTTON_NotifyToggle] row=0x01, column=0x00, pin_value=1 -> pin=1, timestamp=257220 -> IGNORE

I've checked a few other keys the results are similar.

Robin

[TK.]

I added another debug message, could you please try again?

Best Regards, Thorsten.

[robinfawell]

Thorsten

Here is the latest result from MIOS STUDIO.

[4032.078] [BUTTON_NotifyToggle] XXX 38533 0 0 0

[4032.078] [BUTTON_NotifyToggle] row=0x01, column=0x00, pin_value=0 -> pin=1, timestamp=38533 -> IGNORE

[4032.084] [BUTTON_NotifyToggle] XXX 38539 1 0 1

[4032.084] (ERROR: string passed to MIOS32_MIDI_SendDebugMessage() is longer than 100 chars!

[4032.202] [BUTTON_NotifyToggle] XXX 38657 1 1 1

[4032.202] [BUTTON_NotifyToggle] row=0x02, column=0x00, pin_value=1 -> pin=2, timestamp=38657 -> IGNORE

[4032.218] [BUTTON_NotifyToggle] XXX 38676 0 1 0

[4032.218] [BUTTON_NotifyToggle] row=0x01, column=0x00, pin_value=1 -> pin=1, timestamp=38676 -> IGNORE

Robin

[TK.]

Ok, it seems that the code is working (are MIDI events sent? The MIDI IN Monitor of MIOS Studio should show them), just the debug message which will show the delay was too long.

Could you please try the updated version?

Best Regards, Thorsten.

[robinfawell]

I forgot to look for them.

Here they are!

5187.328] 90 21 7a

[5188.828] 90 22 7c

[5190.468] 90 23 7c

[5191.531] 90 24 7a

[5192.288] 90 25 7c

[5193.347] 90 26 7a

[5194.240] 90 27 7a

[5194.903] 90 28 7c

[5195.515] 90 29 7c

I have played the first few notes at roughly the same velocity.

However No Midi Off Codes are generated.

I'll check all the notes but I thought you would be pleased with an early reply.

Robin

[TK.]

Note Off events: stupid error from my side, these events should be sent now.

Velocity: it would be important to know which delays have been measured (messages should be short enough now)

Best Regards, Thorsten.

[robinfawell]

Thorsten,

The system is now generating both Midi On with velocity and Midi Off with zero velocity.

I need to go to bed now but will check on delays tomorrow. What measurements would you like?

There seems to be a delay of 226 with a velocity of 1. That's the slowest I can get!

Would that be 226 mS?

Thanks again

Robin

[TK.]

Yes, exactly! :)

I'm using following formula to determine the velocity value:

    // determine velocity depending on delay

    int velocity = 127 - (((delay-KEYBOARD_DELAY_FASTEST) * 127) / (KEYBOARD_DELAY_SLOWEST-KEYBOARD_DELAY_FASTEST));

    // saturate to ensure that range 1..127 won't be exceeded

    if( velocity < 1 )

      velocity = 1;

    if( velocity > 127 )

      velocity = 127;

[/code]




So, the minimum and maximum delay is scaled to a velocity value between 1..127



The constants are defined in the header:

[code]

#define KEYBOARD_DELAY_FASTEST 3

#define KEYBOARD_DELAY_SLOWEST 100

If you notice different min/max delays, just change these constants (and let me know so that I can insert them into the original file) Note that you could try to play a software synth with your keyboard now. It's also possible to control a common MIDI device, just replace:

#define KEYBOARD_MIDI_PORT DEFAULT

[/code]




by:



[code]

#define KEYBOARD_MIDI_PORT UART0

and MIDI events will be sent to the MIDI OUT1 port of the MBHP_CORE_STM32 module.

Best Regards, Thorsten.

[robinfawell]

Dear Thorsten

I did try the last version of fast scan last night and I now have the Midi On and Midi Off working. I have tried it out with 2 soft synths that I have. It works fine. Thank you again.

My Table with Pin No, Rows, Columns

It is inconsistent. I think that both rows and columns should start with 0. It will be more understandable to anyone else who uses the program. A new version is attached below. Please modify the code.

Start Note A0

This should be Decimal 21 ie 0x15. This was found out using the piano synth.

Scan Speed

I appreciate that have taken up a lot of your time recently. But I would like to see whether the scan speed could be increased. I believe that we may have reached the limit using portTICK rate of 1mS.

Can the 1mS portTICK parameter be reduced?

This also raises the subject of DMA. I think that it would be interesting to see what is possible and would add to Duggle's work on this subject.

I also need to incorporate a Midi Channel switch into the piano system and incorporate the two foot pedals (Midi Control Nos 64 and 67). I will utilise the unused Left Hand Bytes Rows B and C for this. I would like to see if I can deal with this on my own.

Regards Robin

PS Rather than being very generous with your time maybe you could give me a few pointers on how to use SRIO.

Row Col Fast Scan B.doc

Edited October 7, 2010 by robinfawell