avogra

err, does this app care about encoders at all? the name at least contains explicitly ain, din and dout, no encoders there. -- just looked into the source and the corresponding function is empty, so no encoders :( you could try "enc_speed_v1b" under troubleshooting instead, to test the encoders. still you have to setup the encoders in mios_enc_table.inc. what spongebob suggested works in C-Apps only, this one is in assembler. which application do you want to use in the end? --- oh, i should read more carefully ^^ so you want to adapt the ain63_din128_... to also handle encoders? mb64e is in assembler, but you can look through the examples in ucapps.de -> MIOS - C Interface. There are some coding examples for encoders. ok, i hope one of the answers is what you wanted to know :P Good Luck :) Alex

hehe, i know that curse :P took me 2 weeks to come up with the "perfect" menu-engine in order to have tidy and small code. now i'm almost finished, my code is a real mess and the app with only the menu takes up 10kB :o yet, it could have been worse and i'm really flexible with the menu, so it still paid :) back to topic: i just glanced into the datasheet from st-microelectronics and found a little diagram of the output-stages on page 2. i don't know much about CMOS, but it's so perfectly symmetric, that i doubt, it bothers about being a source or a sink. isn't that, what they do for multiplexing as well? about the multiplexing: did you take into account, that one of the SR has to supply current for 4 leds through one pin in the worst case? sounds worse than 8 leds through 8 pins in my opinion :P i still believe, 1 digit through 1 SR is the best solution for you, if you have enough spare SRs. you said, you have more blue LEDs connected apart from the digits. i guess they go 1 LED to 1 pin as well? if this works fine, why should it be different for the digits? i hope i don't send you to thinking-nirvana with that :) Cheers, Alex

Hey, i read your post and just remembered the following thread. This (the user) did some extensive testing there, e.g. draining up to 35mA from 8 pins at once. http://www.midibox.org/forum/index.php/topic,13460.msg115545.html#msg115545 Just in case you missed it in your search. What i read from there is, that the maximum total current is mainly to make sure, the chip stays in specs for logic-1, which it is intended for. seems it actually even survives beyond 200mA total current. Do you have the modules already built? then i would just give it a try :) According to the thread you will hardly be able to fry the chip, nor your led-digits. so there's no risk. just my humble 2 Cents. i'm not really experienced in that stuff :P Cheers, Alex

