Pedal switching matrix with the AD75019

[G. Hoffman]

Gain of 2.

If you patched to cascade all 16 channels, gain would be 96dB!)

Their hack for unity gain is ugly.
_______________________

It IS 16 to 16. The decode has 256 outputs (+16 for enable). It is a crossbar where any intersection can have a cross-connect.

The AD8114 is a gain of 1, but still has the 16 to 1 switch, so no parallel routing, and is only +-5V analog rails. 

Which sucks.  Parallel data is so much easier to develop.


Gabriel

[ElectricDruid]

I'm with PRR. That AD8113 looks like it'd do parallel routing to me. Plus it also says up to +/-12V for audio applications. +/-5V is for video, so presumably the slew rate isn't fast enough for the higher voltage at video frequencies. But that's no problem for us.

It says "16x16" and "crosspoint switch matrix" all over the datasheet. What did you mean about it being 16-to-1?

(Thinking I'm missing something of what you're intending here)

Tom

[G. Hoffman]

I'm with PRR. That AD8113 looks like it'd do parallel routing to me. Plus it also says up to +/-12V for audio applications. +/-5V is for video, so presumably the slew rate isn't fast enough for the higher voltage at video frequencies. But that's no problem for us.

It says "16x16" and "crosspoint switch matrix" all over the datasheet. What did you mean about it being 16-to-1?

(Thinking I'm missing something of what you're intending here)

Tom

Each output can only have one input.  First sentence of page 14 in the datasheet, "16 outputs, each of which can be connected to any ONE of 16 inputs."   Compare that with the Product Description of the AD75019, "Any or all of the X terminals may be programmed to connect to any or all of the Y terminals."  At least for what I have in mind, that's a deal breaker.  (I may not be great at a lot of electronics, but I GET complicated switching matrices.  This one doesn't do what I need.)

But think about the parallel logic - four pins for sixteen switches, so any time you switch on an input, you turn off that outputs connection to the other inputs.   I'm not sure if an input can be connected to multiple outputs, but the outputs are strictly one input per.   Or at least, that's how I read the datasheet. 

The +-5V device is the AD8114, which is a unity gain device.  The only one in the line designed for +-12V is the 8113, but as Paul said, gain of 2. 


Gabriel

[Thewoodguy]

Yeah the only thing holding me back from messing around with this is the lack of info for the code. Data sheet is terrible.

[G. Hoffman]

Eh gads!   The AD8114 is also $100 a piece!!!

[PRR]

> can be connected to any ONE of 16 inputs

Ah. You want mixing also. Misunderstood.

[G. Hoffman]

So, I've run into a rather frustrating problem -

I've programmed a 12F629 to output a changing control signal when ever a button is pushed. 

The problem is, what it is outputting (according to the PICkit 2 logic analyzer) isn't what is programmed, nor for that matter what the program shows when I simulate the program in MPLab X. 

So, for the data signal, the data pin needs to go high before the Serial clock pin goes high, and it must stay high until the clock pin goes low.  When all 256 bits have been transmitted, you pulse the Pclk pin.  (The Pclk needs to pulse within 5ms of the last bit being sent.)  And that is what I've programmed, and that is how it simulates, but when I actually run the program the data pin goes high correctly, but it goes low when the Sclk pin goes high, so it clocks as a zero. 

Now, I can turn all of the switches ON by pulling the data pin high on the 75019 through a 10k resistor, so I'm pretty confident I've got the clocks right, but I can't for the life of me figure out why the data pin isn't staying high!!!


Gabriel

[slacker]

Shot in the dark, have you turned off the comparator if the pic's got one?

[G. Hoffman]

Shot in the dark, have you turned off the comparator if the pic's got one?

That might be it, but I've made it work by simply writing the data bit over again as I'm writing the Sclk bit.  It's kind of ugly, but it dealt with the important part, which was seeing if I understand the way the data works.  Which I'm still not sure about, but I HAVE at least managed to write data to the switch.  I've got to try setting specific switches, next, so I can see if I have ANY clue how it works!

But that's for tomorrow, as tonight, I have to sleep at least a little bit!


Gabriel

[Thewoodguy]

Glad you are making progress!

[G. Hoffman]

OK, trying to do more on a bread board was getting confusing, so I'm making a development board - basically, it has all the digital circuitry, and the AD75019, but NOT any of the analog audio stuff - no buffers, mixers, etc.  Here's the schematic (click for an almost legible version!):





The LED matrix is for indication, the "Extra Switches" are for some relays I want to use, and the MIDI thru's are just there because I had extra outputs on the 75HC14.  I decided to go with a PIC16F887 so I didn't have to share to many pins, and so I could leave some room for expansion, should anyone ever want to do anything more than I do with this thing.  For instance, I'm just using the LED matrix for indication, but I had three extra pins, and it worked out they are on the SPI pins, so if someone wanted to add an LCD or something, they could do so.  The 887 also has lots of EEPROM, if someone wanted to implement a way to store patches.  I'm also pretty sure the programming will end up being pretty easy to adapt to either my "8 loops and 8 locations" design, or a "15 loops" design. 

