audiocommander

sorry, I know there are some threads about the DOUTs, but I'm having trouble getting my DOUT module to function. I connected two LEDs on line 30 and 31 of 1 DOUT module, connected to J8 of CORE (that's because I plan to bring some more LEDs on the other outputs...). I have no DIN module. As soon as I'm calling [tt]MIOS_SRIO_NumberSet(4);[/tt] my application won't be executed properly anymore. Every second pin of the DOUT is lighted, though. If I comment this line out, everything works fine, but naturally all DOUTs are low. This is my init: MIOS_SRIO_UpdateFrqSet(1); // ms, shift register update frequency MIOS_SRIO_NumberSet(DOUT_SR_NUM); // number of shiftregisters (4 per DIN/DOUT module!) and that's on SR_Service_Prepare: void SR_Service_Prepare(void) __wparam { // called every ms // handle DOUT LEDs if(lastAinPin > 0 && lastAinPin < 3) { // distance sensor LEDs on AIN 1 & 2 if(lastValue[lastAinPin] >= 20) { MIOS_DOUT_PinSet((lastAinPin + 29), 1); } else { MIOS_DOUT_PinSet((lastAinPin + 29), 0); } } } I simply want to switch on a LED if the sensor receives a signal. Is this because I have no DIN? Do I have to ground some pins I'm not aware of? Have I totally misunderstood the DOUT-concept? ??? Any hint appreciated! Cheers, Michael

yes, I remember having read similar. But how about using an IC for multiplexing? Some years ago (before Midibox) I worked with an 4 to 16 line (which is actually just 4 to 10) demultiplexer (SN74LS145); these are also available as multiplexers (16 to 4 => 10 to 4). You just have to decode the 4-bit value by code and can therefore get the states of 10 button, but I think this should be achieveable without timing issues, if coded smart. But this is really just a guess :)

AIN measures Analogue Voltage Ranges (typ. 0V to 5V), e.g. if you have 2.5V on AIN/Pin0, is is likely a Midi Message with the value 64 or 65 will be sent (depending on the application, of course). You typically connect a potentiometer (10k, linear, either round pot or fader) to an AIN. DIN checks the logical level of digital input line, that means: 5V OR 0V (logic HIGH and LOW). You can connect all kinds of switches, buttons, knobs or encoders. So: AIN is Analoge Range, DIN is Digital Input. A piano keyboard normally involves Digital Input (key down, key up), sometimes also AIN (aftertouch amount -> pressure range!). There are multistate switches like the one in your link (-> for more than one pole you need multiple pins), buttons to toggle, snap; radio-button groups... that's too much to tell. Take a look in an electronic store or see the parts FAQ in the Wiki. Best, Michael ;)

hey jeb, no need to double-post ;) (although I enjoyed training my french)

oui, c'est possible. tu peux avoir 2 * AIN (parallel) et 4 * DIN (serielle, chaine) et (je pense) 4 * DOUT Ã un module CORE. Quand tu veux plus DIN, il y a quelque techniques (multiplexing/free CORE-pins), mais c'est une question d'efficience et de tempo. Michael

(excuse mon francais, je comprends, mais je ne peux pas parler très bien :P): c'est n'est pas possible. Tu peux connecter seulement 2 AINs / Core. Les modules AIN ne sont pas chainez commes les modules DIN/DOUT: => J5 de Core a seulement 8 pins. Mais c'est possible avec deux modules Core (-> MidiLink). ;) Michael

naja, entweder halt mit ganz normalen Kabeln, verzinnen, dranhalten, kurz erhitzen, fertig - oder wenn du die Kapazitoren meinst: erst richtig hinbiegen und Beinchen kürzen, dann Schrumpfschlauch drüber, festlöten und am Ende Schrumpfschlauch mit dem Feuerzeug kurz erhitzen, fertig ist die isolierte Verbindung :) Grüße, Michael

When you're using the Analogue Pins from J5, you can stay in the AIN_Notify() Function, no need to setup anything else. No variable needed then. Just add (pseudo-code!): switch(pin) { case 4: if(value > 64) { // switch selected } else { // switch not selected } break; case 5: if(value > 64) { // switch selected } else { // switch not selected } break; case 6: if(value > 64) { // switch selected } else { // switch not selected } break; } Note that this works _only_ inside the AIN_Notify() Function. If you choose for other Pins, there has to be another implementation. The function will be called, whenever the state of the AIN-Pin changes. Best, Michael

