TK.

I knew that somebody will request such a mode sooner or later ;) No, such an option isn't supported yet, and I'm unsure if I really should add this to the firmware, or if people could just use existing Max/MSP patches to access the BLM directly for highest flexibility. Best Regards, Thorsten.

Of course - just try out some examples from this page: http://www.ucapps.de/mios8_c.html E.g. Sending MIDI events on button movements Controlling 128 LEDs via MIDI Sending 7bit MIDI events on rotary encoder movements Printing values on a LCD You can combine these examples to a bigger firmware and you could also adapt it for your own controlling requirements of course. You won't need a Core32 for such experiments, and the 32k flash of PIC18F452 should be sufficient for your firmware. It's really worth a try (as Ilmenator highlighted) :) Best Regards, Thorsten.

Hi, the vector table pointer is set in MIOS32_SYS_Init() The same function is used for Bootloader and Applications; the vector itself will be defined in the .ld file for highest flexibility (e.g. the application could locate the vector into SRAM if desired, e.g. for ISR pointers that are changed during runtime) Best Regards, Thorsten.

btw. (I just remember that I haven't mentioned this yet): there is a topic which has to be considered when using serial resistors at signal sources for smoothing the signal edges: higher resistances will make the transmission line less robust against noise resp. they will worsen EMC. In other words: a long transmission line acts like an antenna, and then higher the resistance between driver and logic inputs, than higher the danger that shift registers will get additional clocks (sporadically) in noisy environments (e.g. if you turn on/off another device) I agree that it makes sense to add line drivers for the "next generation" core32 module. It will be at least a 100pin device, so that we don't need to consider different SRIO routing options - we can just use one dedicated SPI port for this and it never has to be changed (e.g. if I2S audio chips should be accessed as well) We could even consider to add line drivers on each DOUTX4/DINX4 module - this would lead to the highest robustness and would also allow longer chains. Yes! Best Regards, Thorsten.

Port #3 is working like intended - from router.c: void ROUTER_Rx_IIC3(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { unsigned char transposed_note; // IIC3: connected to my Yamaha AN1x // lock/release this routing path on SysEx streams ROUTER_LockPathOnSysEx(PORT_IIC3, ptype); // filter clock if( evnt0 == 0xf8 ) return; if( ptype >= 0x08 && ptype <= 0x0e ) { // check if channel should be forced to specific value if( router_flags.IIC3_FWD_FORCE_CHN ) { evnt0 = (evnt0 & 0xf0) | (router_iic3_fwd_force_channel & 0xf); } // check if note should be transposed if( router_iic3_fwd_transpose != 8 && ptype <= 0x09 ) { if( router_iic3_fwd_transpose >= 8 ) { evnt1 += (router_iic3_fwd_transpose-8)*12; // if value >= 0x80, decrement 12 until we have reached the range <= 0x7f again while( evnt1 & 0x80 ) evnt1 -= 12; } else { evnt1 -= (8-router_iic3_fwd_transpose)*12; // if value < 0, add 12 until we have reached the range >= 0 again while( evnt1 & 0x80 ) evnt1 += 12; } } if( router_flags.IIC3_FWD_MBSID ) ROUTER_Tx_IIC0(ptype, evnt0, evnt1, evnt2); if( router_flags.IIC3_FWD_MBFM ) ROUTER_Tx_IIC1(ptype, evnt0, evnt1, evnt2); if( router_flags.IIC3_FWD_MBSEQ ) ROUTER_Tx_IIC2(ptype, evnt0, evnt1, evnt2); } // forward data (also) to the Core MIDI OUT #if 1 // if no FE if( evnt0 != 0xfe ) #endif if( !router_flags.IIC3_FWD_MBSID && !router_flags.IIC3_FWD_MBFM && !router_flags.IIC3_FWD_MBSEQ ) ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2); } [/code] If you want a similar behaviour like for IIC2 (note splitting; just replace the code of ROUTER_Rx_IIC3 by the code you will find in ROUTER_Rx_IIC2 [code] void ROUTER_Rx_IIC2(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { // IIC2: connected to my MIDIbox SEQ // lock/release this routing path on SysEx streams ROUTER_LockPathOnSysEx(PORT_IIC2, ptype); // forward MIDI clock/start/stop/continue to all IIC modules if( evnt0 >= 0xf8 && evnt0 <= 0xfc ) { ROUTER_Tx_IIC0(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC1(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC2(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC3(ptype, evnt0, evnt1, evnt2); } // if IIC2_FWD_CHN8_16 flag set: if( router_flags.IIC2_FWD_CHN8_16 && (ptype >= 0x08 && ptype <= 0x0e) && ((evnt0 & 0x0f) >= MIDI_CHN9) ) { // directly forward MIDI channel #9..#16 messages to MIDIbox SID and MIDIbox FM only ROUTER_Tx_IIC0(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC1(ptype, evnt0, evnt1, evnt2); } else { // forward all other events to the Core MIDI OUT ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2); } } or create your own "routing logic" - by changing the source code this MIDI Router is completely configurable! :) Best Regards, Thorsten.

Hi Simon, it was always unclear to me why you are not writing the whole application in C - it's much easier than adapting the assembly based MB64E firmware for your needs (especially since this firmware includes 90% features which you probably never use). Another advantage: once you learned programming in C, you can re-use your code (and knowledge) for MIOS32 based applications later. :) If you are searching for a text adventure, try the assembler approach. But if you are searching for some sparetime fun (!), you should definitely go for C :) Best Regards, Thorsten.

Hi, the most simple way to find this would be to change the MIOS32 environment variables before compiling any application (such as apps/templates/app_skeleton) So, instead of: export MIOS32_FAMILY=STM32F10x export MIOS32_PROCESSOR=STM32F103RE export MIOS32_BOARD=MBHP_CORE_STM32[/code] you would write: [code]export MIOS32_FAMILY=MYFAMILY export MIOS32_PROCESSOR=MYPROCESSOR export MIOS32_BOARD=MYBOARD All source codes and Makefiles which are checking/referencing to these values will print out an error message (sometimes very verbose since they are generated with #error) This simple check also gives you the files locations or directories where something has to be changed, resp. where a new directory with similar files has to be created. E.g., usually MIOS32 based applications don't refer to any driver functions under drivers/$MIOS32_FAMILY - this is only done under mios32/$MIOS32_FAMILY (the HW adaption layer, take the files in the mios32/STM32F10x directory as a reference), the programming_model/traditional (which will need some #ifdef statements for your environment) Means: probably you don't need to refer any "driver" functions at all if your SoC doesn't support such a library. Instead you would have to configure/access peripheral functions directly in the MIOS32 HW adaption layer Best Regards, Thorsten.

Simon asked me for help, but it's currently very difficult for me to find the time for giving an explicit example. However, here some hints: You need a variable which stores the patch number, another one which stores the bank number. Search in app_defines.h for free locations. E.g., 0x1d and 0x1e are not used yet (in MB64E!) - by adding MY_PATCH_NUM EQU 0x1d MY_PATCH_NUM EQU 0x1e[/code] these addresses are now yours! :) Now you have to create branches for all 4 buttons, similar to this example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox64e%2Fmeta_examples%2F2%2Fmb64e_meta.inc but you only need to consider the first four (MB64E_META_Handler_00 .. MB64E_META_Handler_03) - all others are not relevant and can be removed. [code] JUMPTABLE_2BYTES 4 ; 4 entries rgoto MB64E_META_Handler_00 rgoto MB64E_META_Handler_01 rgoto MB64E_META_Handler_02 rgoto MB64E_META_Handler_03 Now you implement the functions based on Nil's pseudo code. "inc" (increment) can be done with "incf <variable-name>, F", such as "incf MY_PATCH_NUM, F" "if( patch_num > 127 )" is a bit complicated in assembly language. The easiest way is to check if the 8th bit is set, such as btfsc PATCH_NUM, 7 clrf PATCH_NUM [/code] (see datasheet for a description of these instructions) Such a simple check isn't possible for checks != 2^n, such as "if( bank_num > 5 )" There are instructions for such comparisons, and I also have some macros, but they are complicated to use (if I haven't programmed assembly for more than one year - like currently - I would need at least two tries to get this working ;)) So, it's easier to make an equivalence check, such as "if( bank_num == 5 ) bank_num = 0" Resulting instructions: [code] movf MY_BANK_NUM, W xorlw 5 skpnz clrf MY_BANK_NUM Best Regards, Thorsten.

