audiocommander

500k != 50k 500k = 50 * 10k 50k = 5 * 10k 50 / 5 = 10 => 10k :o ;D

that's what we were laughing about: a bit is either 0 or 1 it cannot be -1 (or maybe stryd_one is sitting in front of one of these mysterious quantum computers cooled down to -250°C with an ice beard developing the seq Vx to conquer the world) ;D just take an unsigned char – that's the smallest possible variable type besides some custom typedefs... you have to take care, that no variable name is used in the c-namespace that hasn't been defined or declared... maybe it helps to peek in a basic c book, there are some excellent free online-books. you should have read the pure basics (variables, scopes, syntax) in one day... it's not very difficult, esp. when you consider that SDCC just knows the plain basics of this language – so don't let it scare you by a thousand pages, it's mostly only the first 50 relevant for PIC dev ;) cheers ;) Michael

unsigned bit ;D that's nice... thanks for that stryd_, about loops I may add that there's a restriction in SDCC: no function calls are allowed inside loops... nasty terrain here and there :) have a good sleep (it's 6pm here haha..) cheers, Michael

have you measured the behavior with an ohm-multimeter before connecting it to the MB? If the ribbon-controller is okay: how did you connect it?

stryd_one, I think the underscore before the name is just an indication that it's a renamed symbol for the linker (or compiler or what the heck... don't know exactly). therefore I would recommend to find out what Moxi/theApplication wants to do with LFSR FSR1, AOUT6_L? I cannot say anything about the values, because I simply don't know ASM (besides the barely nfo in the datasheet it all looks quite chinese to me ::) ) and I don't know exactly what this app does at all, so I'm better saying nothing ;D just find out what it's good for and give it the right parameters and everything should be fine... I mean it's a bit ridicilous to discuss if a value should be a constant defined or a volatile int if obviously noone has a clue what it's good for? isn't it so? nevertheless... :) cheers, ac

well, I don't know... ??? When you #define it in aout.h (like you did) it is a fixed value, but I don't know if it should be. If you want it to be a variable so that it can contain different and changing values, it shouldn't be #defined, but rather declared as an unsigned int (as you stated before). In general it is a good idea to match the naming conventions; therefore variables are normally written in lowercase, while #defines are written in UPPERCASE... Sorry, besides having read that it sets some AOUT-values, I have no clue what the program does... :-[ Hope this helps, best, Michael

no :) the #define preprocessor directive syntax is like this: [tt]#define SOMEWORD somevalue[/tt] eg: [tt]#define CONTENTS_OF_MY_POCKETS emtpy[/tt] or: [tt]#define NUMBER_OF_MY_ROLEX 12[/tt] or: [tt]#define MY_POSTINGS_IN_HEX 0x168[/tt] you can even define longer strings or whatever you like to see exchanged by the preprocesser (very early step in compiling). now you did that: [tt]#define AOUT0_L [/tt] (which means practically that AOUT0_L gets exchanged to "" (in other words nothing) that means that the preprocessor takes this line: [tt]LFSR f, AOUT0_L[/tt] and makes this out of it: [tt]LFSR f, [/tt] (which is obviously nonsense, 'cause you cannot move the literal 'nothing') so you just have to take care that you define AOUT0_L to a 12 bit value like: [tt]#define AOUT0_L 0xFFF[/tt] so that the preprocessor would make this out of it: [tt]LFSR f, 0xFFF[/tt] see? ...I don't know really ASM, so this is all a bit cheesy to me and I'm really not sure what AOUT0_L does at all... but the principle should be clear now, is it?