Right, greenfox :) Maybe I'm totally wrong, but modifying the sysEx-File seems not like a very good idea to me. From the description @ ucApps: I don't know if Serge's SysExBox compiles something for you, the "normal" way is: Edit and recompile (that means generate a new .hex-file, then convert the .hex to .syx and send by SysEx -- or send the .hex with MIOSStudio, which does the hex2syx-conversion for you). Please refer to http://www.ucapps.de/midio128.html for a detailed description. Maybe you want to add your experiences to the Midio128-Wiki-Page? http://www.midibox.org/dokuwiki/doku.php?id=midio128 (and remember: I'm not into Midio128 project, so this is just a guess! ) Cheers, Michael ;)

If you just want to hack the mb64 project, it can't be that hard, but it's in ASM, and I'm obviously too lazy to learn that, so I can't help you 'bout that ;D But Thorsten has made it very (very) easy to code in C. You might want to take a look in the AppDev Section of the Wiki: http://www.midibox.org/dokuwiki/doku.php?id=application_development and the C-Function List @ ucApps. If you're on Windoze, stryd_one has just finished an excellent tutorial with an openSource IDE called code::blocks. I did the same for Xcode on the Mac. So installing the tools and setting up your environment will be very easy ;) If you know C you should have your application ready in a few days; if you start from scratch, it may take some weeks, but I'm sure it's easy for everyone. TK added plenty of examples and the list of converted C-applications grows from day to day (maybe just pattern storages and complex DOUT examples are a bit rare at the moment). It's a lot fun to code one's own applications :) Cheers, Michael ps: I'm from germany. And you, Mickaël? :)

Xcode uses a packet (kind of "invisible folder") with at least three xml-like property-lists. But they contain a lot of entries (also user-related) I wouldn't touch programmaticaly, because experience teached me, this is no good idea (at least regarding the frequent update cycles from Apple :) ) btw: the mirrored link is: http://www.audiocommander.de/downloads/midibox/SDCC+AC-Sim+CBP_Skeleton_v1.9.zip ;) Cheers, Michael

Have you tried if it works with an unmodified MIOS? If you changed MIOS and made experiments writing your configuration into Flash rather than onto a bankstick, it's likely your problems result from there... Cheers, Michael

You're right, I'm sorry (mentioned it's been just a quick view). But the point is: it's all in your hex-file: Block 003000-0033FF allocated - Checksum: 4F Block 003400-0037FF allocated - Checksum: 71 Block 003800-003BFF allocated - Checksum: 59 Block 003C00-003FFF allocated - Checksum: 36 Block 004000-0043FF allocated - Checksum: 2C Block 004400-0047FF allocated - Checksum: 4B Block 004800-004BFF allocated - Checksum: 4E Block 004C00-004FFF allocated - Checksum: 6E Block 005000-0053FF allocated - Checksum: 1E Block 005400-0057FF allocated - Checksum: 2D Block 005800-005BFF allocated - Checksum: 75 And if there is a buffer overflow or something unlogical compiled, you can't be sure, that any data executed is really the data you think it ought to be. That's the mean thing with it... I'm focussing to "How can a progamming error cause remaining problems during upload?". If I were you, I'd try it with a fresh project skeleton without all that unused overhead. If you succeed with it, you can slowly put all things back you want to implement and check from time to time if it works or not. I'm pretty sure, if you do only the basic stuff, there is no problem (you said you succeeded with precompiled applications).

Hi Thomas, after taking a very (very) quick look: You're sending a lot of sysEx commands as response to AINs (in the intercom classes) with different buffer sizes. This seems a bit suspicious, having in mind what Thorsten remarked. I'm going to have a deeper look next week (when I've a bit more time) ;) Regards, Michael

The hardware-specs say there are only three DINs used. So there are 32 inputs left, right? Either this is enough, or you're going for an encoder chip that encodes your button matrix state. They are easy to use and if that's an option I can see in my archives what kind of IC's I used for a button input matrix... But I have no clue on ASM-implementation nor if this affects the overall performance! :) Cheers, Michael

Hi gigmick, welcome aboard :) What application do you use? (e.g. your custom app in C or a ready programmed project like mb64, mb128io, ....)? There are different approaches for C and ASM. Take a look at the function reference @ uCApps; there is one for C and one for ASM! See MIOS_LCD_Print...() and DISPLAY_Tick() if your app is written in C! Regards, Michael

It could be really helpful if you post your code. I think it's possible to have bad code that results in strange hex/syx files. SDCC is not comparable to a long-time-tested compiler like GCC, so it may happen that there are compile errors that are not recognized, but deliver unpredictable results.

thank you Thorsten! Now at least I can upload again :D I'll keep you updated and post useful stuff to the wiki -> http://www.midibox.org/dokuwiki/doku.php?id=iic_modules btw: I don't recommend using my breadboard design until I succeeded ;) There are some minor errors, anyway... but I'll fix that soon! Cheers, Michael

