lichtuberstromt

Yeah I think I was confused when I came to that specific conclusion. Using the MIDIO128 as a testing tool, it works fine on J19 with your modified code perfectly. Switching to J8/9 makes MUX 1 act strange and have an incorrect pin order. The other 2 MUXes continue to behave perfectly. Still a lot of random data coming through from the "other" module that doesn't exist, but I'm just parsing that out and it seems to work fine. I'll try reducing the channels and number of inputs. Appreciate seeing your code for HAARP. I think I may do the same and move to a copy in the app folder so I can leave the original AINSER module in its original state. Read through the datasheet for ADC (MPC3208 - I stuck with the 8 channel for unknown reasons) and all I can imagine is that Din is doing something really strange when it tries to read from the first MUX. If I remember right it has the ability to go low and create leading zeros, and maybe its doing it in some kind of mysterious way that leaves me with an unordered (but repeatable) set of pins. Seems like a really far-fetched explanation though. My other thought is that J8 is just running a different clock speed that is making things act strange. Seems equally far fetched though. Do you (or anyone) know of potential conflicts on SPI 1? I've moved SRIO to SPI 0 with no change, and I think there is some overlay from the non-audio DAC, but I'm not using it anywhere. Otherwise I'm not seeing how SPI 1 should be operating so differently from SPI 2. It would make more sense if it just didn't work at all, but changing the pins of just 1 MUX is so odd... Thanks again for all your help! And a happy holiday to all celebrating anything! Or not! Happy day regardless!

one more new problem... I have a pin map that works for MUX 2 and 3. Doesn't work for MUX 1. The obvious answer would be that I screwed up the layout, but I keep checking it and everything is fine. And that kind of makes me think of the A B and C lines again. MUX 1 is just really off. Tried swapping chips again with the same results. Rechecked for continuity between A, B, and C lines. Really don't want to breadboard all three MUX chips, but I'm feeling like I may have to. Was so excited to have normal values earlier, that I failed to notice that the pin numbers were wrong. So back to the thinking board for me. Any thoughts as to what could cause one MUX to have a different pin mapping than an another? Wouldn't it have to be either swapped A, B, C lines or some swapped lines between the pots and MUX inputs? I'll recheck between pots and MUX and see if I can find anything out of place. And its consistently wrong on the pin mapping. Has the same issue whether I use the code for the reversed ADC channels or the original code. FWIW, this is at least the fun kind of puzzle that I enjoy. I'm not great at solving them obviously, but I could worse things to be confused by... edit - should add that everything works fine under MIDIO128 on SPI2. Pins are all reading perfectly and actually in the right order. Strange that the simple move to SPI1 seems to throw everything off on MUX 1...

Well... Just noticed something interesting. All of my errant data is coming in on the other module. The one I'm not using. Whatever is happening is way over my head, but I think I can just parse it out. With the module set to only use RC1 and the ribbon cable modified to also use RC1, all of the knobs return appropriate values for Module 1. One knob also returns its values for all of the other pins (except for itself) on Module 0. So I can just write my handler to ignore commands from module 0. It's a bit of a kludge, but it works for my purposes. It gets weirder though. The original AINSER64 code addresses the ADC channels in reverse order. u16 pin = muxed ? (mux_pin_map[mux_ctr] + 8*chn) : chn; // the mux/chn -> pin mapping is layout dependent //u16 pin = muxed ? (mux_pin_map[mux_ctr] + 8*(7-chn)) : (7-chn); // the mux/chn -> pin mapping is layout dependend The first line is modified as suggested by Antichambre to work around the fact that I wired it backwards from the original midibox wiring. The commented out line is the original code. Until now, I thought this was a bit of a kludge and fairly odd that MUX 1 was supposed to be wired to Chan 7 of the ADC. I'm assuming the problem I'm having is maybe the reason (or one of the reasons) why its wired as such. If I use the original code, I have no weird issues. The pin numbers are completely wrong, but thats to be expected. So I'm thinking that must be the issue. For now I'll just filter out the data from Module 0. I'll breadboard it with the correct wiring and see how it behaves though. Would eventually like to revise my PCB to have the RC jumper and just make things a little less sloppy. I still trusted the autorouter a bit too much when I made this one... Have since found the joy of manual routing. It's almost soothing... Thanks again for the guidance on all of this. This would be in the pile of sad broken things without this forum. A little nudge in the right direction is beyond valuable! As is paying attention to the original schematic and not "fixing" anything... Woops :)