Hallo, nachdem mein Projekt definitiv dem Low-Budget-Segment zuzuordnen ist, habe ich einige Teile von Pollin bestellt. Vielleicht interessieren ja jemand meine Erfahrungen damit :) Beim LCD hab ich lange mit mir gerungen, ob ich das große 4x27 nehmen soll oder lieber ein kleineres 2x20, das dafür wesentlich schicker ist. Es ist dann das kleine geworden: http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MjgzOTc4OTk= hat 2x20 Zeichen (5,5mm Zeichenhöhe), weiße Schrift auf blauem Hintergrund für 3,95. Von dem bin ich bei dem Preis mehr als positiv überrascht gewesen. Schaut wesentlich besser aus als auf dem Produktfoto (meine Kamera is leider kaputt). Finds auch sehr praktisch, dass die Platine nur nach links und rechts übers Gehäuse übersteht. Statt Lötpads hats ne 2x8 stiftleiste. Das Datenblatt taugt eigentlich nur für Abmessungen und Pin-Belegung. Die seltsame Zeichentabelle z.B. ist einfach komplett falsch. In Wirklichkeit entspricht sie genau dem Standard-Zeichensatz des HD44780. Wenn man das rausgefunden hat machts aber eigentlich nichts -> Uneingeschränkt empfehlenswert! Dann habe ich noch die Radiohm-Fader für 50Ct. gekauft. Sind komplett aus Plastik und machen nen ziemlich zerbrechlichen Eindruck. Jedes meiner 4 Stück braucht unterschiedlich viel Kraft zum bewegen, teilweise sogar innerhalb des Fader-Wegs. Elektrisch scheinen sie in Ordung zu sein, hab aber nur gemessen und sie noch nicht eingebaut. Großes Fragezeichen ist die Lebensdauer. Für mich werden sie's wohl tun. Aber man bekommt genau das, was der Preis verspricht. Schließlich sind da noch die bekannten Panasonic-Encoder. Ich brauch eigentlich nur einen als Jog-Wheel, hab aber auch mal 4 genommen. Rasterung will ich zwar schon, aber bei denen ist sie schon relativ hart. Deshalb hab ich die Rasterung des ersten wie in der Wiki-Anleitung entfernt. Allerdings nur eine der zwei Kugeln, so dass die Rasterung nur leichter wird. Sah soweit ganz gut aus, bis ich sie angeschlossen hatte. der Encoder ist mit Speedmode Fast (2) eingestellt und mir ist es regelmäßig passiert, dass bei zwei-drei benachbarten Rast-Stellungen der Wert auf einmal um 4 weiter springt. Zuerst dachte ich, dass es daran liegt, dass ich die beiden Pins vertauscht hatte, das wars aber nicht. Anscheinend stimmen Rastungen und Impuls-Flanken nicht genau überein. Liegt wohl an meiner jetzt einseitigen Rastung, dachte ich mir. also zweite rastung auch entfernt. Dabei hab ich leider die Abnehmer verbogen -> gleich neuer Encoder. Diesmal hab ich vorher durchgemessen, ob ich von den Rast-Punkten aus etwas Luft habe, bevor einer der Kontakte umschaltet. Und sie da: auch hier gibt es 2-3 Stellungen, in denen eine Flanke direkt neben der Rastung liegt und ich den Encoder nur berühren muss. Also der dritte Encoder. Bei dem waren die Messungen in Ordnung, ich hab ihn dann unmodifiziert mit der harten Rastung eingebaut. Allerdings zeigt auch der nach nur wenigen Probedrehungen das gleiche Verhalten. Von daher bin ich mittlerweile etwas skeptisch geworden. Auf der anderen Seite haben schon einige den Encoder verbaut und sind zufrieden. Evtl. schlechte Charge? Liegt es an meinem Einbau (habe die Pins so zurechtgebogen, dass sie ins Standard-Lochraster passen) ? Oder fällt der Fehler nur auf, wenn man Speedmode Fast benutzt? Nachdem es wie gesagt ein Low-Budget-Projekt ist, werd ichs einfach mal hinnehmen (tritt auch nur auf, wenn man genau auf den schlechten Rastpunkten stehen bleibt). Falls noch wer ne Idee oder andere Erfahrungen hat, würds mich auf jeden Fall sehr interessieren. Das wars auch schon :P Grüße aus Landshut/Augsburg, Alex

hihi, i just played around quite aimlessly and suddenly got this message from the compiler: INCOMPLETE SUPPORT FOR INITIALIZED union---FALLING BACK TO struct This is a bug. Please file a bug-report with your source attached. INCOMPLETE SUPPORT FOR INITIALIZED union---FALLING BACK TO struct This is a bug. Please file a bug-report with your source attached. gplink -s C:\Programme\MIOS_base/etc/lkr/p18f452.lkr -m -o project.hex C:\Programme\MIOS_base/lib/libsdcc.lib C:\Programme\MIOS_base/lib/pic18f452.lib _output/main.o tried it with sdcc 2.9.0, and error was gone, instead, where the 3 pointer bytes should be, it's only 0x00,0x00,0x00 i'll look into the bug list once more and meanwhile look for an alternative solution. maybe a void-pointer, cast to the right type before use. Cheers, Alex

I just tried to find out, what it's doing there by adding some char-vars and -unions. when i add a simple char behind the union and add an according value (i took 0xef and 0xff) to the initialization, asm will look like that: _menu db LOW(_testfunc), HIGH(_testfunc), UPPER(_testfunc), 0xef, 0x00, 0x00, LOW(_teststring), HIGH(_teststring), 0x80, 0xff, 0x00, 0x00 that seems to confirm what you said. but why does it do so? but when i add a simple union of 2 chars in front of the pointer-union, i seem to be completely unable to get it compiled: main.c:37: error 2: Initializer element is not constant main.c:37: error 2: Initializer element is not constant make: *** [_output/main.o] Error 1 no matter, how i distribute the values or how i set braces. when i have a union of only 1 char in front, it compiles again ??? i want the complete struct to take 5bytes in total (including 2x char). that would let me populate the array with 51 elements (256/5). currently, i'm using up 27, enough headroom for future menu-entries. dropping the union leads to a footprint of 8bytes -> max 32 elements. that works now, but

