TK.

Hallo, 4.6V ist ein wenig niedrig, doch noch im erlaubten Bereich. Wie hoch ist eigentlich die Spannung an J1? Am besten verfolgst Du nun mit Deinem Messgeraet die Leiterbahn zwischen dem Tx Pin und der restlichen Schaltung - siehe Schaltplan: http://www.ucapps.de/mbhp/mbhp_core_v3.pdf Vielleicht ist Pin #25 nicht richtig verloetet, oder zwischen diesem Pin und dem MIDI Ausgang befindet sich aufgrund eines Loetfehlers ein Kurzschluss nach Masse? Gruss, Thorsten.

SD Card and Ethernet are usually connected to J16. It is possible to connect a third device, but it should be clear to you that this slows down the overall performance of your application. J8/9 would be an alternative solution - you haven't listed DIN/DOUT, so this port is free. You would use the MIOS32_SPI* function to configure the SPI interface: http://www.midibox.org/mios32/manual/group___m_i_o_s32___s_p_i.html Configuring SPI for ca. 10 MHz clock isn't a problem (-> MIOS32_SPI_PRESCALER_8) MIOS_SPI* transfers data via DMA, so that this clock rate indeed improves the performance. Interrupt line: check which pins are free on your board, search in the STM32 datasheet for possible routings. On the other hand: I would prefer STM32F105x for this usecase. It has two integrated CAN controllers, and there is no conflict with USB. Accordingly the transfer performance will be much better, and the complexity will be reduced -> improved robustness. Disadvantage: it only has 256k flash maximum (yet) But since you are planning to split tasks over multiple chips anyhow, this shouldn't be a problem for you. Best Regards, Thorsten.

I guess that the blue "Luftpost" priority sticker speeds up the delivery dramatically! :) Following orders have been shipped today: drsyncenstein julianzizko chrisbob12 pataroulis lameth Joe56 Wild_Weasel Lu Taska grizz zen_audio kaleaf sunflower rhinoceros gomiboy99 Acidtracker shipped via Nils (soon): dcer10 Following orders will be shipped next weekend (once I got the money...) ssp runinit potain Best Regards, Thorsten.