I've designed the board (the interactive router the CERN guys added to KiCAD is a real time saver!), but if anyone has any comments on the schematic, I'd love to hear it.  This is really intended just as a firmware development board, so some of the oddities have to do with that intent (for instance, when it comes time for the final release, I won't have to swap pins 6 & 7 on port B for RC0 and RC1, but I want to be able to use my PICkit for debugging, so I need to leave RB6 & RB7 to the debugger.)

If I can find that MIDI recieve object file I wrote, once upon a time, I might actually get this thing done in a few months.  Probably not, but maybe!


Gabriel

[ElectricDruid]

The problem is, what it is outputting isn't what is programmed

Unfortunately, it almost certainly *is* what is programmed, although it's interesting that the sim doesn't think so. However, I trust the chip more than the sim. The computer always does what it's told. In 35 years, I've only had two examples where that was not the case. One was a hardware bug on the 6502 to do with pages not wrapping correctly, and the other was more recently with the PIC 16F1788, which was released with significant bugs in the silicon.

Paste the code and we could have a look?

Tom

[G. Hoffman]

, and the other was more recently with the PIC 16F1788, which was released with significant bugs in the silicon.

Paste the code and we could have a look?

Tom

How many hairs did you lose figuring THAT one out?   Sounds unbelievably frustrating. 

It was a throw away bit of code - I needed to populate the data registers with semi random data, so I put a "1" in the first register, then rotated it left to populate the rest.  It should have changed every time I pushed the button, because the wrap around had a remainder, but it didn't change.  I got all the other issues worked out. 

If I remember, I'll post the code, but I've already kind of moved on, and as I said, it was a bit of a throw away. 


Gabriel

[G. Hoffman]

I was going to try to come up with two versions of this program, one for my 8 loops/8 locations design, and one for the 15 loops/15 outputs idea that R.G. originally came up with, but I'm not sure that's going to be possible.

See, with my idea, you only need 8 MIDI cc#'s - one for each loop, and you assign it to the location based on the value of the cc#.  Since each loop can only be assigned to one location (though the locations can take any number of loops), the MIDI implementation is pretty easy.  There are only about 72 possible switch configurations, including everything off, and it only really needs 8 data registers.

For R.G.'s design, there are over a million configurations, and I'd need a CC# for each switch (256!!!!), which is more than are available.  It only needs 32 data registers, which isn't a problem, but since you want to be able to have more than one active on each column and each row, I can't think of a cleaver way to implement the MIDI CC#s.  You can't just use one CC# for each column, because then you've only got one row at a time, and even some complex system of a different switch group for each CC# value doesn't work, because you've only got 7 bits to work with and it needs a 16 bit word!  If someone else has a cleaver way to implement the MIDI part of it, let me know, but I for one am flummoxed on that one.

But my design does seem to be coming along pretty well.  Unfortunately, I'm getting hit with a bout of insomnia, and my dad is going in for a (relatively minor, but still...) brain surgery on Thursday, so I think I'm going to have to slow down for a while. 

I've got a first pass at the main loop written (the LED matrix, which is pretty simple), and I've started to write the MIDI interrupt sub-routine.  It's interrupting alright, and context saving is happening as it should (at least, in the MPLAB software simulator, which may be misleading me!), but I've no idea if I've got the USART set up right yet.  I need some hardware for that, and only just ordered the development board I designed for this project today, so I probably won't see it until the end of next week. 


Gabriel

[G. Hoffman]

If you want it to be only series configurations, the 15 loops version is easy to implement, by the way.  Is that what you had in mind, R.G.?

[Thewoodguy]

Yeah I was thinking of doing the order switching part of the looper. Save The the loop order as part of a preset. Then just recall presets with a PC. I would put it in with the foot controller, so each preset could also send out midi comands for all my other midi gear. Basically just like the boss es8 but with more parellel options

[Thewoodguy]

With that said if you can store different orders as presets. you could recall those presets with a program change then use the same CC to turn on and off each loop. You could do a whole bunch of coding to have just a couple cc to move a loop up or down the chain then a save to save that order. Personally I wouldn't want to do all of that with a foot controller. Better done on a screen of some sort

[G. Hoffman]

Well, I'm not very concerned with the user interface - I'm planning to just figure out the MIDI implementation, and let someone else take it from there.  For what I want, a foot controller should work great. 

Not sure about using patch changes.  I'm still not sure how much program memory I'm going to need, but with 32 data registers per patch, and only 256 bytes of eeprom,  you would need to either write to the program memory, or to add an external eeprom.

[Thewoodguy]

External eeprom was what I was thinking

[G. Hoffman]

OK, so the PICbaud calculator I have is telling me something completely different from what the data sheet seems to be telling me!!!


The calculator is telling me BRGH = 0, SPBRG = 7.

BUT, when I calculate it using the formula from the data sheet {SPBRG=(Fosc/Baud/64)-1}, I get {SPBRG=(4000000/31250/64)-1=1.  That's with BRGH off.

I'm going to go with what I calculated, but I wish Microchip had a convenient tool for this crap.


Gabriel