Hi, i'm working on a menu-engine for some time now. after struggling (and learning) a lot with (about) pointers, structs and unions the last 2 days, i'm finally stuck now :) I'll post the problem first, then what i need this for. --the problem-- one of the fields in a struct (for the menu-entries) should hold a pointer to either a function or a string. so lets have a union in the struct: void testfunc(void) { } unsigned char teststring[]={"i'm a teststring"}; typedef struct { // i have dropped all variables here, not affecting the problem union { const unsigned char (*const text); //pointer to string const void (*const menu_func)(unsigned char); //pointer to menu-function }; } test_t; const test_t menu[2] = {{&testfunc},{&teststring}}; //initialize the test-menu compiles fine, but when i look into the asm code, menu contains 4*3 bytes, so it seems the compiler has converted the union into a struct without telling me: _test db LOW(_testfunc), HIGH(_testfunc), UPPER(_testfunc), 0x00, 0x00, 0x00, LOW(_teststring), HIGH(_teststring), 0x80, 0x00, 0x00, 0x00 when i remove the outer struct, so that test_t is a union, it compiles as i expect: _test: DB LOW(_testfunc), HIGH(_testfunc), UPPER(_testfunc), LOW(_teststring), HIGH(_teststring), 0x80 i googled a lot and also discovered, that there have been many bugs in sdcc concerning initialization of unions, but they were either fixed or don't apply to this case. same happens in sdcc 2.8.0 and 2.9.0. have a clue? --what i need this for-- each menu-entry should have a small footprint in order to pack as many entries as possible into the 256byte-limit, and to safe code-space (even if i still have plenty left). it should be possible to enter submenus, change numeric values and change strings. what i came up with is an array of structs with each struct of 5 bytes holding 1 entry. each entry can be 1 of 4 types: type 0: submenu -> you can choose between several followup-entries (e.g. for selecting "midi-setup", "pots", "buttons", ....) type 1: multmenu -> you can choose between many values, all pointing to the same followup-entry (e.g. for selecting pot1-64) type 2: editval -> edit a numerical value type 3: edittxt -> edit a string depending on this type, the bytes of an entry have different meaning: byte0 byte1 byte2-4 bit6+7: bit0-5: 00:submenu index of first subentry number of subentries pointer to entry-function (mainly for handling display stuff) 01:mltmenu index of subentry number of subentries pointer to entry-function (mainly for handling display stuff) 10:editval minimum value maximum value pointer to edit-function 11:editstr unused length of string pointer to string i then would track the way taken through the menu in a small array (2bytes per menu-level), so i find back to where i was before, when i exit an entry. at the same time, i can read it to see earlier selections. e.g. when i alter a value for a button, that was selected in a multmenu. then i have to look up, which one it was. i took this whole approach to be flexible, when extending the menu. if you can follow my thoughts, any comments are very welcome :) concerning this union: i certainly could use a function-pointer to a stringedit-function as well and do stuff there (possibly better anyway) or even drop it entirely and do this with the other types. still i'm curious, why the compiler acts the way it does. thanks for reading or maybe even some input :) Alex

Yay :D