no. but there are some examples with a bankstick-content.asm file. This might be helpful (or not)... yes ;)

You need to use a DIN board to be notified by DINNotify_Change (as with AINNotify_Change). If you don't want to use a DIN module, please refer to the concept I already posted: http://www.midibox.org/forum/index.php?topic=6754.msg43142#msg43142 Check the pintable listing, decide for three appropriate pins of the core module and see the hardware example (http://www.ucapps.de/mios/j5_din.pdf) on how to connect your switch! The resistor is important, otherwise your core will be shortened! when you're done with that, tell us and then I'll start a wiki how-to... michael

wonderful! :D I just discovered the changes to the sim... good job, mate!!! I'm going to add IIC and Speakjet handlers next week.. that's great, like the way I imagined it ;)

the 2nd parameter is the buffer. You "give" the buffer to the function and it will be returned, filled with data. See writePage on how to create the buffer. There's an example in the C-Function-Overview: http://www.ucapps.de/cmios_fun.html#MIOS_BANKSTICK_ReadPage But I agree, an additional example how to get and fill that buffer would be helpful. Anyone already did that and want to share his/her experiences? I have not worked on my sensorizer project any further, because I obviously have to reprogram wide parts of my application, but as soon as I resume, I'll keep you updated... Edit: forgot that there are no ladies here.. ;D

haha, so you found it ;D (It's not yet complete, I may add address ranges) I was still about to type my answer (for two days now ;D ...that's a slow type!), but wanted to run a few tests before... I am currently stumbling upon these two questions I cannot answer by myself: - is it right to set jumpers for the ID#20 in the same way as described of the IIC_MIDI page (both jumpers set)? I think, I have a problem with the IIC connection somewhere, seems the core module just cannot find the appropriate slave, although both PICs have 0x20 set in code... As I see from my simulator, the code should work, but in reality the PIC18F hangs up (doesn't react to anything anymore, not even application updates) as soon as [tt]IIC_SpeakJet_Init()[/tt] is called... (I have not changed the firmware of the PIC16F). - I wonder if that 1k Resistor on J4 of Core between VD and SC (as seen on the IIC_MIDI_interconnections) is also required for the SpeakJet? Thanks, everyone!

Thanks for your work, stryd_one :) You've done a very good job with this article. karma-candy for you ;D (upps, no, clear that, don't want no bad karma anymore ;D) I could mirror the zip, too; I've got a midibox-directory on my server anyway with all the pics and SDCC-binary installers, so chances are very low it's disappearing soon... although it would be good to have one copy here, because any server can go down and any addict can loose it's interest :-\ Just because I'm curious: The WIKI software's not caching zip-files, too? (I haven't tried it, but I find the pic-caching-idea quite impressive)

well, I think you got a few things mixed up. *.asm means it's an assembler file *.c / *.h means it's C. either you grab one of the precompiled applications like MidiBox 64 (but then you have to make sure you got the hardware requirements) - or you code your own application, but that means, you have to program it! You need to download the C-Skeleton (with main.c not main.asm!). Stryd_one is writing a step-by-step tutorial at the moment, maybe you're going to take a look (wiki -> application developement -> wintel...). In other words: if you haven't said the box what to do when turning a know, it won't do nothing :-\ Asking again: C or ASM? (I'm always assuming C is the best choice, but I don't know if you're an assembler-pro, right? ;D (btw: it's sunny in Nuremberg, but they say it should rain this afternoon :)