256 DINs?

[wackazong]

Hi!

I was just wondering whether it is at all possible to get 256 DINs in MIOS, provided that:

1) I adjust the corresponding routines in mios_din.inc, mios_srio.inc etc.

2) I adjust the memory allocated in mios_defines.inc

What I would like to know is whether there is any technical/hardware problem that would make it impossible to address 256 DINs, the timing of the interrupt routine for example.

Would be happy for any help,

ALEXander.

[nILS]

A possible and simple answer would be: use two cores

[wackazong]

and if i do not want to two cores? Some tips? Pretty please?

[dj3nk]

matrix

[wackazong]

Don't get me wrong, I looked at the matrix as well, I do not want to use it for my design. The question really is: Is 256 possible, or is it not due to some hardware limitation?

Thanks!

ALEXander.

[TK.]

There are several technical reasons: the additional wire and FANIN load will increase the signal reflections on the SCLK and RCLK line, which are difficult to handle (shorter cables, no connectors between SRs, buffers, terminators). Probably also the SCLK frequency has to be reduced, which leads to a higher CPU load. Since the SRIO handler is running at the same priority level like the UART handler (to save resources), the serial transfer could lead to a MIDI IN buffer overun of it takes longer than ca. 600 uS.

Also the SRIO handler itself is not simply scalable. You will notice this, once you are looking deeper into the code.

Only simple solution I see if programming and testing effort doesn't matter: connect the second DIN/DOUT chain to different GPIO pins, and implement a new SRIO handler (at application level), which scans the two chains in alternating order. This would double the latency (2 mS instead of 1 mS), but it wouldn't affect the CPU load and wouldn't lead to too much additional HW effort. Two GPIOs could be saved, by sharing the So pin between the two DOUT chains, and buffering the SCLK signal between core and the DIN/DOUT chains (4 chains -> 4 buffers). Accordingly two free GPIOs for the second Si signal, and the RCLK (latch output) are required for this method.

Best Regards, Thorsten.

[jimhenry]

If DOUT is not needed and programming effort is not a concern, how about using the DOUT data pin as a second DIN data pin. Connect the second group of 4 DIN boards as you would a group of 4 DOUT boards. Then you can shift both 128 bit shift registers in with the same clocks and read 2 data bits on each shift. You should be able to read all 256 inputs in 1 mSec.

Why don't you want to use a switch matrix? You can use 1 DIN and 1 DOUT and then connect them to a board that has the diodes and pin headers to look like the pin headers on a DIN board. Of course, AFAIK you still give up having a DOUT that you can use as such and there might also be timing issues with larger matrices since you still have to shift in all the input bits in the matrix.

[groovereiter]

Only simple solution I see if programming and testing effort doesn't matter: connect the second DIN/DOUT chain to different GPIO pins, and implement a new SRIO handler (at application level), which scans the two chains in alternating order. This would double the latency (2 mS instead of 1 mS), but it wouldn't affect the CPU load and wouldn't lead to too much additional HW effort. Two GPIOs could be saved, by sharing the So pin between the two DOUT chains, and buffering the SCLK signal between core and the DIN/DOUT chains (4 chains -> 4 buffers). Accordingly two free GPIOs for the second Si signal, and the RCLK (latch output) are required for this method.

Where do I have to connect the second SR chain to make this work? And wich changes do I have to do to the code? I didn' work on the box for some months so I'm completely out of it and I don't have much time for it in the next year. Since the Hardware part is already done any help is appreciated.

[jimhenry]

...I'm completely out of it and I don't have much time for it in the next year. ...

With these two items added to the design criteria, two cores really looks like the best option. Why do you not want to go that way?

[wackazong]

After some months of rather intensive experiences with the MBHP I must say: Just use two cores :)

I do that now as well, and seems to work just fine.

ALEXander.