jackchaos

I'm finishing off the last bit of electronics for my panel and I've decided to use 1 encoder as a menu data wheel. My encoder is from SMASHTV's site and I'm confused on the wiring for the 3 pins. Below is an image of the encoder: Encoder wiring diagrams suggest 2 of the pins connect to a DIN module and 1 of them to VS. Does it matter which one goes to VS?

I've added more photos of the new additions to the development setup. I've also began WIKI-fying my project here: http://www.midibox.org/dokuwiki/doku.php?id=jackchaos

Your right. And if your app is wacking everything out, it may look like MIOS is is broken, especially if your looking at a garbled LCD, but you should still be able to resend your app.

Vedge Take a break from uploads and carefully look at your core module. Make sure there are not electrical problems and check out the MIDI in/out wires. When you turn on the PIC, it sends a wakeup/upload request out the MIDI out port. You should be able to see it in MIOS Studio.

I've thought I had fried my PIC during a HEX upload many times but I've always found my way back and recovered. Thorsten has provided some safeguards to keep these things uploadable. I'm assuming you're using MIOS studio to upload the HEX. I would suggest you restart MIOS Studio, Enable [wait for upload request], then turn on your PIC. If you get nothing after 10-15 seconds, try disabling [wait for upload] and send via manual mode. Make sure your application isn't hosing your PIC, try an earlier version or one of TK's sample applications.

Thanks David, After looking at it all day and a nap and a movie, I discovered a jumper was missing on the far right of the DIN: http://www.avishowtech.com/mbhp/mbhp_dinR2.html

Pardon the ASCII graphics below. I've added a second DIN to my project... only 7 of the pins are needed right now. I've attached the j2 of DIN1 to j1 of DIN2 as shown below. I've double checked my cableing between the two (j2->j1) None of my buttons are responding to it. Using the scematics here as a reference: http://www.ucapps.de/mbhp/mbhp_dinx4_32buttons.pdf I've shorted the ground pin g(vs) to pin x(d7) of j3 on the top left of DIN2 and my my app displays it as pin 63 but the other pins do not respond at all. I expected after pin 32 to show up... not 63. None of the other pins respond at all either. I've check for shorts and breaks in the circuit and it looks fine. Can anyone suggest a way I can troubleshoot this DIN? P.S. I'm running MIOS 1.9 with a custom C application. As always, Thanks. P.S. I just discovered this on the WIKI: http://www.midibox.org/dokuwiki/doku.php?id=din_module from core DIN1 DIN2 |-----------------------------------------| |------------------ _____vs_|__o ..... ..... ..... ..... o_|__vs___|_o gx... ..... _____vd_|__o o_|__vd___|_o _____s1_|__o o_|__s1___|_o _____sc_|__o o_|__sc___|_o _____rc_|__o ..... ..... ..... ..... o_|__rc___|_o ..... ..... | | | |-----------------------------------------| |-------------------

declare the variable 1st, then assign a value like so: unsigned char button_state; button_state = 17;

I've been watching my code block size increase steadily as I work on my project and I'm now aware first hand of how assembler can be much more efficient than what a compiler can do. I wanted to share a method I use to determine if my C optimizations are reducing the code size. If you look inside the project.map file, at the top of the file look for the name of the function you're working on like this: S_main__Update_LFO_LED_Status code 0x006304 program 0x0000fa On the end is the size of the function in bytes: 0x0000fa = 250 bytes This number will change when you make changes to this function.

Especially the combination of array + structure as parameter Well, now at least I know where to look when this happens again. I'm wondering if the compiler will always give me the message "MOVFF PREINC1 ... used only once" when this problem comes up? If so, then I can work with that and be sure to work around it like the WIKI suggests. I was able to work around my error mention in my 1st post on this topic by by moving the code between the case: break: into a function of its own. About the memory test post: I forgot to include that I initialized the arrays at 256 elements each: #define MEMSIZE 256. I got memory errors after initializing the 3rd array of 256 elements. I'm aware of the large array issue and I've been working around it. I didn't need to know its available RAM... I wanted to know how much RAM I had available after MIOS and my application were loaded and running. I'll definitely need to go through all the source and make the necessary changes to avoid the compiler and array errors... I don't want to spend another 4 hours tracking down things like this :). Thanks for the help!