Shipped today: potain Duggle ted53 Eddie Chubaka psyreactor Will be shipped once I got the money: ssp runinit Please note: all PCBs are sold out! (the 4 last v1.1 PCBs are reserved for ssp, one for runinit) I've still 89 GM5 chips, + 20 that I already sent to Nils Since it's unlikely that we get 100 orders for the "mini PCB", the GM5 chips are now all reserved for next GM5x5x5 run and can be purchased via Nils. Best Regards, Thorsten.

After I read the blog and want to thank you for starting this report! It makes the signal integrity issue better understandable and will help us to give newbies some arguments, why SRIO chains are usually limited to 16 shift registers (longer chains could require expert knowledge and technical equipment to get stable transfers) There are two points I would like to add: we get a more difficult situation once a DIN chain is clocked by the SCLK signal in parallel to the DOUT chain: parallel chains can result into two "ringings" (one from the DOUT, one from the DIN chain - if they have different lengths resp. impedances. The situation will become even more difficult if DIN/DOUT registers are connected to SCLK in mixed order, in this case it can happen that the serial data won't be shifted correctly anymore due to setup/hold time violations caused by unbalanced clocks (with different delays) at SR inputs. This results into the effect that bits could be missed or added in the DIN and/or DOUT chain at random moments and positions (-> flickering LEDs, random button events) - this effect could vanish if you put your finger on the SCLK line (see also next point) by probing a signal with your scope you will add a capacitance to ground of ca. 10..100 pF (so far I remember, the value could be wrong or different for your scope). This has to be considered while comparing waveforms with theoretical calculations. This means in other words: currently your waveform looks nice, but once you remove the probe the "untouched signal" could be bad again. You won't see it (as you removed the probe ;)) Seppoman recommented AC termination to solve this - it works! E.g., at the end of the chain add a 100R +100 pF to ground (so far I remember, meanwhile he even prefers higher capacitances) Best Regards, Thorsten.