Ok, so it turns out to be a rather clever trick that I've pulled on myself (at least I think this is the issue). MIDIO128 works great on SPI 2. But I need SPI 1 for implementation of Goom because of a conflict with the DAC. MIDIO128 exhibits the same problem when using SPI1 and J8/9. To use SPI 1, I was just simply changing line 42 in AINSER.H and all was well. Not exactly, but it avoided the conflict with the DAC at least. This morning I realized that I can improve things a bit by also changing the RC pin assignments a bit. My understanding from the comments in AINSER.H is that SPI 2 can use RC1 or RC2, but J8 can only use RC 1. But if I alter the code for the first AND second module to be assigned to RC2, all of the pots work. Except the one pot that spit out data for all pins, still does so. Closer, but not fixed. Unfortunately, I save tons of space and money by eliminating the CS jumper and hardwiring to RC2. So now its time to see if I can swap the lines in the ribbon cable and make it work on RC1. I'm a little confused as to why or how the CS line is causing this issue, but it seems to be at least related to the code and my "custom" board. I think I've learned to do a little improvising when copying circuits... That CS jumper would be nice to have right about now...

So its not the wiper, but that is indeed a clever possibility! And exactly why I love this forum. You guys always have ideas I'd never think of. Unfortunately, I've got 3 seperate control banks (8 pots each), and they each work fine on the other two MUXes and also exhibit the same weird behavior on the first MUX. Good thinking on the tutorial Antichambre - had forgotten all about the initial AINSER testing I had to do. Ended up just loading the MB128 Controller because it was handy and already has debug messages. Works fine... Each pot has its own pin and its own unique value. Albeit this is all when plugged into J19. My Goom implementation has AINSER running on J8/9 and its associated SPI. Goom uses the onboard DAC of the STM32F4 which uses the same SPI as J19. So I'm thinking the problem must lie in modifications I've made to the AINSER software module... Not sure off the top of my head, what could be causing this rather unique issue, but I'm going to start over again with the original AINSER code and slowly remodify it again. What's strange is that I could swear I had it all working. Then this problem popped up after setting it all aside to work on other projects. Of course that also means there are some major lapses in my memory, so who knows what I did to the code... Again, many thanks for the help - always good to have a few fresh eyes and brains to help regain perspective on this stuff. You all rock! Will report back shortly!

Sorry, should have been more clear - this is a self built module based around AINSER64. Just pared it down to 3 muxes and inadvertently did some pin swapping. Antichambre - I agree, this is strange. It feels so much like the ABC lines are not firing, but the are on the same node as the two functioning muxes. You're correct that there is continuity for all A pins, B pins, and C pins. The only thing I can possibly come up with is that this was my first PCB layout and I did a bad job routing these lines. Specifically on the failing MUX, the C line is almost twice as long as A or B. Other MUXes are all similar length lines. Is this enough to cause this issue? Yes, the AIN hook is called 8 times. I have a debug message in the main notifier and it gives me 1 message for each pin all with the same value. I'm as confused as can be. Later tonight I'll try to breadboard just a single mux on the first channel of the ADC. That is the other weird thing I did - I wired my ADC backwards. MIDIBox design calls for channel 7 as Mux 1, 6 as mux 2 etc. I went channel 0 as Mux 1. Had to change some code, but I don't think it should cause this kind of issue. I'll suss it out on the breadboard when I get a chance... Thanks for taking a look at this! Jeff

