Sam_K

Progress!!! After heaps of research into the SRIO and SPI interfaces, which mainly involved reading through the MIOS and FreeRTOS code, I finally took the plunge this past weekend and now I have my own matrix scanning code working! My application now polls the entire keyboard matrix on each application tick (1ms). The response is much better than it was before, but it is still not excellant. Due to the nature of how it works, the resolution of the velocity detection gets worse the faster you hit the key, so at the upper end of the scale the resolution of the velocity sensing is quite poor. For example: * A deliberately slow keypress is in the low hundreds of milliseconds (between the first and second key contact closing) * A mild keypress gets you around 20-50ms * A moderately firm key press usually gets you 5-10ms, . * A reasonably fast/hard hit typically produces a result of 2-4ms * You have to hit it VERY hard and fast to get 1ms * You have to hit it VERY hard and fast AND get lucky to get 0ms So, by my subjective experience, 10ms is what I would call the mid-point of velocities. So there are only 10 steps of resolution between a "mid range strike" and the very fastest possible velocity, but there are hundreds of steps between that same mid-point and the slowest (practical) velocity. When doing rapidly repeated hard strikes it is easy to get a run of several keystrikes all with exactly the same value around 5ms. This doesn't strike me as being conducive of an expressive instrument but I'll really have to play it and see if it really is bad or not. I also tried increasing the configTICK_RATE_HZ (in FreeRTOSConfig.h) from 1000 to 5000 and even 10000, but it seemed to make no difference at all. Perhaps there is something else I need to do also to make my scanner run more frequently, or perhaps the CPU is already running as fast as it can go? I'm not sure. Anyway, I'm still pretty chuffed to have (mostly) pushed through this obstacle. I think that is possibly the hardest part of the project behind me now other than perhaps the final finish on the case. :thumbsup:

Oh God! I'm soooo stoopid! I had re-enabled standard MIOS SRIO scanning to try something and forgotten to turn it off again. So the regular SRIO code, and my custom SRIO code where taking turns setting the DOUT pins. :wacko: Thanks agin for your time TK, sorry to waste it on a dumb coding goof.

Righty-Ho! Believe it or not, it's a software problem with my app! Whilst preparing my answers to your last post, I wrote a skeleeton app to just test the most basic case and the problem went away! (DOUTs are at VD when High (4.7v), and DINs register that as logic high.) Re-uploaded the original app, problem is back again. So, at this point, my assumption is that the DOUTs are flickering rapidly between high and low which is causing the DINs to read a low value and would also explain the lowered voltage reading (I am just using a cheap multimeter, not a CRO). So now I need to figure out where my custom SRIO code is going wrong. I thought I had all the DOUTs set high, but it seems that is not what is going on.

Hi TK, Thanks for your reply! I made these checks and measurements just now. J23 definitely selects 5V and R31 is stuffed with the resistor array which is fitted in the correct orientation. Voltage at MBHP_CORE_STM32::J2 is 4.8V Voltage at DIN::J1 is 4.8V Voltage at DOUT::J2 is 4.8V (far end of DIN/DOUT daisy chain) Voltage at Vcc pin of all DIN and DOUT shift registers is 4.8V *Note: I am powering the core via USB from my laptop, the supplied voltage measured at J2 tends to slowly drift up and down over time by as much as 0.2v, presumably due to the state of charge of the laptop battery. I also double checked that all the DIN/DOUT DIP sockets are stuffed with the correct chips (SN74HC165N on DIN and SN74HC595N on DOUT) and that they are fitted in the correct orientation. I have also done the same tests using DIN::J4 in case there was a problem with the shift register connected to DIN::J3 but I still get the same results.

I am trying to hook up a keyboard matrix to my Core32 module and I've run into a problem. I have a DIN and a DOUT module (both PCBs are R5) daisy chained together and hooked up to J8/9 on the STM32_R1 core module. In testing this issue, I have actually removed the keyboard altogether, so I won't describe it's circuit here. I am just trying to hook a DOUT pin directly to a DIN pin and trying to read the DOUT value from the DIN and I can't get even this simple test to work. The resistors between the shift register and J3 on the DOUT module have been bypassed. When set to "logic high" the output voltage at a DOUT pin is 4.14V. Vcc at the DOUT shift register chip is 4.77V (and is also 4.77V at J2 on the core module). The core of the problem seems to be this. At any DIN input, a voltage of 4.14V is being registered as a "logic low" value. According to the spec sheet of the SN74HC165N shift register on the DIN module, any value over 3.15V (at Vcc=4.5V) is supposed to be interpreted as "logic high". If I connect Vd from the DIN module (4.77V) directly to the DIN pin, it is read as "logic high". Given this set of circumstances, how can my keyboard matrix work at all??? Why is 4.14V being interpreted as logic low contrary to the specs of the shift register? Really hoping that I've just done something stoopid that someone can easily point out, cos I'm really stumped. Cheers, and thanks in advance for your help, Sam