for a midibox-project an altered firmware isn't essential. i just looked into the manual: the altered firmware is to control the leds and the display on the fcb. seems, they can't be accessed via midi-in. if you can get over this, you needn't do anything with the firmware. but having the right leds lit up, might be important. especially, when you switch to an earlier patch, so you can see which switches are on. if you could get hold of this gordius firmware, you might be able to find by trial and error, what are the commands to change the leds and the display. but this seems rather viewless. maybe one of the asm-gurus here could help you, but i guess, it's also far too much work, to reengineer the software of the fcb. viewless as well. if you get the gordius firmware AND find some nice ASM-Guru, it should be quite possible to find out, what they changed in the firmware and deduct the necessary commands. i'm moving on really thin ice here, though. never really touched asm in my life ^^ the straightforward option is, to rip the electronics out of the board and replace them with your midibox 8) this should be quite simple, if there's enough space inside. besides, you end up with a single unit. however, it feels wrong, to strip a working unit. (at least to me ) i had to make a similar choice only a month ago and decided to have an external unit. now im quite happy about that. as i discovered, using buttons, sliders n pots on the midibox is far more comfortable to me than using the floorboard. so it's in the cellar now :) but thats certainly special to me. to come back to your problem, i think i would go the radical way. if they layed out stuff nicely inside, you might even be able to put the original electronics back in, if you regret it. (doubtful though :-P ). cu, Alex

nice price. how hard is the detent, and where did you get them? :D

jaja, was man mit einem soooo kleinen zeichen für eine verwirrung stiften kann :P ich kapier aber immer noch ned ganz wo der unterschied zwischen "&array[0]" und "array" (oder im 2-dim fall "&array[0][0]" und "array[0]" ) liegen soll. da hattest du n paar posts weiter oben geschrieben: "&mapping[0]" und "mapping" sind doch exakt der gleiche pointer? argl, muss ins bett, damit ich morgen ganz früh und mit frischem hirn weiterbasteln kann :D ciao, Alex

hehe :D that video-recorder thing just jumped into my mind, as i tried to repair one some days ago :) cheers! n tell us what you will use it for! Alex

ich dachte eigentlich, dass genau dafür das & da ist ^^. muss mal kucken, ob das sdcc anders handhabt, aber würde mich eigentlich wundern. und wenn man ein array benutzt, ohne einen index anzugeben, dann bekommt man normalerweise auch einen pointer, der auf den speicher zeigt, an dem das array anfängt. hab mir grad ne C-Referenz und die anleitung zu sdcc angeschaut, aber nirgends ein @ gefunden...

sounds like an encoder with turn-buttons to me. maybe with 2 way speed like on some video-recorders. where you can rewind, fast rewind (turning left) or forward, fast forward (turning right). that would make: encoder: 3 pins 4 buttons: 4+1 pins voila! 8)

mist, dachte, ich editier das noch ganz schnell rein, aber hast genau in dem moment gepostet :P ich hab ja selber noch kaum erfahrung. bin auch grad dabei, meiner anwendung, bei der alles fest gecoded is, presets beizubringen. steh aber auch noch in der planungsphase, welche daten muss ich sichern, wie organisier ich die, etc. Finds auf jeden Fall ziemlich spannend alles :) evtl. kannst ja nils ne pm schicken, wie das @ gemeint hat. und vor allem wozu :)

ok, thats a fancy one :) looks really nice!

hmm, ich kann mir auch keinen richtigen reim drauf machen, wie Nils das gemeint hat. ich glaub ja fast, er hat sich vertippt und meinte eigentlich "&mapping[0]" :) wobei das eigentlich auf exakt das gleiche rauskommen sollte wie "mapping". bzw. in deinem beispiel sollte mMn "&array1[n][0]" dasselbe wie "array1[n]" sein. keine ahnung was das ausmachen soll ??? wegen dem flash: funktionieren sollte es wohl. so wie ich das mitbekommen hab, ist n bankstick aber der saubere weg, um solche daten zu speichern. und einfacher wahrscheinlich auch. kannst einfach ab adresse 0x0000 loslegen und musst dir keine gedanken machen.

i meant to use another psu as well, but i just discovered your thread about using a 5v psu http://www.midibox.org/forum/index.php/topic,13749.0.html that explains, why you want use that psu :) if this is such a big unit, i would put the psu inside the protodeck, if there is the space. so that you plug the mains-cable directly to the unit.