and one quick last hint from me (for today :) ) the pic18F datasheet sais: LFSR f,k Move literal (k, 12-bit) 2nd word to FSRx 1st word that means the AOUT..s have to be 12-bit numbers (if I'm interpreting that right...) cheers! Michael

Hi Moxi, JohnH was right, it is indeed AOUT6_L! if you look at the error: [tt]_output/aout.asm:207:Error [113] Symbol not previously defined (FSR1). [/tt] and then in the generated aout.asm file you see this: ; ; Starting pCode block S_aout__CV_AOUT_LC_Update_SRs code _CV_AOUT_LC_Update_SRs: lfsr FSR1, ; loads AOUT6_[LH] and AOUT7_[LH] rcall CV_AOUT_LC_LoadAOUTx_8_8 lfsr FSR1, ; loads AOUT4_[LH] and AOUT5_[LH] rcall CV_AOUT_LC_LoadAOUTx_8_8 lfsr FSR1, ; loads AOUT2_[LH] and AOUT3_[LH] rcall CV_AOUT_LC_LoadAOUTx_8_8 lfsr FSR1, ; loads AOUT0_[LH] and AOUT1_[LH] rcall _CV_AOUT_LC_LoadAOUTx_8_8 bsf LATC ; The latch enable input, 5 ; (CANNOT be shared with other outputs!) ; latch SID values bcf LATC ; The data pin, 4 ; (can be shared with other outputs) ; clear out pin (standby) bcf LATC ; The latch enable input, 5 ; (CANNOT be shared with other outputs!) ; release latch RETURN I am an ASM idiot, but at [tt]lfsr FSR1, ; ; loads AOUT6_[LH] and AOUT7_[LH][/tt] a parameter is missing and the warning about the ',' (comma) is right. when you look in the corresponding void CV_AOUT_LC_Update_SRs(void) function you see: [tt]lfsr FSR1, AOUT6_L ; loads AOUT6_[LH] and AOUT7_[LH][/tt] which means, that you have to define [tt]AOUT6_L[/tt]! I tried it with 1 and 0x1 but had no luck, because I simply don't know what this ASM function expects as value ;) Cheers, Michael

then it must either be a misconfiguration in your code::blocks IDE or some errors in one of the other files (main.h, main.c ...) I could also take a look into the other files if you made it available ;)

:) good point, but I just discovered a tiny "#endif", so this should be alright... as it did indeed compile on my computer, I think moxi forgot to add aout.c to the makefile, so there's some important stuff missing for the compiler or linker or whatever... but these #if 0 parts seem indeed a bit cheesy to me... and if they compile, yet they don't seem to improve readability... just my 2c... cheers ,) Michael

have you created a proper makefile? you must open MAKEFILE.SPEC in an editor and add this line right below l:39 (MK_SET_OBJ pic18f452.c main.c) [tt]MK_ADD_OBJ aout.c[/tt] more entries if you have more files like aout.c... then save and open up your console (DOS promt or terminal) change directory to the /tools dir and call [tt]mkmk.pl (path to MAKEFILE.SPEC here)[/tt] then you should see this output: [tt]Makefile generated. Makefile.bat generated.[/tt] then call [tt]make[/tt] from the directory of your sources. I could compile these files without any error: [tt]Block 003000-0033FF allocated - Checksum: 16 Block 003400-0037FF allocated - Checksum: 60[/tt]

can you send me both the header and the source file and I see if I can compile it...

Moxi, you just have to care about the very first errors. Most time the rest of the errors are a result of the first one. An illegal character is reported right before CV_AOUT_LC_LoadAOUTx_8_8, if I count these line-numbers (113) up to 108, this brings us straight to your "#if 0" thing. please remove this completely from the code and compile again: ;; this must be done once all SRs in the chain have been uploaded! #if 0 bsf CV_AOUT_LC_LAT_RCLK, CV_AOUT_LC_PIN_RCLK ; latch SID values bcf CV_AOUT_LC_LAT_DOUT, CV_AOUT_LC_PIN_DOUT ; clear out pin (standby) bcf CV_AOUT_LC_LAT_RCLK, CV_AOUT_LC_PIN_RCLK ; release latch #endif When I think about it, it seems very likely that C-preprocessor directors are not supported in ASM codesnippets! I bet this is it!

as the snippet has just 193 lines, I expect the error has been before... let's see what looks suspicious: - line 54: you should move the [tt]return[/tt] after the [tt]__endasm; [/tt]==> [tt]__endasm; return; }[/tt] - line 93: [tt]#if 0[/tt] if 0 will never be true and therefore will never be processed? is that okay? in cases like these, there might be an error in the header file? besides the "return;" I can see no syntax error. [tt]MIOS_PARAMETER3[/tt] is declared in cmios.h wich is included correctly. let's see if that [tt]return; [/tt]solves it...

can you post a bit more, so that I can see the whole logical snippet? is everything allright with "__asm" in the beginning of the token? (eg. no ";" after "__asm")?

Hi moxi, I think you have to add two underscores before calling [tt]__asm asmcontent...bla... __endasm;[/tt] best, Michael btw: is it normal that there's line 212 missing or have I watched too much doctor who investigating dissapearing things ;D

this one is pretty easy: just make a new line at the end of the file, so that the file does not end with a char but a blank line! could you post a snippet (maybe lines 180 to 190) of aout.c? cheers, AC