Great! And now have a lot of fun! :) Note: the labels are SI (like serial input) and SO (like serial output) Best Regards, Thorsten.

This feature which was available in V3 isn't implemented in V4 yet Best Regards, Thorsten.

No, it doesn't make a difference since the sequencer module (which is included into the project) provides an internal clock generator with Master, Slave and Auto Mode. By default it is in Auto mode, which means that it will automatically switch to Slave (-> external clock) once MIDI clock events are received Best Regards, Thorsten.

E.g. at Schaeffer - but I'm not sure if this is the cheapest solution. Good point (you know him very well ;)) In fact he already requested two cases as one of the first guys, but probably hasn't found out how to enter his name into the Wiki yet Best Regards, Thorsten.

Thanks for doing these experiments! In my snapshots I connected the DOUT/DIN modules over a very long cable (ca. 3 m) to increase the impedance. Normally I'm only using these snapshots to illustrate what I mean - the waveforms will always look different depending on the environment and the point from where the signals are probed. (e.g. interesting is a comparison between SCLK at the core and SCLK at the end of the chain by using two scope channels) Best Regards, Thorsten.

Shipping to the states: please align this with Nils, he will handle the shipping :) Best Regards, Thorsten.

Hallo Can, wenn Du den Ribbon Sensor loslaesst wird er hochohmig, und am AIN werden scheinbar zufaellige Werte konvertiert. Am besten schliesst Du am AIN Pin noch einen hochohmigen (bspw. 100k) Widerstand gegen Masse an - so wird die Eingangsspannung nach 0V gezogen und erreicht somit einen definierten Zustand, die von der Firmware ausgewertet werden kann. Zum Testen koenntest Du dann mal die Stribe Firmware aufspielen, die hat eine clever programmierte Erkennung fuer diesen Zustand eingebaut, siehe auch AIN_NotifyChange() in: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fstribe%2Fmain.c Gruss, Thorsten.