I've been implementing analog controls in the GOOM distribution for STM32F4, and thought I had conquered all of my issues with AINSER with much help from the forums. Got all my controls on panels now and wired everything up and have a whole new problem. Only one control on the first MUX chip works. I'm only using 3 chips and the other two work perfectly. I am almost positive that I tested the first MUX chip, but perhaps not... It's acting like the MUX isn't getting the ABC bits to advance through each channel, it just stays on the first channel and AINSER assigns that pot's value to all of the pins on that chip. But ABC on MUX 1 are receiving the same pattern as MUX 2 and 3. Tried swapping MUX chips around with no change. Same with ribbon cables. Really seems like it's a hardware issue, but I can't for the life of me find it. I'm out of time for the day, but plan to rebuild it on the breadboard and see if the problem persists. Could this be caused by software? I can't see anywhere in AINSER that would cause this kind of an issue. To be clear, there are 8 knobs (parameters 0-7). Only one knob generates values and it assigns that value to all parameters (0-7). I built my module with a bit of a weird pin mapping, so the working knob is number 6, but this is the one connected to X0 on the MUX. Which really makes it seem like the MUX just isn't advancing. I can change pin mapping and it still only reads that one knob, thought it does change the order in which it assigns pin values (matching the pin mapping). Any thoughts as to where to look for further testing? Thanks! Jeff

Confirmed, that was all that was wrong! Thank you so much for you help!

Ah that makes sense - I'm not using any other SPI's - I'll move to J8/9. Thanks for the help! Have been absolutely amazed by this platform and the forum - both are incredibly robust. Usually the answers I need are already in documentation, but when not this forum has consistently provided a whole lot of detailed information. Already thinking about doing another midibox project... Way too many possibilities... Thanks!! Jeff

I've moved the AINSER_Scan task back to app.c and SYNTH_Update back to APP_Tick just to make sure I'm not introducing any new issues of my own making, but am still with the same results. Are there any other applications using both the Audio DAC of the STM32F4 and an AINSER module? The only similar synths I could find in tutorials or apps didn't utilize AINSer. Posted the main functions at issue below. SYNTH_Init is where things seem to go wrong. Right now I've got the return MIOS32_I2S_Start commented out - this is the only way I can get AINSer to function and return values. Swapping it with return 0 allows the synth to function, but no AINSER controls work, nor does the pulsing link light on the module ever light. I don't think I have any SPI conflicts, but the SPI_Start sure seems to be the culprit. I'm a little over my head in this project - any thoughts on how to approach debugging this further? Thanks! Jeff #define PRIORITY_TASK_AINSER_SCAN ( tskIDLE_PRIORITY + 3 ) static void TASK_AINSer_Scan(void *pvParameters); void APP_Init(void) { // initialize all LEDs MIOS32_BOARD_LED_Init(0xffffffff); // initialize the AINSER module(s) AINSER_Init(0); // start task xTaskCreate(TASK_AINSer_Scan, "AINSerScan", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_AINSER_SCAN, NULL); // init Synth SYNTH_Init(0); } static void TASK_AINSer_Scan(void *pvParameters) { portTickType xLastExecutionTime; // Initialise the xLastExecutionTime variable on task entry xLastExecutionTime = xTaskGetTickCount(); while( 1 ) { vTaskDelayUntil(&xLastExecutionTime, 1 / portTICK_RATE_MS); // skip delay gap if we had to wait for more than 5 ticks to avoid // unnecessary repeats until xLastExecutionTime reached xTaskGetTickCount() again portTickType xCurrentTickCount = xTaskGetTickCount(); if( xLastExecutionTime < (xCurrentTickCount-5) ) xLastExecutionTime = xCurrentTickCount; // scan pins AINSER_Handler(APP_AINSER_NotifyChange); } } static void APP_AINSER_NotifyChange(u32 module, u32 pin, u32 pin_value) { // toggle Status LED on each AIN value change MIOS32_BOARD_LED_Set(0x0001, ~MIOS32_BOARD_LED_Get()); DEBUG_MSG("APP_AIN_NotifyChange_SER64(%d, %d, %d)\n", module, pin, pin_value); SYNTH_AINSER_NotifyChange (module, pin, pin_value); } s32 SYNTH_Init(u32 mode) { // use J10A.D0 for performance measurements MIOS32_BOARD_J10_PinInit(0, MIOS32_BOARD_PIN_MODE_OUTPUT_PP); // start I2S DMA transfers //return MIOS32_I2S_Start((u32 *)&sample_buffer[0], SAMPLE_BUFFER_SIZE, &SYNTH_ReloadSampleBuffer); return 0; }

