Thomas

I cannot interpret this errors, but in your function are at least two: Rewrite the functionheader to void send_word(unsigned char* stuff, unsigned char length) 0. _wparam is not needed (but this is not an error), 1. Arrays in C are assigned to function via pointer (to the first element) 2. SDCC does not allow arrays longer than 256 element, nor does it allow 16bit-Integers as index for arrays. Look for an older thread I started. I noticed this too. SDCC is not ANSI-SDCC, think about it as a more or less C-Style programming language. And avoid 16bit-Integers whenever possible (if you don't need numbers above 256 or below -128)! It would blow up your resuilting asm-code significantly (up to doubled size).

Hallo! Is it possible to program midiboxes via MIDI in an application like this http://www.ucapps.de/midibox_link/tunnel4.gif ? Since there are IDs I thought it should be possible, but it seems not to work. Greeting Thomas

Why? I programm my own application. In C. I think that's much better that reusing the old mb64 code. MIOS and the ability to use C is an important improvement over rewriting mb64 code, like I started to do 3 years ago. In my opinion thats one of the great advantages of the whole midi-box project: extrem costumizating...

I guess that makes no difference. Look at the resulting asm-file!

Thanks, I will try it. I've overseen the MIOS_LCD_Cmd function.

Hallo stryd_one! I'm not sure at the moment, but considering http://www.sprut.de/electronic/pic/assemble/befehle.html#rrf the high bit is filled with the carry flag on right shifts. So you have to mask out the higher bits when you get te higher nipple, too. unsigned char highernipple = (value >> 4) & 0x0f; unsigned char lowernipple = value & 0x0f;

Hallo! I need some input for programming. I want to write a routine for editing same valus, the midi events of a button or poti. A button has 4 midibytes (controller command, value1, valueOn, valueOff, type) (if you now the PC1600 from peavey you'll know what I mean) it's looking like this on the display (T==toggle): ---------------- old: BE017F01T new: BE017F01T ---------------- Now I want to add a cursor, like ---------------- old: BE017F01T new: BE017F01T - ---------------- (indicating that you edit the lower nipple of the second midi byte) My current solution is: ---------------- old: BE017F01T new: BE0>1<7F01T ---------------- But this looks ugly. Any Ideas?

Hi Thorsten! My faders move with half speed like yours. But I have no video camera... ;) And the tc4427s are getting hot after 4x up and down. Don't know if this is normal or dangerous. The BAT54s shottky diodes should work. What do you think about the pin compatible mic4427 drivers? I will check this out this week. Today I did some debugging of the other board and found two shortcuts. And completed the software with snapshot functionality and noticed a bug in the event saving routine for bank >1. etc.pp. Theres a lot to do... BTW. the code upload hardware bug in the other thread seems to be solved. Maybe it was a loose power connection. No problems anymore, even with the increased code.

Hi Thorsten! Do you know how much current the motors actually need? In the datasheet of ALPS faders http://www3.alps.co.jp/WebObjects/catalog.woa/PDF/E/Potentiometer/SlideMixers/RSN1M/RSN1M.PDF only a maximum of 700mA is given. That seems to be too much. The maximum output current Imax of TC4427 is 0.270A (DIL) / 0.216A (SOIC). Imax = sqrt(Pmax/10Ohm).

Hi Thorsten! The diodes are not in the wrong direction, but I use BAT54S. (http://www.fairchildsemi.com/ds/BA/BAT54S.pdf)

Hi Thorsten! Some additional questions: 1. It takes more than 1s that all 8faders move from 0 to max. Two faders need nealy 2s. In the MF description you list the valus (voltage, duty cycle) for ALPS fader (the first one). But I need more voltage and higher duty cycle. 2. The TC4427s are getting relatively hot during working. Normal or not? I cannot use my old MB64 at the moment for comparison.

Success. (with the 1k modification) :) First half (i'm runnig out of BAT54S and TC4427) of the second (I put the first one on the side. because of the code uploading trouble) motor fader board are running. A little bit slowly but that's only adjustment.

Hallo Thorsten! I turned the 240Ohm 90°, scrached the circuit path and soldered a 1k R over the scratch so that it is in chain with the 1k poti. I could adjust the voltage now from 6.4V to 10.5V. The datasheet says 3.5mA is a typical mininal load current. So I thought the 1.24k is workload enough. The thing that confuses me is that the formular given in the datsheet says that my 6.5V are consistant with the theory... ???

I forgot: Uin is 12V.

Hi Thorsten! Yes, I get only 6.8V at the LM317 output. (no H-bridges installed yet) The formula can be found at http://www.elektronik-kompendium.de/public/schaerer/ureg3pin.htm (Bild3) or in the data sheet itself http://focus.ti.com/lit/ds/symlink/lm317.pdf (page7) Iadj is 50uA. 1kOhm * 50uA = 0.05V -> neglectable.

Hallo! Looking at the motorfader schema im a little bit confused. How do I get 8V when R2 is max 1K? Uout = 1.25V*(1 + R2/R1) Uout = 1.25V*(1 + 1000/240) Uout = 6.5V Shouldn't R2 (the poti) be 1.5k ? Just wondering, Thomas

Thank. Good ideas. I didn't think on the debug interface... Btw. the oter problem with damaged code seems to be solved. Don't know why and how. I only startet with a simplier application by commend some parts out and step by step decommand them. And I use a new power connection where I could messure U and I. Btw. flashing uses a little more current, but only some mA.

I cannot switch the ICs...the only thing I can do is to remove them destructively. (SO-package directly soldered) That's why I ask before I destroy them.

Hallo! Board debugging no. 2354... I have 5 DIN - shift registers. That means 40 Button and 40 LEDs. (All 40 LEDs work.) BUT: on the 3th shift register only Button 0-5 work and on the 4th only button 7 (pin 1F(Hex) 31(dec)) on the 5th DIN-shift register only Button 7 (pin 27(hex) 39(dec). Electrical connetions seem to be ok. No short cuts or broken connection. Any Ideas how this can happen? Is shift register 3 damaged? Other possibilities before heating the soldering iron and destroy a 74HC165?

Btw: If you ever looked at a *.asm produced by SDCC you would know that the file is very well documented.

Hi OrganGrinder! The problem is that we not program on a "normal" CPU but on a very restricted controller. And SDCC is not ANSI-C. So it is worth to look at assembler programming of PIC (e.g. in german www.sprut.de) and see what's really produced by the compiler. I can be really eye-opened. I don't think it "drive them away". It's only another option.

Hi! Some additional words: 1. since array can have only <=256 elements a one dimentional array is better because the ("pointer") arithmetic can be calculated in 8bit-Integers ("unsigned char"). But every multiplication has a 16bit-result, so theres overhead to handle those 16bit-values in more steps. And with two dimentional arrays the whole calculation is done with 16bit. 2. I'm not shure but I can imagine that higher leve data structures like links lists or binary trees have more overhead than simply access arrays with <=256elements directly. Even if you have to calculate the address. Each element of a linked list needs at least 2bytes (data and pointer). But sure: it depends on your needs. Maybe a search could be improved. But you pay with RAM if you want more speed. 3. Sometimes its better to replace mulitplication by addition: --------------version 1--------------- unsigned char result = value1 * value2; -------------------------------------- vs. --------------version 2---------------- unsigned char result = 0; unsigned char i; for (i = 0; i < value1; i++) result += value2; -------------------------------------- While version 2 looks more complicated it produces less assembler code! If value1 is small (e.g. 2) it's even faster. 4. Always look at te *.asm out if you not sure.

Hi! As we pointed out in the other thread array with more than 256 elements are a bad idea because they will not be compiled (linked) directly with SDCC and the linker. unsigned char myArray[256]; // will work unsigned char myArray[257]; // will not be linked! And the same problem is with multidimensional array: unsigned char myArray[64][4]; // will work unsigned char myArray[64][5]; // will not be linked! So it would be a good idea to use multiple one dimensional arrays. //instead of myArray[2][4][256]; unsigned char myArray00[256]; unsigned char myArray01[256]; unsigned char myArray02[256]; unsigned char myArray03[256]; unsigned char myArray10[256]; unsigned char myArray11[256]; unsigned char myArray12[256]; unsigned char myArray13[256]; if it is possible. There is a big difference if you use constants or if you calculate the indices during runtime. I tried out: ----------- version one ---------- unsigned char otherArray[2]; //to prevent contants that will be optimized unsigned char myArray[3][4]; .... myArray[otherArray[0]][otherArray[1]]; --------------------------------- ----------- version two ---------- unsigned char otherArray[2]; //to prevent contants that will be optimized unsigned char myArray[12]; .... myArray[otherArray[0]*3 + otherArray[1]]; --------------------------------- ----------- version three ---------- unsigned char myArray[3][4]; .... myArray[1][2]; --------------------------------- Version two is produces only 2/3 of the assembler statements of version one. Version three (with constants) will be optimized to myArray[5];

The MIOS version doesn't matter! And I had a little while ago a experience that uploading a precompiled applications did not work as well. After erasing the PIC and after I reprogramming. (each step with verification). And length of code also correlations with complexity. It need not to be a wrong code but only a big code if I'm right. But I haven't found the current consumtion during flashing in the datasheet yet. I will test it on saturday, so we don't debug in the wrong direction. Schönen Männertag noch. *prost*

Hi! Have you checked the code by uploading it? I have another idea, because some years(?) ago I had a similar problem. Does the PIC need much more energie while flashing? So much that the voltage drops and the PIC resets during upload? I think I have to check this, too. Although all problems started after uploading the modified MIOS... But correlation is not causality...