Building How-to » Bend Matrix » Still no luck with firmware issues.
| Still no luck with firmware issues. [message #2641] |
Sun, 06 March 2011 04:13  |
 smrl
Messages: 23
Registered: February 2010
|
Junior Member |
|
|
Hi. I've taken now to hacking the firmware and am trying to figure out what is going on. Still cannot change my matrix mode. From what I can tell so far, DUALMATRIXMODE always == 2.
change_dual_matrix_mode_down is reported by the compiler as defined but unused.
../bendmatrix2.c:399: warning: unused variable 'change_dual_matrix_mode_down'
also complains about inttimerreached if I have MATRIX_VERSION defined as TRIG8.
Have tried messing with defining GREEN_IS_BEATS under different conditions. That doesn't seem to help much. Still don't know what that's supposed to do, but it certainly looks like it only applies (or once applied) to the MATRIX_VERSION==JOYTOY_saki
In 20100420_code, bendmatrix2_triggers_nomoment.hex displays 4-d upon startup, cannot change by either method. Shouldn't this only be the case if GREEN_IS_BEATS is defined (which I believe means that MATRIX_VERSION==JOYTOY_saki)
Totally stumped. Been at this for too many hours.
Also, the tempo is not at all synchronized with the changing of patches... This has been the case for a long time, possibly in all the firmware versions. Any idea why that might be?
[Updated on: Sun, 06 March 2011 04:17]
|
|
|
| Re: Still no luck with firmware issues. [message #2648] |
Thu, 24 March 2011 12:01  |
dann
Messages: 829
Registered: December 2002
Location: Austin TX |
Senior Member |
|
|
Hmm. well pretty much unless I have a specific reason, I keep MATRIX_VERSION set to AH232.
GREEN_IS_BEATS is a feature I wanted to do with making the green section flash multiple times for each step, but I never finished the code so I don't really know what it will do if you enable it.
OK so I'm going from the 20110122 folder, freshly downloaded from the commonsound wiki:
As long as NO4x8MODE is not defined (make sure that line is commented out in bendmatrix2.h), when the BM first starts up, DUALMATRIXMODE is set by the read_dualmatrix_mode() function (bendmatrix2.c line 466) which reads your matrix mode out of EEPROM (note that depending on how you have your fuses set, burning flash to the program memory might erase the eeprom, thus resetting your matrix mode setting).
Next, pin PA3 is read via the READDUALMATRIX macro, and if it's high, DUALMATRIXMODE is flipped from 0 to 1 or vice versa (line 473) and the new value is stored in EEPROM (line 475, save_dual_matrix_mode())
Then the text for the current matrix is displayed and the main loop begins.
At the top of the main loop it listens for SHIFT and PLAY and SAVE all pressed at the same time. When that happens it sets the change_dual_matrix_mode flag to 1 (line 508), which is just a flag used so that we only change the MATRIXMODE on the very first time the keys are detected being down. When this happens, it does the same thing as in the startup sequence: it sets DUALMATRIXMODE=1-DUALMATRIXMODE (line 513) and stores the new value to EEPROM, and displays it.
All of the above main-loop code is only executed if #define NO4x8MODE and #define NOLIVEMATRIXMODESWITCH are both commented out in the .h file
So I'm wondering now if your mode is set to something funny in EEPROM, since it displayed 4-d? Maybe try erasing the EEPROM.
Also, that's odd that change_dual_matrix_mode_down is reported as unused... It's only used at the top of the main loop, but I'm wondering if you have NO4x8MODE or NOLIVEMATRIXMODESWITCH #defined? If you did, then I would understand the compiler's warning. The way wrote it, even if they are defined as a blank or zero value they will still show up as being defined.
And finally, the complaint about inttimerreached is something I always have gotten, it's because the compiler isn't understanding the volatile flag for the tmrms variable, or something like that. Not an actual problem.
Ok, hope that helps. Oh, what do you mean by the tempo being synced with patch changes?
|
|
| | |
| Re: Still no luck with firmware issues. [message #2653] |
Mon, 04 April 2011 15:05 |
smrl
Messages: 23
Registered: February 2010
|
Junior Member |
|
|
My 8x16 functionality is just pending code, really. I installed parallel ports with all of the pins brought out to the port. Some of the devices that I've built already have unused connections (they have a "bending matrix" which is 8x16 in size) so all I need to do is write the code. Currently I have a manual 4p25t switch (pulled from a parallel port switcher) designed to do the same thing but this is not ideal for several reasons, primarily that I need to keep my signal path as absolutely short and shielded as possible for video bending to work as I'd like. (i've even considered embedding MT8816's into the processors and then just running power/data to the devices - which probably needs buffering/line-driving the data signals)
In an ideal world I could have an interface which shows me the entire matrix as an LED display. Lacking that, the next best thing would be for the entire matrix to be represented internally with the code affecting the entire thing, and a 4x8 'window' into the state of the matrix.
Lacking that, however, and avoiding a major overhaul of code, I could have just the current 'view' of the matrix updating. The question, I suppose, would be whether or not to release the switches in the current submatrix upon switching to a new one - i.e. whether to keep the switch state persistent beyond the currently selected submatrix. (I think all that's necessary here is to not toggle the MT8816 reset pin - gotta find references to that in the code...) Might be interesting from a bending perspective, but it's also possible to completely lose track/lose control over one's bends. And it's really hard to manually reset/clear the matrix in certain modes, which has been discussed before.
But yeah. Regarding the tempo, it's this drift that makes it so much less useful - because the patches are still drifting/phasing wrt the midi clock.
Could something be done at ~line 99 of midi.c? Perhaps setting a var somewhere that inittimerreached() could check? I'm unfortunately just doing a cursory look at the moment because i'm not near my bend matrix or my dev box
thanks again. I made an effort to come visit you in chicago this weekend! alas, i couldn't get in 
j
|
|
|
| Re: Still no luck with firmware issues. [message #2661] |
Fri, 29 April 2011 10:03 |
dann
Messages: 829
Registered: December 2002
Location: Austin TX |
Senior Member |
|
|
Hey... Probably to make the tempo lock better, I would move this code from midi.c to the ISR(USART_RXC_vect) routine in uart.c (which is the interrupt that's run when data is present on the UART):
if (midi_in == 0xF8) {
short maxclocks=24;
if (midi_mode==6) maxclocks=48;
if (midi_mode==7) maxclocks=12;
if (++clocks_recvd==maxclocks) {
clocks_recvd=0;
clockreceived=1;
seven_seg[3]|=BIT(1);
} else if (clocks_recvd==6) seven_seg[3]&=~BIT(1);
}
midi_in should be set to *data or uart_buff...
Now that I'm looking at it, I'm not sure why I had the midi clock LED (seven_seg[3]) flash after 6 clocks received... it should be maxclocks or 0? That might be part of the problem, if the light is flashing out of phase with the shifting.
Another approach (perhaps both) is to set the matrix being updated on a timer interrupt. Probably do_play_mode() and then the /****OUTPUT SWITCHES****/ section of main() would get called from an interrupt. Right now the time between steps is variable, as it depends on how much processing has to happen in the main loop... so there's a bit of jitter. An interrupt would reduce this a bit (but there's still jitter in interrupt timers because we have several interrupts running!)
___
As for multiple matrices, :doh: I've promised to write that code for you several times now... ahhhh...
Jitter/latency will go up a lot if we are running 4 matrixes. But anyways let's try. We would need to make some of the *matrix variables an 8 element array of uint16_t, instead of 2 element (each element is 16 bits, which is a 4x4). It would need to be the ones that actually combine to produce switch_matrix (bendmatrix2.c:654), which are these:
uint16_t matrix[8]={0,0,0,0,0,0,0,0}; //the current page from the stored matrix array s_matrix
uint16_t midimatrix[8]={0,0,0,0,0,0,0,0}; //from midi notes recvd
uint16_t latchon_matrix[8]={0,0,0,0,0,0,0,0}; //"SAVE" layer
uint16_t latchoff_matrix[8]={0,0,0,0,0,0,0,0};//"CLEAR" layer
Also we need to make the stored matrix array bigger:
uint16_t s_matrix[16][8][8];
Output_matrix will stay a [2] element array beacuse that's just the display. So on lines 673-674, we'll need to assign output_matrix[0] and [1] to the current two visible portions of switch_matrix.
Some finagleing will need to be done in inputs.c read_buttonmatrix() to keep track of which matrix we're in and assign button pushes to that one only. Also things like bank changes will need to be figured out (whole matrix? or current quadrant).
And I guess we'd need a global variable to keep track of the current quadrant. How about
uint8_t cur_quadrant;
And then in read_buttonmatrix() we can test for all four corners being pressed at the same time (or some handy button combination) and then go into a mode where we wait for one of the corners to be pressed again... which then sets cur_quadrant to a value 0-3.
Well, that's all my ideas for now (and before 9am!) Go over it and get me back, maybe we can actually make this happen (and watch that poor mega chip buckle under the load, heh heh...)
Aw, we'll have to catch up next time I'm in chicago. Or if you're in austin... great town!
|
|
|
Goto Forum:
Current Time: Fri May 24 21:17:19 EDT 2013
|
Members
Search
FUDforum help
Register
Login
Home
E-mail to friend 