I found that wiki earlier today but there isn't a lot there to describe the problem. Am I right to believe it's an unpredictable/intermittent problem?.. because I do access variables in arrays accross functions elsewhere. I was about to post a question: "How can I tell how much memory I have available?" or "Will the compiler give me an error when I use up all available ram?". Then I realized I could test this myself. in main.c I initialized these one by one: unsigned char memorytest1[MEMSIZE]; unsigned char memorytest2[MEMSIZE]; unsigned char memorytest3[MEMSIZE]; then in Init() I did this: unsigned char i; for(i=0;i<MEMSIZE;i++) { memorytest1[i] = 2; memorytest2[i] = 2; memorytest3[i] = 2; } memtest1 and 2 compiled fine but after adding memtest3 I got: So this tells me I have at least 512 bytes of available ram according to the compiler?

Edit: My ISP is terrible so I've created a Flickr account instead. You can see the set there: http://www.flickr.com/photos/19562549@N00/ I've made a lot of progress on my project. Chaos Matrix is a knobby programmer for my Matrix 1000. I have most of the electronic components built and I'm waiting on the last order from SMASHTV to finish the rest like the 5point Tracking/Reshaper, Ramps & Portamento Controls, Matrix Mod, and Patch Selection section below the LCD. What you see in the photos below is a fully functional programmer for what was until this point... a pain in the ass to program. The Oberheim Matrix 1000 is one of the the last analog synthesizers Oberheim built before they went away. It has 6 voices, 2 oscillators per voice, 2 LFOs, 3 ENVs, and a VCF per voice. It also has sophisticated modulation routing functionality making it more like a modular synth. I've already started designing the front panel and I look forward to getting to that point. Right now, cardboard boxes make great containers for prototyping because its so easy to cut holes. I also plan on upgrading the LCD. The 2x16 I have is very restrictive and the new 2x20 I got from Smash looks better... I've not wired it in yet. One of the extra features I want to do once everything else is finished, is to implement visual feedback in regards to Matrix 1000 patch parameters that are represented by LEDs on my control surface. I plan on dumping all the necessary patch data from the Oberheim (~64k) to a couple of bankstick chips, and when a patch change is made on the programmer, read the patch values and update the LEDs on the panel. For example, if the Pulse wave is enabled on DCO2 and oscillator sync is enabled on DCO1, I want the LEDs to update when I change patches... The Matrix 1000 has 800 preset voices. Here is a shot of the Matrix 1000 Analog synth. The left side is where the DCO controls are at. At the top is where I select the DCO to edit. in the middle are the shared DCO1/DCO2 controls. On the bottom, is the DCO Sync enable button, Detune, and DCO1<->DCO2 Mix pot. On the right is the lowpass filter. From top left to bottom right: VCF Resonance, unused, VCF Cutoff to ENV1, VCF Cutoff to Aftertouch Cutoff, Modulate Cutoff to LFO Enable, Cutoff to LFO Amount,Cutoff to: Portamento, Kbd, PBend, Modwh FM Amount, FM to ENV3, FM To Velocity On the top are the envelope controls. The 3 buttons at the top select one of the 3 envelopes. The controls on the right are for the 2 LFOs. Whats great is when I toggle between the ENVs, the LED's on the buttons will light up based on their last edited status. The button that toggles between the 7 LFO waveforms also blinks at the speed of the LFO rate thats currently set. Obviously this is a close proximation of the actual rate but it gives enought visual feedback as to what's going on with the patch. The 3 knobs on the top right are the VCA controls. This is the inside of the panel on the right. I got a lot more efficient by the time I build these components. The components in the left panel were built last year and are a mess. All my parts are from smash. I used the boards as templates to organize all the controls.