hi moxi, the errors should come along with the line and the file (eg: "undefined symbol _SOMETHING in 'main.c':144") I often have to look up error codes by myself, if you don't have no reference, just paste the relevant query with quotes to google and in 99% of all cases you get a clue of what's missing instaneously... defines are just exchangement for the compiler, eg you could define: [tt]#define TRUE 1 #define FALSE 0[/tt] ...and then use the words [tt]TRUE[/tt] and [tt]FALSE[/tt] instead of the numbers 1 and 0... cheers, Michael

64E is fine; that's why I also recommended that in my previous posting! ...but because MB64E is written in ASM, you don't get to know anything about C – and the C-Support of MIOS/SDCC is a nice thing. While building a ClockBox or designing a custom FilterBox, you get in touch with the most important C-Basics without complicating it too much. But sure, agree, MB64E would be a good starting point and maybe sufficient enough to control 1200 parameters by using patches :) #Cheers, AC

don't worry about C++, you just need plain C which makes the whole thing less complex (my personal opinion :D)... as I mentioned, just sending a CC is easy, storing patches requires at least a logical thinking about ordering some bytes and setting up an idea of a memory table (with a calculator at hand). in short: the answer is: you can do (nearly) everything, the question is: how much endurance and money are you willing to put into your project (have you thought of the fact, that the cheapest encoders are ~1 EUR (normally 2 - 5), this is a respectable sum; just for Encoders, no knobs, no faders, no chips, no LCDs, no PCBs... if you know what I mean... to be honest: I wouldn't solder 600 euros to start experimenting, maybe you find some use for a ready available DIY-project like the MBHP_clock or a simple midi-filter-box for the beginning; you can always re-use the modules later on and upload another application. or you adopt your demands to the maximum supported number of interface hardware parts, then you could start with a ready-available project like midibox64(e) or something, these apps have a lot of features that are tested, optimized and work very well... there should be a good reason to ignore these apps if you are a non-programmer ;) keep it up! Cheers, Michael

Hi Scube, if you look at the uCapps page you can see the maximum numbers supported by the different readymade mb-projects. if you have no programming-skills, you could simply use more of them and build them into one case, for example. this should be no problem as they are all pretty configurable. else you could write your own app. if you design it good (connections right ordered and numbering friendly behavior; eg. fader 10 sends cc 7 on ch 10, whereas fader 12 sends cc 7 on ch 12...) it should be not toooo much hassle... but that depends on your demands. custom applications can be quite easy (sending a midi-value) to very complex (multi-core linking, lcd-menues, encoder behaviors, bankstick support)... the coding itself is not the most difficult thing at all, it's the ordering process and keeping ones demand low ;D ...the syntax of C is easy, take a look at the MIOS-C-Reference and you've seen 75% of what you could do by code. with 300 encoders (or even 150) you need multiple cores anyway, so why don't you just start with one core (with up to 4 DIN-modules supporting up to 8 Encoders each DIN)? By realizing your project stepwise and fully modular you can slowly grow it to it's final size... and you'll surely know by then if you'd like to solder 900 wirings ;D hehe... If you need just one setup and no dynamic menues, patches or stuff - and enjoy soldering, you've probably found the best place in the midibox-world :) cheers, ;) Michael ps: it's always a good idea to keep the cabling (esp. for AIN-signals) as short as possible ;)

stryd_, I really hope she didn't misunderstand that! Just think of the picture – you swinging ladies hosiery around your head like a cowboy – I mean, I would have probably also thought about something sexual and not that you were just shaking out air bubbles... ;D lmao... (uhh, I need a fresh cup'o oxygen after all this fun...) btw: very nice thread moxi! thanks!

veery cool 8) Btw: one of the first speach transmissions has been invented by an hungarian, which kept asking into the wire: "hallható?" – ("am I to be heard?"). Some people think, this has been the creation of the international word "hello". :) Michael

Hello atom, dunno if get your problem, but maybe it helps: 1) if u get an upload request, you should upload MIOS and an application. To my understanding no loopback is active when there is just the bootloader active 2) the flickering of the input LED seems perfectly right 3) sorry, never heard of the MIDI DEBUG test1- LED :-[ 4) is it because you want to build a Midibox Link (Linking multiple Cores)?. If so, you have to enable the link in the application you use (eg MB64) or - if you are writing your own app - implement the forwarding by yourself. See this example (forwarding CH1-events): http://www.ucapps.de/mios_c_forward_chn1.html Regards, Michael