With the session concept the format function under UTILITY->DISK got obsolete, therefore I removed it from the application (but haven't updated the documentation yet). E3 means that the volume information (part of the filesystem) couldn't been read E11 means, that a file couldn't been written Probably E11 is a side effect of E3 - means, there seems to be an issue with the format. Phil has created an application which formats a SD Card properly, it can be found here: (please continue discussion there) Best Regards, Thorsten.

Some informations are located in the hidden programmers section: Some others in a german thread: therefore you haven't got useful hits with the search function. Please keep us updated - you could create a blog to document your experiments, this would result into a handy link for me to give other people some more informations about this topic. I keep my own documentation effort low by setting the "not more than 16 DINs/DOUTs" rule ;) Yes, using multiple SPI ports would solve this as well. Best Regards, Thorsten.

Hi Doug, It's hardcoded in mios32_srio.c, but already configured for the lowest frequency. However, reducing the clock rate won't allow you to extend the chain, because the impedance is the parameter which limits the length! A refresher (I wrote about this multiple times in the forum, therefore only the reduced summary): See this snapshot (measured on a PIC with a superlong SRIO chain, but for STM32 it would look similar): The transients on SCLK line overshoot VH/VL, this will lead to non-deterministic clocking of the serial registers. For STM32 the situation is even more critical if SPI pins are configured for push-pull mode, where signals are working at 3.3V Therefore I decided to configure the pins for open drain mode, and to pull the signals to 5V. This results into such sexy curves: But experiments showed me, that the Logic-0 and 1 get above/below the threshold levels of the HCT chip family once more than 20 DINs and DOUTs are chained. Yes, using buffers will cost you some additional chips, but it will help. Take care that SCLK/RCLK have to be buffered separately for DIN/DOUT chain. And buffers should be integrated along the chain, don't use starlike wiring, because this can result into setup/hold violations caused by unbalanced delays between FF clock and input! Buffer IC: I tried a 74HC541 some time ago - it works, but has more buffers than really required (as mentioned earlier, starlike wiring, resp. using one buffer IC to distribute the SCLK for all DIN/DOUT chips is not recommented) There are probably similar chips with lower pin-count If you've SMD soldering experiences, such an option would be preferred Best Regards, Thorsten.

The usage of serial registers give us the advantage that remaining IOs are free for other purposes. Since most of bigger applications get use of all available pins, SRIO is the first choice and therefore the standard. (*) Scanning the SRIOs doesn't really take that much CPU time, as MIOS32 handles the (hardware) SPIs via DMA transfers in background. While the complete SRIO chain is scanned, the CPU is doing something else. Therefore the serial clock rate doesn't matter (I selected a slow clock rate to make the transfers more robust). Only the propagation of pin changes to the application takes CPU time, but a handler for parallel IOs would have to do exactly the same! Note that it is possible to call MIOS32_SRIO_ScanStart() from the application to scan the SRIO more frequently. This will require to remove the MIOS32_SRIO_ScanStart(SRIO_ServiceFinish); call in vApplicationTickHook - I could add a #ifndef based switch if you want, so that this code doesn't need to be modified. Instead you would enable this switch in your mios32_config.h file, and call MIOS32_SRIO_ScanStart from a timer function (-> MIOS32_TIMER) embedded into your app.c file at the desired frequency. I don't see the need to integrate an alternative method into MIOS32, but nobody prevents you (or somebody else) from writing a driver for parallel scanning and to put it into $MIOS32_PATH/modules so that other applications can access it. In difference to MIOS8, MIOS32 is very modular (e.g. it's possible to remove the software parts which scan the SRIO chains from the binary). Or to disable the default scanning method and to do it on a different way (e.g. more frequently) as described above. Everything which is special and not used by most of the applications should be located under $MIOS32_PATH/modules This has the advantage that multiple solutions for the same "function(s)" can be provided and selected by the application. You are writing that there isn't a MIOS32 equivalent to STM32F10xgpio c This isn't completely true - because this driver provided by STM is already compiled into each application (the sources are here) so that you can already use these functions w/o Makefile modifications. You are even able to re-use most of the example applications provided by STM for the first experiments if you remove the system initialization parts that are mostly located in the main.c file of these examples (because the system is initialized by MIOS32_SYS_Init) Best Regards, Thorsten. (*) another reason for using SRIO is, that they are working at 5V level instead of 3.3V, and that 74HC595 can drive multiple LEDs w/o loading the microcontroller. This isn't relevant for your plans, but I think that I should highlight this to make clear why SRIO is better for most applications.

Shipped today: rmouneyres michael123 afx socrates antix Napiks meimaddin reincarnate glacial23 efluon altitude jrock keyg artyman henk gomiboy99 tamiflu paulb Buriedcide Boops shipped via Nils (soon): dcer10 Following orders will be shipped next friday (once I got the money...) julianzizko lameth ssp Joe56 runinit Best Regards, Thorsten.

I described the details somewhere in the forum, but I'm too lazy to use the search function. ;) Changing channels: can be done via CCs CCs can be sequenced. CC Layers are stored in a track. So: yes, it's already possible. Best Regards, Thorsten.

I will ship already paid GM5 orders probably this Thursday. Next shipping day would be friday next week. The ordering procedure is described in the Wiki: http://www.midibox.org/dokuwiki/doku.php?id=tk_gm5_bulkorder Best Regards, Thorsten.

Gridracer: your idea isn't lost - I like it and will see what I can do. Echopraxia: the recommended method is to store the complete track from which the drum map should be exported into a preset (MENU->EVENT->PRESET->SAVE AS NEW PRESET) Now you can import the drum map into another track with the PRESET function as well. Note that you will be asked for several import options, e.g. you can exclude the pattern import (Steps: no), etc. This function not only works for importing/exporting drum maps, but for anything related to a track. It's the most powerful copy function (especially since you are able to edit preset files with a text editor) - you will like it! :) Best Regards, Thorsten.

Thanks for joining the order! :) PMs with order details are sent. Attention Ankage: I can't determine your forum name Attention JuliaDee: I can't determine your forum name Attention Kabbi: I can't determine your forum name Attention Chrisbob12: your email address (...@lineone.net) is invalid, therefore the PM wasn't forwarded to your email account. Attention Bastard3b: your email address (...@freenet.de) is invalid, therefore the PM wasn't forwarded to your email account. Attention Zenguru: your email address (...@evtek.fi) is invalid, therefore the PM wasn't forwarded to your email account. Best Regards, Thorsten.