Earlier today a spent a long time trying to figure out why everything in my application started to go haywire. I was given a "...used only once" error when compiling and at the time I was unable to find the problem. Whats worse, my application started behaving wierd. I feard that I may have reached my RAM memory limit so I began looking for places to optimize. I was able to completely remove a 32 element array and the compiler message below went away. From then on, everything started to work again unit I saw the error again. This time, I was able to pinpoint the line in the source that produce the error... but I cannot determine why I get the error. Below is the output of make.bat with the compiler message: C:\MATRIX~1\MIOSAP~1\MATRIX~1>make Makefile generated. Makefile.bat generated. Assembling MIOS SDCC wrapper ========================================================================== Compiling pic18f452.c Processor: 18F452 ========================================================================== Compiling main.c Processor: 18F452 MOVFF PREINC1, r0x00 pcoderegs.c:367: removing reg r0x00 because it is used only once ========================================================================== Linking project ========================================================================== Converting to project.syx Block 003000-0033FF allocated - Checksum: 1A Block 003400-0037FF allocated - Checksum: 22 Block 003800-003BFF allocated - Checksum: 55 Block 003C00-003FFF allocated - Checksum: 54 Block 004000-0043FF allocated - Checksum: 1D Block 004400-0047FF allocated - Checksum: 04 Block 004800-004BFF allocated - Checksum: 24 Block 004C00-004FFF allocated - Checksum: 24 Block 005000-0053FF allocated - Checksum: 1D Block 005400-0057FF allocated - Checksum: 2C Block 005800-005BFF allocated - Checksum: 2B Block 005C00-005FFF allocated - Checksum: 2D Block 006000-0063FF allocated - Checksum: 3E Block 006400-0067FF allocated - Checksum: 5A Block 006800-006BFF allocated - Checksum: 6C Block 006C00-006FFF allocated - Checksum: 7D ========================================================================== SUCCESS! Here is the segment of code that created the error. case 2: // LFO2 Select Selected_LFO = 1; // set the LED MIOS_DOUT_PinSet(ButtonConfigMap[pin].dout_pin, DIN_STATE_ON); // <---- THIS LINE //MIOS_DOUT_PinSet(ButtonConfigMap[pin].dout_pin, (MIOS_DOUT_PinGet(pin)== DIN_STATE_ON) ? DIN_STATE_OFF : DIN_STATE_ON); // toggle the other buttons MIOS_DOUT_PinSet(ButtonConfigMap[0].dout_pin,DIN_STATE_OFF); Update_LFO_LED_Status(); break; Now, if I comment out that line, and uncomment the line below, it compiles without the error. P.S. I'll be posting some photos of my work in progress today in the HUI forum.

I understand that. But does it matter if I pass a decimal or a hex?

What is the difference of writing this: MIOS_MIDI_TxBufferPut(0x06) and this: MIOS_MIDI_TxBufferPut(6) I notice this in looking at other peoples source that hex and decimal notation is used interchangably. P.S. I have 80% of my hardware completed and mounted in 2 cardboard boxes so I have something to write software to before I decide on the front panel design. It's very exciting to see my project come together and even more so when I can almost tweak every audible characteristic of the matrix sounds with my knobby programmer. I've ordered some more parts from SmashTV and those will allow me to complete the 5 point tracking/reshaper, ramps and portamento section of the front panel. I've also ordered a larger LCD (2x20) which I havn't added yet which is part of the final electronic component, the programmer section.

Thanks. I was worried that by declaring it [17] I was just hacking a solution... which is not what I wanted to do.