I've got my keyboard matrix hooked up and did some experiments with the software. Unfortunately it looks like I am going to have to bypass the SRIO API layer and interface to the SPI directly. Just using the APP_SRIO_* hooks, I can only scan one column per SRIO pass, this means that the minimum velocity time that can be detected is the number of columns in milliseconds. This is an order of magnitude too slow for decent velocity detection. It looks like scanning the whole key matrix every millisecond might just be adequate, but I have a feeling I'm going to end up having to scan twice per millisecond to get a really good velocity response.

Thanks for that link Wilba, it is an interesting read. That circuit is a little beyond my abilities at the moment but I will certainly keep it in mind when I revisit the design of the soft-pot connections. For the time being the current circuit is good enough for me to focus on getting the other components working. Reading through the text it seems that a lot of the problems they are trying to solve in that circuit are things that I am dealing with in software instead.

I have the software working well now for driving the strips. I just spent about half an hour playing various synths with it and it was really fun which is a good sign. The dual touch works surprisingly well. I am really happy at the moment because I really had no idea when I started if the touch strips were going to turn out to actually be enjoyable to play. The $300 I've spent so far to get to this point was a pretty big gamble and I can now say that it has paid off! The code is a bit of a labyrinth of logic as there are 3 different types of strip (soft-pot, inverted soft-pot and FSR), each can have up to 5 different states (Off, Transition to On, On, Transition between notes, Transition to Off) and all the strips are depoendant on each other to provide things like dual touch and velocity.

OOOOOOOOOOOOOOOKAAAAAAAAAAAAY..... I worked it out. I'm using the wrong function. :blush: I should have been using MIOS32_AIN_PinGet() :rolleyes:

I went and looked at the code for MIOS_BOARD_J5_PinGet() in mios32/STM32F10x/mios32_board.c and I learned 2 things. Firstly I need to set a #define for J5_NUM_PINS before PinGet will work. I put this into my mios32_config.h file as a line that reads "#define J5_NUM_PINS 6". Is that correct? EDIT: I now see that J5_NUM_PINS is #defined to 12 elsewhere in mios32_board.c Secondly, the last line of MIOS_BOARD_J5_PinGet() looks like this: return (j5_pin[pin].port->IDR & j5_pin[pin].pin_mask) ? 1 : 0; Now, I'm no C expert, but my interpretation of that line of code is that it could only ever return a 1 or a 0, but I am expecting this function to return a value between 0 and 4096! Confused....

I am developing a MIOS32 app and I've run into a bit of a problem. When I try to use MIOS32_BOARD_J5_PinGet() it always returns zero, however if I check the same pin in the APP_AIN_NotifyChange() hook the hook does get called with changes of input and the value provided to the hook is correct. Attached is a minimumal app to demonstrate the problem. If you compile and run this app as is then you should see just "0000" in the top left of the LCD screen which does not change in response to analogue values at pin 0. If you look at APP_AIN_NotifyChange() in app.c you will see there is two versions of the line that prints the value of pin 0 to the LCD. One line simply prints "pin_value" (this one is commented out) and the other line re-fetches the value using MIOS32_BOARD_J5_PinGet(0). When "pin_value" is printed, the correct value is shown (changing value between 0 and 4096), but when the value from MIOS32_BOARD_J5_PinGet() is printed, it always comes out as 0000. From my reading of things, both of these lines should produce exactly the same result. What am I doing wrong? j5_test.zip

Hi Wilba, Thanks for your post! Yes your interpretation of my problem with the voltage range is correct. At first glance that diode protection circuit certainly looks promising, I'll put my thinkbone onto it tonight to see what I can do. Regarding the behaviour of the touch strips at the on/off transitions, yes they do ramp. As you press down, the resistance swings down from Infinity until it settles at the correct resistance. As you release, the resistance swings upwards until it reaches infinity. My code accounts for this by waiting for the analogue input value to stabilise before acting on it. On the Soft-pot, these transitions are very quick, smooth and predictable and so are easy to account for. The FSR however is VERY jumpy and erratic, even after reaching the correct "on" state it still swings around pretty wildly, I think I will have to write some kind of smoothing routine that is always in effect for the FSR rather than just debouncing the transitions.

OMG IT FREAKING WORKS!!!! :frantics: :D I have coded for basic note on/off with pitch and velocity. It is so awesome to actually hear sounds come out of the speakers in response to touching the strip.