Did you install the 220 Ohm resistor array R31a/b/c/d on the MBHP_CORE_STM32 module? Best Regards, Thorsten.

Hi, you are searching for an arpeggiator function. Here is a programming example, but it will only run under MIOS32: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F018_arpeggiator%2F Similar things can be done with MIOS8 (on a less elegant way) based on this clockbox firmware: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fclockbox%2F Best Regards, Thorsten.

Bugfight: if login to the Wiki is still failing please contact Twin-X Since we already got more than 10 pre-orders for the case, I will ask Heidenreich for a first run with 10 pieces next week (this week the whole company is still on vacation). Upcoming runs could include higher quantities, but it's better to rampup this slowly. I finished my backpanel and will order it at Schaeffer today: It includes: A power socket + switch. The appr. "power board" will be provided by Wilba USB and 2 MIDI IO pairs of the MBHP_CORE_STM32 module slot for SD Card -> Seppoman's MBHP_SDCARD module OSC (ethernet socket) -> Seepoman's MBHP_ETH module 25 pin SubD socket for AOUT module connection + gates + clock outputs. I will assign the pins exactly like on my MB-6582, so that I can simply re-use the same breakout box for both MIDIboxes depending on the situation 4 additional MIDI OUTs and a BLM socket (7-pin DIN) soldered on a veroboard, since an appr. PCB doesn't exist I will make the .fpd file public once I got and tested the panel. A bulk order for such a panel will be difficult, as it's almost impossible to find a compromise. E.g., OSC is currently only a "nice-to-have" option, additional OUTs are expensive (since this option requires 4 MBHP_IIC_MIDI modules), BLM is not used by most people, and instead of a CV/Gates/Clk extension port some of you probably prefer an integrated solution. Therefore it's better when people modify and order such a backpanel individually. /update: picture of the backpanel: Best Regards, Thorsten.

Hi Rio, I can't check this by myself, since both of my MBSEQs are running with the V4 firmware meanwhile, and with this version the scenario is perfectly working (although I never tried this out before ;)) However, in the old V3 firmware it could be that this behaviour is caused by SEQ_TRKMODE_FLAG_RESTART not being cleared by SEQ_CORE_ResetTrkPos Could you please search in seq_core.inc for following lines: SEQ_CORE_ResetTrkPos ;; don't increment on the first clock event movlw SEQ_TRKVARSTATEx bsf PLUSW2, SEQ_TRKVARSTATE_FIRST_CLK [/code] and add following lines thereafter: [code] ;; clear position reset flag that was probably set in seq_midi.inc during stop mode bcf PLUSW2, SEQ_TRKVARSTATE_POS_RESET If this doesn't help, you will have to continue searching for a possible reason by exploring the source code. Remote diagnosis is too difficult (and from my previous experiences with you it can be very time consuming ;)) Best Regards, Thorsten.

It's inside the case, see also this picture: http://midibox.org/forums/index.php?app=gallery&module=images&section=viewimage&img=430 Your panel could be used after the rack ears are cut with a milling machine - maybe there is a company close to your location which could do this? It isn't much work, so it shouldn't cost that much money (maybe 10 EUR and/or a crate of beer ;)) Best Regards, Thorsten.

Yes, it will be anodized as well :) Best Regards, Thorsten.

yes, correct Best Regards, Thorsten.

Yes, it even contains a "dummy" backpanel if somebody wants to drill the holes by himself. :) Only the frontpanel is excluded to save costs. Mounting: see the comments of these pictures: http://midibox.org/forums/index.php?app=gallery&module=images&section=viewimage&img=423 http://midibox.org/forums/index.php?app=gallery&module=images&section=viewimage&img=424 Future frontpanels should have 1 mm extrusions to "stick" the panel into the frame. Best Regards, Thorsten.