I'm at work right now and I wanted to ask about a problem I had this morning. I'm defining my pot config in structs like so. typedef struct s_pots { const unsigned char description[16]; const unsigned char param1; const unsigned char type; <etc..> } pots; const pots PotConfiguration[32] { //description param1 type <etc...> {"12345678abcdefgh", 16, 2, <etc...>}, {"12345678abcdefgh", 15, 2, <etc...>}, }; Later, the description is being passed onto MIOS_LCD_PrintCString() like so. MIOS_LCD_PrintCString(PotConfiguration[pin].description); I get an error when compiling for the 'description' const having too many elements. the error goes away if I define description with 17 elements like so: const unsigned char description[17]; I'm using a 2x16 LCD screen and it seems I should define the descriptions as being 16 in length. I wipped out my old 'C' book and it looks like strings should have an additionalnull terminator. The book showed this: '\0'. Is this my problem? Do I need to make my description one extra char longer? And if I do, how do I pass a null or '\0' at the end of the string in my config above? Thanks for everything... again.

stryd I wasn't trying to set up ACSim... I just wanted to use Code::Blocks for coding and I tried to break my code up in separate files and I buggered it up. I'm back to notepad now but I will try again this weekend. Thanks

ac I first tried to follow stryd's instructions on the wiki by incorporating an existing application into the project. At first it would work fine until I attempted to split my code in separate *.c and *.h files. From there I was having difficulty compiling without errors. I will give it another go-around and If I'm not successful, I'll provide better descriptions of the errors. Thanks

I'm having a mess of a time using Code::Blocks with my MIOS C application. Up to this point, I've always used Notepad++ and I want to try something different. One of the errors I get when I try to compile is this: in cmios.h "...syntax error: token -> '__wparam..." starting at line 101 which contains: "extern void MIOS_MIDI_BeginStream(void) __wparam;" I get a lot of these but it stops at 50.

"....Multidimensional arrays just won't work at all unfortunately" You mean, they don't work for arrays larger than 256? Or at all? But for smaller ones, they are fine.... especially for const unsigned char myarray[32][4] or some such. .. I see. I re-read this entire thread. Stryd needs data storage for real-time, in memory stuff. I worried that my flash stored constant multi-dimension arrays are a problem. I see they are not.

th0mas You posted the code below and I'm trying to follow the meaning of this thread. This looks interesting! Can the SDCC compiler handle this for the PIC? Is this a better way to handle things than a simple multi-dimensional array? Regards

unsigned char two_dimensional_array[NUM_POTS][NUM_OPTIONS] The array can only hold one value type. I'm storing all my config here and every value is a char. I want the option to scale all the update intervals so the interval is later multiplied by another number which is higher than 255.

Stryd When I woke up this morning, I was able to test my solution for this problem after installing Code:Blocks and the nice library that comes with it. The solution seems to work like a charm; each pot I confgured to behave differently in regards to when and how often it sends a SYSEX. For the slow pots, they only send SYSEX on the first movement and on the last. Below is the code I wrote to make this happen: void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { . . . // when a pot is 1st moved, this flag isn't set, so the first move gets transmitted // and all other subsequent pot movements do not. if(!app_flags.TRANSMIT_SPECIAL_PARAM) { Transmit_MIDI(pin, value); app_flags.TRANSMIT_SPECIAL_PARAM = 1; MIOS_LCD_CursorSet(0x46); // give a visual that a pot is being moved MIOS_LCD_PrintCString("-"); } . . . } and later in: void Tick(void) __wparam { unsigned int interval; // We set the special parameter when a slow pot was moved in AIN_Notify // We didn't transmit then but we will after this counts to max if(!app_flags.TRANSMIT_SPECIAL_PARAM) return; // At this point, app_flags.TRANSMIT_SPECIAL_PARAM is set to 1 // the pot config lookup table is made of unsigned chars, so we have to cast the UPDATE_INTERVAL value to an INT so we can multiply it to a larger number interval = (unsigned int)POT_CONFIG_MAP[last_ain_pin][POT_CONFIG_UPDATE_INTERVAL]; // we transmit the last pin values here only when we've counted high enough if(PotUpdateCount >= (interval * 500) { MIOS_LCD_CursorSet(0x46); // display a visual of when the SYSEX transmits MIOS_LCD_PrintCString("*"); // app_flags.TRANSMIT_SPECIAL_PARAM = 0; Transmit_MIDI(last_ain_pin, last_ain_value); PotUpdateCount = 0; } PotUpdateCount++; } I spent 5 minutes moving, listening and watching the MIDI monitor while moving the pots and I like what I see. The high resolution pots sound good and the pots that need slow transmissions are working with no stuttering or note hanging. I'm very pleased!

I have a lookup table filled with unsigned chars that define the config and behavior of each and every pot. One of the items is a refresh interval that later gets multiplied by 500 (this may change later). This is the only way I can see how to do it... and yes, I'm doing a multiplication the bad way (a = b*c). I'm at work right now, but from what I see in this document. If I change my 500 (above) to 512 and do a bit shift like so: a = 2 << 9; // a is 1024 or a = 5 << 9; // a is 2560 This would be the equivalent of: a = 2 * 512; or a = 5 * 512; If this is true, I've solved that problem and I can make the changes when I get home. Thanks again! ( audiocommander, yes. I meant 'a = 2 * 512;', It's corrected above. Thanks. )