Tested, cabled and working. Yay! The actual swing displayed on the LCD is 0->2520 and the R2-open-circuit voltage is only 3.25v. I immediately suspected and confirmed that the 5V line from the USB port on my laptop was not quite 5V, it was at around 4.7v. In the long run I intend this to be battery powered from a 2 cell LiPo battery (7.4v) through the Core32's own 5v regulator so I won't make any changes to that for now. Now to get it to send MIDI...

Well it's been a long few days of research and head scratching but I have finally found a satisfactory solution. First off, that circuit I posted above could be made to work if you just reverse the positions of the fixed and variable resistors, That way when the pot goes open circuit the analogue input goes to ground instead of 5V, but the real problem with using a basic voltage divider like that is that the voltage response is a knee curve and that voltage knee curve causes one of the end of the touch strip to have very low resolution. I actually built this circuit and wrote an app to just display the raw analogue input values on the LCD screen. With the analogue deadband set to just 2 ticks, at the low-rez end of the sensor I could actually wiggle my finger on the sensor and have no change registering at the MIOS callback level. Whereas at the other end of the sensor the same wiggle would produce triple digit swings in the number. So, out with the basic voltage divider. At this point I knew that what I really needed was some kind of automatically adjusting resistor to go in place of the fixed resistor in the voltage divider. If I had a resistor that would adjust in opposite proportion to the variable resistor then the voltage response across the variable resistor would be a straight line thus giving me a consistant response and resolution across the full length of the touch strip. With some thinking I realised that this theoretical auto-variable resistor could only work if it adjusted itself according to the current that was flowing through the circuit. With this in mind I did a bit of googling around and discovered the "current regulator" circuit that can be built using a variable voltage regulator. After studying current regulator circuits for a bit I realised that I could get what I wanted by using a standard variable voltage regulator circuit applied to a nominal load with the touch strip being used to control the regulator voltage. (see attached pic) Due to the voltage regulator keeping a fixed voltage across R1 this means that the voltage across R2 changes in linear proportion to the changing resistance. As I sweep through the full range of 0 to 20K ohms on the touch strip, the voltage at Ain sweeps from 0v to 2.35v. This is because the maximum possible voltage at Vout is 3.6V with a 5V input, and there is always 1.25v across R1. When I take my finger off the touch strip and R2 goes open circuit, the voltage at Ain jumps up to 3.6v which happens to be the maximum allowable voltage at the analogue input pins according the STM32 specs. I cannot get the voltage across R2 to go any higher than 2.35v without the "open circuit R2" voltage going above 3.6V. Also I cannot swap R1 and R2 (To make Ain go to ground when R2 goes open circuit) because the maths just doesn't work right when R1 is the variable resistor. I have setup this circuit on the proto-board and it all works as predicted. Along the way I also discovered that RLoad was necessary otherwise the LM317 would not operate properly as a minimum current of 10mA is required at Vout in order for the regulator to run. Of the full 12 bit range of 4096 input values at the analogue input, I am utilising the range 0 to 2820 with the number 4096 representing "no touch". This gives me a consistant 5.64 values per millimeter. It would be even better if I could utilise the full sweep of 4096 values, but I am happy with my progress so far. Tonight I also designed and built a veroboard circuit based on this design with three seperate regulators to drive all three of the variable resistors in my test strip (2 in the soft-pot, one in the FSR). I have finished all the soldering but still have yet to check my work. Probably another couple of hours of double checking everything and making some cables to go to the Core32 before I can finally plug it in. I hope you don't mind the long winded explanation but I am learning a lot and it's fun to share. Cheers Sam

I've now realised this problem is not going to go away, because the FSR Strip (The one that measures the touch pressure) is only a rheostat (2 pin resistor), not a potentiometer (3 pin voltage divider). The FSR also has the same property of being an open circuit when no touch is applied. To use the FSR at all I still have to solve this same problem of needing to control a voltage between Vdd and Gnd using a single rheostat that can also be open circuit part of the time. When (not if) I find a circuit to solve this problem, then I can use the same circuit to exploit the soft-pot for dual touch.

OK I think I've answered my own question, which is that yes, that circuit will let the magic smoke out. After thinking about it I realised that when the soft-pot goes open circuit the Analogue inputs will get pulled up to 5V or close to it. I downloaded the specs for the STM32 chip and confirmed that the voltage on the analogue inputs is not to exceed 3.6v. So for now I will put a dual-touch implementation on the back burner until either I have an epiphany or someone else can suggest a workable answer.