Hi there, i want to expand my app by presets stored on a bankstick and have some elemental questions again :) 1.) at ucapps.de->bankstick, it says, writing to a bankstick takes ~10ms, for either, bytes or pages. for reads it just says ~100us. I guess this is also for both, bytes and pages? 2.) presets will take up 128bytes, so i want to use a union for data access and bankstick transfers. i just havent worked much with those and im a bit uncertain, if the following is ok, esp. with regard to heavily mixed var-types: typedef union { struct { unsigned char BStick_page1[64]; unsigned char BStick_page2[64]; } struct { unsigned flag1:1; unsigned flag2:1; unsigned mode1:3; unsigned mode2:3; unsigned char status; unsigned char name[12]; data_t data1[6]; //data_t defined somewhere above //.... } }preset_t; preset_t current_preset; then i should be able to read presets with MIOS_BANKSTICK_ReadPage(preset_nr*0x80, current_preset.page1); MIOS_BANKSTICK_ReadPage(preset_nr*0x80+0x40, current_preset.page2); same for writing. i hope thats fine so far? 3.) im just curious, what exactly MIOS_MIDI_BeginStream /-EndStream is doing. I haven't used it so far, and im not planning to link another core. but still im interested and the description is not very specific, except, that it's "important" for Midibox Link. that's it so far :) Thanks n cheers, Alex

hey Chris, mein code beispiel kann auch mehrere relais setzen. wenn du beim schreiben ein OR (resp. | ) hernimmst, bleiben alle anderen bits unverändert, ausser dem, wo die maske eine 1 enthält. du kannst also für einen CC erst relais 1 setzen und später auch noch relais 5. dazunehmen, so dass beide schalten, wenn der entsprechende CC ankommt. der vorteil der OrMask ist, dass du nicht eine Routine für jedes relais schreiben musst, also in deinem beispiel die expliziten abfragen mit 0x01 bis 0x20. die OrMask generiert dir genau diese Zahl, wenn du ihr die nummer des Relais gibst. wenn du also das 6te relais überprüfen willst, übergibst du 0x05 == 0b00000101 (wir zählen von 0) und bekommst als ergebnis 0x20 == 0b00100000. hab ganz vergessen, dass man ja evntl. auch relais wieder löschen möchte. um relais 3 zu löschen brauchst du dann array1[ccNumber] &= 0b11111011; // == 0xFB das lässt alle anderen relais-einstellung unverändert und löscht nur relais 3. alternativ mit der Maskenfunktion: array1[ccNumber] &= MIOS_HLP_GetBitANDMask(learnMode); ich bin mal davon ausgegangen, dass in allen beispielen, die variable "learnMode" die Relais-Nummer enthält, um die gleichen Namen wie Nils zu verwenden. was mir gerade einfällt: es gibt doch die midibox cv. hast du dir die schonmal angeschaut? evtl. kann die schon alles was du brauchst. wenn auch selbermachen natürlich wesentlich cooler is :) Grüße, Alex

regarding the plug, i think of other equipment, standing near your midibox (keyboards, synths, whatever). so i meant using a plug, that fits in no other equipment at all (maybe mini-din, sub-d,...). just to clarify my thoughts, as i guess, you already got what i mean :) about the fuse: i dont know what kind of fuse you want to use. i dont know whats available there, but an ordinary melting fuse will certainly be too slow. i guess, even a short voltage spike can burn the pic. according to the pic's datasheet, input voltage is rated at 4,2V up to 5,5V. i didn't find anything about a lethal voltage though :P just out of curiosity: why don't you want to use the inbuilt power regulation? bye, Alex

mios is only the operating system. it does nothing by itself. when uploading an application, actually the midibox gets some functions. i dont know, what you are planning to do. you can find applications directly on ucapps.de under MBHP projects. e.g. midibox64, midibox seq, etc. alternatively you can code an application yourself, using the sdcc-skelleton, for C-applications. i would suggest to look into ucapps and the wiki in depth. some links, answering your question: http://www.midibox.org/dokuwiki/ http://www.midibox.org/dokuwiki/doku.php?id=mios http://www.midibox.org/dokuwiki/doku.php?id=projects ... best would be to read through the whole thing :) almost everything you need is in there.

i say you can drop them. but you know that situation when you are in a hurry or a bit absent minded. it happens sooo easy, that you plug something wrong. with the conventional setup, you might blow up the regulator, in your case you can say good bye to your cores and what else is a bit sensitive. so if you are sure to do that, i would have psu, that is hard wired (psu inside the case) or at least have a very unique plug, so that nothing else fits. just my two cents :) cheers, alex