Hi Martin, ok from my side, especially if you sell the sammichSID to a forum member. :) Best Regards, Thorsten.

habe ihn via PM verpetzt ;) Best Regards, Thorsten.

svn is working again :) Best Regards, Thorsten.

Thats really a FAQ and I can only say: don't trust on "max allowed" values... Connections between the BLM_SCALAR modules (especially SCLK and RCLK) should be as short as possible! Try your best! Optimize it to the minimum cable length! Too long clock lines will result into flickering LEDs and unstable button states. The prototype will show the robustness in reality. Take the cable lengths of my prototype as example - it still works very stable. The cable/track length between BLM_SCALAR and LEDs/Buttons doesn't really matter. Best Regards, Thorsten.

In some modes MBSEQ rotates the screen by 90°, e.g. when velocity/length/probability/... or mixer parameters are edited. Therefore 16x16 (+ the extra buttons of course) is a must, supporting reduced BLM16x16+X layouts would result into a nightmare at my side! Best Regards, Thorsten.

wow! Best Regards, Thorsten.

This can be decided layout-driven (there are multiple possibilities) - for extra buttons it's only important that each button/LED combination is individually accessible in the matrix. (I will check your layout once it's finished) Best Regards, Thorsten.

Looks good so far! The 8x8 based variant would look similar, but currently I don't have the time to draw the schematic. You would create a schematic anyhow, so let's save this effort - I will explain it instead. If LEDs/Buttons are numbered this way: EC1 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 EC2 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15 B16 EC3 C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 C16 EC4 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 D16 EC5 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11 E12 E13 E14 E15 E16 EC6 F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15 F16 EC7 G1 G2 G3 G4 G5 G6 G7 G8 G9 G10 G11 G12 G13 G14 G15 G16 EC8 H1 H2 H3 H4 H5 H6 H7 H8 H9 H10 H11 H12 H13 H14 H15 H16 EC9 I1 I2 I3 I4 I5 I6 I7 I8 I9 I10 I11 I12 I13 I14 I15 I16 EC10 J1 J2 J3 J4 J5 J6 J7 J8 J9 J10 J11 J12 J13 J14 J15 J16 EK11 K1 K2 K3 K4 K5 K6 K7 K8 K9 K10 K11 K12 K13 K14 K15 K16 EC12 L1 L2 L3 L4 L5 L6 L7 L8 L9 L10 L11 L12 L13 L14 L15 L16 EC13 M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 EC14 N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 EC15 O1 O2 O3 O4 O5 O6 O7 O8 O9 O10 O11 O12 O13 O14 O15 O16 EC16 P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 EC17 X1 X2 X3 X4 X5 X6 X7 X8 X9 X10 X11 X12 X13 X14 X15 X16 we would: connect BLM_SCALAR::J3_1:C0..C7 with the cathodes of EC1+A1..A8, EC2+B1..B8, ... EC8+H1..H8 connect BLM_SCALAR::J3_1:G0..G7 with the green anodes of A1..H1, A2..H2, ... A8..H8 connect BLM_SCALAR::J4_1:R0..R7 with the red anodes of A1..H1, A2..H2, ... A8..H8 connect BLM_SCALAR::J4_1:I0..I7 with the buttons of A1..H1, A2..H2, ... A8..H8 connect the green anodes of EC1..EC8 with BLM_SCALAR::J3_5:G0 connect the red anodes of EC1..EC8 with BLM_SCALAR::J4_5:R0 connect the buttons of EC1..EC8 with BLM_SCALAR::J4_5:I0 Do you see the logic behind this matrix routing, or do you need additional explanations? Best Regards, Thorsten.

Good news: I will get a batch of 250 GM5 chips from Ploytec very soon! If you are interested, please add your name and the quantity to this list: -> http://www.midibox.org/dokuwiki/doku.php?id=tk_gm5_bulkorder Best Regards, Thorsten.

