Duggle

First of all, which circuit on the linked article did you build?

Ok I've signed up for the PCB, and the desktop case. It would be awful to have to resort to cardboard for the front panel, I'm in!

I'm interested. I've seen the desktop case for this, ('scuse ignorance) but is there a PCB for the UI that fits this front panel? (I guess I'd want to know that case+panel+pcb) are all available before confirming.

I agree with your observation but bear in mind: The comments made about scan speed only relate to the resolution of raw timing values that get converted into midi velocity from a possible 127 down to 1. You already have nearly double the resolution you require for the linear response curve! Now when we talk about delays in this context it's usually referred to as latency, its the speed with which events manifest from a cause. In modern DAW's and digital instruments etc often the greatest latency is caused by the distance from the ear to the monitor speaker (speed of sound 1 millisecond per foot!) Other sources of latency (that get added together) are MIOS32 event processing cycle (1ms, I think), uart MIDI (1ms per note), or USB to host system (about 1ms or more with jitter), DAW host and softsynth (<=5ms very good, 10ms or so is usually acceptable)

I'd encourage you now that you have your application working to enhance it and extend it in various ways that occur to you as useful, keeping the variously modified working versions for reference.(Its the best way to learn!) Having said this Interestingly if 226ms or so is the lowest velocity then a 1ms sample rate seems actually more than adequate. How is the velocity resolution for fast (or rather, hard) key hits? I imagine it is very good. If you were to implement a range of selectable velocity response curves then its conceivable that you could do with the raw velocity timings of a higher resolution (implying a faster scan rate). I suspect this to be only marginally subjectively beneficial. With short wires and few DIN and DOUT, I don't think signal integrity issues will stop you increasing the spi clock, allowing you to increase the scan rate.

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.

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.)

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)

Well I can report the method certainly works well. To proceed as simply as possible I've added s32 MIOS32_DOUT_SRSet_Paged(u32 pg, u32 sr, u8 value) and s32 MIOS32_DOUT_SRGet_Paged(u32 pg, u32 sr) to mios32_dout.c for get/setting the data. Plus changed s32 MIOS32_SRIO_ScanStart(void *_notify_hook) to roll through the pages with each execution. I use conditional compilation to allow for compiling normal unpaged dout apps. I think this is the most transparent and simplest way for now. I'll continue to develop the application support routines for this and report back later!

Maximum number of connected Shift register chips: Actually, looking at the Oscilloscope traces, the period is (7*250ns)~=2us which equals ~500KHz SCLK. If data is one bit per clock cycle then 500 bits per millisecond. (not 1000, as I stated in the conclusion) This equates to around 50 to 60 shift register chips maximum.

Ok, looks simple enough. As an extension to MIOS32 define volatile u8 mios32_srio_dout_bufpages[DOUT_NUM_BUFPAGES][[MIOS32_SRIO_NUM_SR]; //paged buffer dout arrayA family of helper functions to set the page data for RGB, TriLED, single variable brightness LED, row/col matrix wired LED, etc.define MIOS32_SRIO_ScanStart_DoutPaged() which has a rotating index when providing a dout array pointer to MIOS32_SPI_TransferBlock(..)Put a #ifdef switch in void vApplicationTickHook(void) so that MIOS32_SRIO_ScanStart_DoutPaged() is called instead of MIOS32_SRIO_ScanStart() Question: Is there a way of achieving (4.) without modifying MIOS32 source code? If I'm correct then the rest can be achieved as a pure add on module i.e not modifying MIOS32 source. I'm very happy to commit to the repo, but I dont want to "bloat" anything!

Sure, but I'm not quite sure how the additional DOUT register is wired to the matrix, and why 8 pages? Edit: Having thought a some more about this, if there is a page each for the number of matrix columns,then row/column matrix's can be driven this way.

The idea is inspired by the desire to drive DOUT attached LED's with individual variable brightness. Rather than have a single dimension array volatile u8 mios32_srio_dout[MIOS32_SRIO_NUM_SR]; The idea is to have 2D array with a number of buffer pages: #define DOUT_NUM_BUFPAGES 2 volatile u8 mios32_srio_dout[DOUT_NUM_BUFPAGES][[MIOS32_SRIO_NUM_SR]; At a lower level MIOS would alternate pages by presumably setting a pointer prior to each DMA transfer. In the above example any attached LED could be run at 100%, 50% (or 0%) brightness. When setting the brightness level for a particular LED, the same bit is set and/or cleared in different pages. Taking the concept further #define DOUT_NUM_BUFPAGES 10 would produce 10 level, 100Hz, brightness control. Actually its does not have to be Pulse Width Modulation exactly. It is more like Pulse Density Modulation (if such a term exists). This is because the on and off bits can be randomly distributed in the pages, for any given LED. When set, the background processing is achieved with almost zero extra overhead. Just updating the page pointer each SRIO cycle?

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

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.

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)?

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

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.

Thanks, TK. That performance is very good. I imagine it is even better at 25(degC). The AVRs only last for about 1000 rewrites IIRC.

I had a work related project on an ATmega target that mysteriously failed some months into the project development. It turned out that I had exceeded the flash re-write lifetime for the device after much hacking and experimentation (lots of flash programming). I ended up utilising an eeprom based counting feature of the flash programmer software AVRDUDE. It is able to report the number of flash programs on each target chip. Anyhow, I was wondering how many re-flashes can our STM32 take before it fails?