can you give details, what "dead" means? is it doing absolutely nothing? not even backlight, shadows of where the characters should be? just to make sure: you tried changing contrast and backlight? first thing would be then to check your cables i would say. have you taken care of the special order of the pins as described at ucapps AND checked, if your display pinout matches? just some thoughts of another newb, but maybe it helps :) good luck, Alex

hi, MIOS kann zwar mehrdimensionale Arrays, aber grundsätzlich dürfen arrays nicht mehr als 256 byte belegen (gibt n workaround, aber machts kompliziert und unschön :) ). da wärst du also drüber (128*7=896). du hast vermutlich vor, die felder [CC][1] bis [CC][6] entweder 1 oder 0 zu setzen, um zu bestimmen, ob das entsprechende relais schalten soll oder nicht? erstmal achtung: zählung geht bei 0 los. wenn du also my_array[8] definierst, kannst du auf die elemente my_array[0] bis my_array[7] zugreifen. Du brauchst ja eigentlich nicht 8bit pro relais, sondern nur eines. in einem char könntest du also alle 6 relais speichern. eine möglichkeit wäre eine AND-Verknüpfung zum lesen und eine OR-Verknüpfung zum setzen. 0x01 z.B. ist in bit aufgeschlüsselt 0b00000001, also das erste relais, 0x08 = 0b00001000 dann das 4te relais. dein code könnte dann z.B. so aussehen // das relais mit der nummer "learnMode" soll dem CC Nr. "ccNumber" zugewiesen werden array1[ccNumber] |= MIOS_HLP_GetBitORMask(learnMode); // MIOS_HLP_GetBitORMask gibt dir zu einer Zahl einen Wert zurück, bei dem nur das bit an der stelle "Zahl" gesetzt ist, // also z.B. learnMode == 4 => MIOS_HLP_GetBitORMask(learnMode) == 0b00001000 // zu einem CC sollen die richtigen relais ausgelöst werden for (relais_nr =0; relais_nr <= 5; ++relais_nr ) { relais_set = MIOS_HLP_GetBitORMask(relais_nr ) & array1[cc_number ]; // z.B. cc_number = 28, relais_nr = 4, array1[28] = 0b00001001 => relais_set == 0x08; da ungleich null, wird das 4te relais geschaltet MIOS_DOUT_PinSet(relais_nr, relais_set ); } wegen dem speichern: soweit ich das mitbekommen hab, sollte man eigentlich ein schreiben in den flashspeicher zur laufzeit vermeiden oder? (gefahr, irgendeinen programmteil zu überschreiben etc.) stattdessen lieber einen bankstick hernehmen. oder habt ihr da keine bedenken? zu 2.: so ganz hab ich nicht verstanden, was du mit "speicher 0" meinst, dass der speicher komplett leer ist? wenn du ihn jungfräulich kaufst, dann ja. als nächstes musst du dann den bootloader mit deinem mbhp_burner draufbrennen, dann über midi das Betriebssystem MIOS aufspielen. jetzt kannst du über midi deine Anwendungen aufspielen. entweder ne fertige andwendung wie z.B. Midibox64 oder eine eigene, die du idR aus einem SDCC-Skelett mit deinem Code oder aus einer modifizierten Anwendung compilierst. und zu 3.: genau! in ne funktion verpacken müsstest du das selber. Wobei mir noch nicht so ganz klar ist, wann man das ...BeginStream und ...EndStream braucht. bei mir steht das nirgends dabei. Wird damit MIOS_MIDI_TxBufferPut aus anderen Funktionen heraus blockiert? Grüße und viel Spaß beim Basteln :) Alex