Hi, thats easy, as encoder pinnings are defined in a table: From http://www.ucapps.de/mios_c_send_enc_abs7.html MIOS_ENC_TABLE { // sr pin mode MIOS_ENC_ENTRY( 1, 0, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 1 MIOS_ENC_ENTRY( 1, 2, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 2 MIOS_ENC_ENTRY( 1, 4, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 3 MIOS_ENC_ENTRY( 1, 6, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 4 MIOS_ENC_ENTRY( 2, 0, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 5 MIOS_ENC_ENTRY( 2, 2, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 6 MIOS_ENC_ENTRY( 2, 4, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 7 MIOS_ENC_ENTRY( 2, 6, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 8 MIOS_ENC_EOT }; [/code] your table (that you unfortunately forgot to post here - it would simplify things) has probably following entries: [code] MIOS_ENC_TABLE { // sr pin mode MIOS_ENC_ENTRY( 5, 0, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 1 MIOS_ENC_ENTRY( 5, 2, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 2 MIOS_ENC_ENTRY( 5, 4, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 3 MIOS_ENC_ENTRY( 5, 6, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 4 MIOS_ENC_ENTRY( 6, 0, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 5 MIOS_ENC_ENTRY( 6, 2, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 6 MIOS_ENC_ENTRY( 6, 4, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 7 MIOS_ENC_ENTRY( 6, 6, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 8 MIOS_ENC_ENTRY( 7, 0, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 9 MIOS_ENC_ENTRY( 7, 2, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 10 MIOS_ENC_ENTRY( 7, 4, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 11 MIOS_ENC_ENTRY( 7, 6, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 12 MIOS_ENC_EOT }; You want to map 1->1 2->2 5->3 6->4 9->5 10->6 3->7 4->8 7->9 8->10 11->11 12->12 Accordingly you have to swap some table entries: MIOS_ENC_TABLE { // sr pin mode MIOS_ENC_ENTRY( 5, 0, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 1 MIOS_ENC_ENTRY( 5, 2, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 2 MIOS_ENC_ENTRY( 6, 0, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 5 -> now 3 MIOS_ENC_ENTRY( 6, 2, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 6 -> now 4 MIOS_ENC_ENTRY( 7, 0, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 9 -> now 5 MIOS_ENC_ENTRY( 7, 2, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 10 -> now 6 MIOS_ENC_ENTRY( 5, 4, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 3 -> now 7 MIOS_ENC_ENTRY( 5, 6, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 4 -> now 8 MIOS_ENC_ENTRY( 6, 4, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 7 -> now 9 MIOS_ENC_ENTRY( 6, 6, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 8 -> now 10 MIOS_ENC_ENTRY( 7, 4, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 11 MIOS_ENC_ENTRY( 7, 6, MIOS_ENC_MODE_NON_DETENTED), // V-Pot 12 MIOS_ENC_EOT }; [/code] hope this makes sense Best Regards, Thorsten.

No his isn't possible, and as mentioned earlier, it's easier and faster (performance wise) to change this on your hardware. Best Regards, Thorsten.

Hallo, das ist eine relativ einfache Programmieraufgabe. Hier die Funktion, mit der Du 9 frei konfigurierbare CCs versenden kannst: #define NUM_CC 9 unsigned char ccNumber[NUM_CC]; unsigned short ccStates; void sendCCs(unsigned short flags) { unsigned char i; for(i=0; i<NUM_CC; ++i) { unsigned onOff = ccStates & (1 << i); // send CCs MIOS_MIDI_TxBufferPut(0xb0); // CC at MIDI Channel #1 MIOS_MIDI_TxBufferPut(ccNumber[i]); MIOS_MIDI_TxBufferPut(onOff ? 127 : 0); // set LED as well MIOS_DOUT_PinSet(i, onOff ? 1 : 0); } } [/code] ccNumber ist ein Array, in dem Du die entspr. Werte ablegst. Entweder statisch gesetzt (in Init()...), oder aus einem EEPROM geladen (-> MIOS_EEPROM_* funktionen) ccStates ist ein 16 bit Wert, der den Toggle-Status der 9 Taster enthaelt. Die Bits lassen sich mit (1 << i) addressieren. Wenn Du nun (bspw. aus dem DIN_NotifyToggle Hook) ein bit setzen willst, schreibst Du "ccStates |= (1 << pin)", und zum Loeschen schreibst Du "ccStates &= ~(1 << pin);" Mehr Programmierdetails unter: http://www.ucapps.de/mios8_c.html Gruss, Thorsten.