OK I think I may have found a solution to give me 2 point multi-touch from the soft-pot, but I am going to need a little advice. I have attached a circuit diagram to this post that should hopefully do the trick. (Excuse my dodgy MS Paint rendition) The only sticking point is that when you lift your finger off the soft-pot, the potentiometer goes open circuit. (The wiper is lifted off the track) This means that the two analogue inputs to the STM32 chip will simply be attached to 5V through a 10.3K resistor. Will this let the magic smoke out?

I'm pretty excited right now because I just figured out that the soft-pots are actually dual-touch capable! They have 3 pins on them, one that measures from one end of the strip to the point of touch, a 2nd that measures from the other end of the strip to the point of touch, and a common ground. Thing is, each of those touch measurements is between the respective end and the first point of touch from that end, other touches beyond that point have no effect on the reading. This means that if you monitor from both ends you can touch it in 2 places and know where both touch points are!!! Very excited about this! EDIT: Oh.. wait.. never mind.... I see now.. pin 1 is vdd, pin2 is gnd and pin 3 is the variable. boo... that's boring... Surely there must be a way I can exploit this???

Thanks to your hints SSP I found the problem! First I adjusted the contrast to the middle position of the dial and the screen went blank all over. At least now I know what that pot does. So then I took your advice to check the conections and did a continuity check between the solder points on the back of the Core32 and the solder points on the back of the LCD module with my multi-meter. (I used a DIL header and IDC connector on the LCD module side for ease of soldering) Turns out that the RS line consistantly measures at 1.8K Ohms, so I opened up the IDC plug connector at the LCD end and worked the RS wire up and down connector blades to help it cut through the insulation. After that it now measures at 0 Ohms so I put it all back together and turned it on and it was still blank. So then I tried the coontrast pot again and there it was! "see README.txt for details". YAY!

Here is a link to the spec sheet for the LCD in case it helps. QP-5516 16x2 LCD

Some more progress tonight. I got some more MIDI cables and tested both sets of MIDI ports with the MIOSStudio "Query" function and everything worked. I also bought a 16x2 LCD display module from my local electronics store (Jaycar). This did not go so well. Getting it wired up correctly was a bit of a brain teaser, especially since on the LCD end I was wiring it into the backside of the PCB. I did it wrong a couple of times and ended up having to draw a fully detailed diagram on a sheet of A4 paper so that I could make sure I was getting everything right. When I finally had it hooked up properly it did the following. As soon as power is applied the backlight comes on and the top line of characters has every pixel on (a row of 16 solid filled rectangles) and the bottom row has every pixel off (totally blank) and this is all it will do. It doesn't change after the "MIDI 2x2" application is loaded and running and I also cannot get it to change at all with the MIOSStudio "MIOS LCD Message" window. At this point I am a bit stumped, I have triple checked the wiring and as far as I can tell it is definitely wired up correctly. I am a littlle worried I may have fried the LCD display on those occasions when I had wired it wrong. I can confidently say that VDD and VSS were ALWAYS wired correctly and that B+ and B- were always going to the backlight (though I had the backlight wired in reverse polarity at one point) everything else got plugged up all arse about at one stage or another though. Any ideas? Did I kill the LCD or the Core32? That's all I have time for tonight. Hopefully a lightbulb will come on next time. :\

Core32 module finished and working! Well, working as far as I can tell. Embarrasingly, I only have one MIDI cable in the house so I can't test the MIDI sockets (requires 2 cables). Also I haven't gotten around to sourcing my LCD display so I can't test that either. However, the whole thing is fully built and it still happily does the MIDI Query test via USB so that's a win. I'll also take this opportunity to say that the PCB provided by SmashTV is a top quality piece of kit.

Ooops! Never mind. I didn't follow instructions properly to set-up MIDI routing in MIOS studio. It's all working fine now.

OK, hit my first speed bump. [EDIT: Fixed.. My bad, I didn't follow instructions] I am up to the part where it should identify to the computer as a MIDI device, and I should be able to Query the device info using MIOS Studio. Here is what happens, when I plug the board into the USB port WinXP reports it as a "USB Audio Device" (not MIDI) and when I do a Query in MIOS Studio it never finishes and no info is returned. When I look in Device Manager, in the "Sound, video and game controllers" section I have a "USB Audio Device". When I open the properties for this device it shows the following info: [General Tab] USB Audio Device Device Type: Sound, video and game controllers Manufacturer: (Generic USB Audio) Location: Location 0 (MIOS32) Device Status: This device is working properly [Properties Tab] +Audio Devices -->USB Audio Device +MIDI Devices and Instruments -->WDM MIDI Device +Mixer Devices -->USB Audio Device +Line Input Devices -->USB Audio Device Now in there it does show a WDM MIDI Device as being present and functional, but the MIOS Studio app just can't seem to either find it or get any data out of it. Any help or ideas appreciated.