There are a few points to make: -Relatively low series resistances slow the edges sufficient to reduce ringing (at least in my case). The circuit has a 220R pullup. I've added 100R in series (maybe smaller will work). It was only the falling edge (open drain) that energised the ringing. -There are other ways of controlling edge rise/fall time that are not increasing the resistance. e.g parallel capacitance reduces series impedance (for high frequencies), also configuring a driver that has a controlled edge speed does not have to increase series resistance. Having said this I need to look at how my circuit and the MBHP layouts differ. I have routed my PCB MKLD Double sided with a ground plain to reduce the inductance (potentially increasing the capacitance somewhat, I'll measure this). I suspect that the traditional MBHP layouts have significant inductance. (Minimizing the effective area of the signal/return current path is the main way of minimizing inductance. Inductively coupled noise spikes are thus avoided. )The point here is that my method of slowing the clock edge that worked for MKLD may not work so well for traditional DOUT chains. I will do some measurements with an LCR meter I have access to. I might even purchase a bunch of DOUT PCB's to test. The simplified telegrapher's equation for characteristic impedance is sqrt(L/C). It ignores series resistance R and leakage G, a safe assumption for us. I will first of all measure the inductance of the SCLK (shorted to ground at far end) and then capacitance for a length of ribbon, then including the chain of SR's. I'll look at the effect of the position of GND in the cable. I think the best is to have GND in between DOUT/DIN and SLCK. I'll try to quantify the significance of this. Also comparing this to shielded multicore. Future revisions -If we accept the fact that ribbons have a characteristic impedance of 100R, then we can design our layouts to match this. This then allows for 100R (AC or DC) termination which makes for much less EMC susceptibility. i.e impedance matched systems are much more noise immune. -It may be possible to compile some design rules for user project MBHP PCBs to follow in order to produce controlled impedance designs and importantly when not to bother (such as your "16 shift register chain is fine" guideline). I'm beginning to think that controlled impedance layouts are the way of the future. The point relating EMC performance with impedance matching is made very clearly in the article I reference in the Blog article. Who wants to be on stage (or similar critical situation) when lighting equipment creates a spike that brings down one's midibox !!!!

You could look up "photointerrupter" these are a device with an IR LED and matched Phototransistor in a 4pin package. They are mounted in such a way that the mechanical thing you want to do the actuating with passes into a channel in the plastic package/housing where it interrupts the beam. They are low cost (especially with the number you'll be needing). Just run a DC current through the LED's in suitable series stings (or individual current limiting resistors of a DC supply rail) and connect the Phototransistor o/p to DINs. Sounds like a labour of love though, however you do it .

Hi Underskor, If I saw this I would be referring to the STM32 chip datasheet along with the CORE32 design to see which Jxx connector the processor pin PC15 actually connects to. This should narrow down the search for shorts. Can you run the test without any other peripherals connected?

Yes, there is interaction with the measurement, sometimes detrimental or otherwise. For example I found the ringing improved significantly by using a 10:1 probe setting rather than 1:1. I gather that this reduced the capacitance of the probe lead due to the divider in the probe. i.e a higher divider ratio means less capacitance, a more "objective" measurement. In this case the ringing wasn't as bad as it first looked. I have to consider that the signal integrity issues I've come up against so far have not been bad enough for my DOUT setup not to work! I need to follow up with longer chains and ribbons to force the issue! With the SCLK of only 500kHz I feel that we should not have transmission line problems. It requires further quantification and calculation. If slowing the clock edge rise time to say 100ns does not violate timings (it certainly tames ringing) and given that propagation delays are ~7ns/m should not cause problematic clock skew, the situation is hopeful. I need to model (on paper) the scenarios of DIN and DOUT chains and their wiring to convince myself thoroughly on this. Like I said Its a "feeling" based on the overall situation. I'll look into it. The issues you mention, in relation to community based projects (guiding newbies etc) where only the lowest level of knowledge can be assumed and the range of configurations and applications is rather large, are challenging. One idea is to have a line driver on the core (or daughter board) that has jumpers to vary the source termination depending on the exact scenario. Could clock skew problems be overcome by assuming a constraint where DIN and DOUTs must be of equal physical length? (like those squiggly tracks on high speed PCBs, however I'm thinking of the ribbon wires that could be folded). The 100R+100pF termination is interesting given that the characteristic impedance of ribbons is around 100 Ohm (with signal next to ground conductor on the ribbon). As I'm sure you understand, matching the characteristic impedance with a load at the end of the line absorbs the energy of the voltage and current waves thus eliminating the problematic reflections. With specific regard to the AC termination mentioned, depending on the source resistance, it may also slow down the rise/fall time, also helping.

Well, Ive added a blog article on my experiences with the long DOUT chain. TK, the waveforms I'm getting from the DOUT SCLK of the STM32 are very different from yours. I get a full swing of about 0.5V to 5V and a very fast falling edge. It seems quite different from the waveforms you posted (the"sexy" ones). I dont have a large number of MBHP DOUT PCBs to test this but I'm interested to see if the "working solution" works for traditional MBHP DOUT chains with both STM32 and PIC. It may be that the parasitics are a lot worse with the traditional layout. I've made the MKLD pcb double sided with ground plane for low inductance etc. I plan to post info on this project as I develop it further.