I put the AINSER Task in Synth.c just to see what part of Synth_Init was causing the issue. Creating a task for SYNTH_Update was a futile attempt at getting things to work, before realizing that I2S_Start seemed to be what was causing the issue. Both tasks are at Priority 3. As long as I don't call MIOS32_I2S_Start, both AINSER and SYNTH_Update tasks work and process / update the control array.

I've been slowly working on integrating analog controls into the lovely Goom port for the STM32F4 and hit a bit of a roadblock. The AINSer64 module won't initialize (no pulsing link light). I can get it to work only if I disable the last line of the following function. Commenting it out and returning 0, allows the AINSer64 to do its job, the link led pulses and turning knobs send debug messages with proper pin numbers and values. The Goom synth also works just fine without any of the AINSER code present. Currently the AINSER64 is setup on J19 / SPI 2. s32 SYNTH_Init(u32 mode) { // initialize the AINSER module(s) AINSER_Init(0); // start task xTaskCreate(TASK_Synth_Update, "SynthUpdate", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_SYNTH_UPDATE, NULL); xTaskCreate(TASK_AINSer_Scan, "AINSerScan", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_AINSER_SCAN, NULL); //use J10A.D0 for performance measurements MIOS32_BOARD_J10_PinInit(0, MIOS32_BOARD_PIN_MODE_OUTPUT_PP); // start I2S DMA transfers return MIOS32_I2S_Start((u32 *)&sample_buffer[0], SAMPLE_BUFFER_SIZE, &SYNTH_ReloadSampleBuffer); } I2S is enabled in the config file. I saw that it can conflict with the SRIO SPI, tried setting SRIO_SPI to 0, with no luck. I wasn't sure if that applied here or not. Have tried this same code with ReloadSampleBuffer as an empty function, with the same results. I'm assuming the issue is somewhere in the I2S_Start function, but reading through that I didn't notice any obvious issues. Other AINSer apps like MIDIO128 work fine. I did have issues with the Jitter Monitor though - it just scrolls endlessly, returning empty results for all modules. I haven't delved deeper into that since the module was returning results without any issues outside of trying to implement it in Goom. Any insight into what might be happening here? Thanks Jeff

That's it! Thank you so much! Not sure how I missed it since the comment explains it, but I'm very appreciative for your assistance. Yeah, this was my first time creating a PCB - definitely a learning experience. I've been surprised at how well everything has actually worked given my lack of experience - the documentation and tutorials for MIDIbox have been amazing. Thanks Jeff

Have been working on adding physical controls to the Goom synth (so thrilled this is ported to MIOS!), and noticed that the AINSER64 module appears to scan each MUX in reverse order. I built a small version of the AINSER module (3 mux's) using channel 0-2 of the ADC, and realized I should have used 5-7. Looking through the code for AINSER.c and mios32_spi.c and I can't figure out why it's scanning channel seven first and assigning it pins 1-8 and so on. It's not a huge deal for this project (I can just offset my pin values), but was wondering if anyone could shed any light into what's happening here. From looking at the schematics for the AINSER64 module, this appears to be the planned mode of operation as J6 connects to channel 7, J7 to channel 6, etc. Thanks for any help anyone might be able to provide. Jeff