TK.

...is now available for download: http://www.ucapps.de/mios_download.html Most of the requested features of the last months (but also my private wishes) have been implemented (hope that the guys are still reading this forum ) -> http://www.ucapps.de/midibox_seq_changelog.html The remaining feature requests can be found at the bottom of CHANGELOG.txt Best Regards, Thorsten. /Edit: uploaded v3_4 again due to another improvement for the MENU button function

It could be a PSU issue - which voltage do you read between Vss/Vdd, and Vss/WC# of each BankStick? Does Vss/Vdd change while the the BankStick is formatted? Best Regards, Thorsten.

Inspirative! :) This is how I protect my GM5x5x5 from dust - I just mounted it under a table: It's well hidden, but still easily accessible w/o moving the table - an ideal solution for prototyping: Best Regards, Thorsten.

Hi Mike, due to resource limitations of the PIC (RAM/Flash/Timers) it's unlikely that I will be able to provide a better quantisation algorithm for MBSEQ V3. It will be a piece of cake for MBSEQ V4 on the STM32, especially because I already adjusted the programming concepts to simplify the implementation of certain feature requests. Best Regards, Thorsten.

We neither connect 5V directly to the SD Card output, nor we ground the pin. The current drain through the 10k pull-device is (only) ca. 0.5 mA when SD Output=0V, ca. 0.17 mA when SD Output=3.3V, and 0A when SD output in tristate (CS not enabled). I'm writing approximated values, as the voltage level at SD output won't be exactly 3.3V, but a bit higher caused by the pull-up resistor and the output impedance - which is advantageous! Because it shifts the voltage level much higher than PIC's Vih_max=3.0V (@5V supply) - as an effect, faster transfers are possible. If you would use a pull-down, the effective high level could be lower than 3V, the slope on signal changes would be weak, etc... -> slower transfer rates Best Regards, Thorsten.

Maybe an understanding problem: If the SD Card is not connected (not plugged into a SD Card slot), the core should read a static value. It doesn't really matter the core reads 1 or 0 - 1 is the best choice, as the pull-up is already available and accordingly no changes are required on the core module. If you notice a problem with this design measure, please let me know - it works fine at my side :) From your questions I suppose, that SD Card accesses are not working? Or why do you post this in the Troubleshooting section? Could you please describe your observations more concretely? Best Regards, Thorsten.

Block reads < 512 bytes should always work if the CS line is deactivated after the transfer. If you store 64 bytes payload in each 512 byte sector, there shouldn't be a speed disadvantage (in distance: access times are still higher) For writes operations 512 bytes have to be transfered, though. But programming a 512 byte sector is still faster than programming a 64 byte page of a BankStick Best Regards, Thorsten.

Just check the opcodes in the listing (project.lst): SDCARD_1uS_Delay 003ae8 d000 bra 0x3aea bra $+2 003aea d000 bra 0x3aec bra $+2 003aec d000 bra 0x3aee bra $+2 003aee d000 bra 0x3af0 bra $+2 003af0 d000 bra 0x3af2 bra $+2 [/code] Offset is 0 -> PC will jump to +2 location If the assembler would handle labels the way you explained, you would have to write "rcall SDCARD_1uS_Delay-2" instead of "rcall SDCARD_1uS_Delay" Btw.: I changed the function name. Oh - and before you are speculating about delays even more: in fact, calling the 1uS delay function will consume more than 10 cycles, since the call itself + the return instruction will cost +3 cycles (so far I remember) Hope that you don't mind, that I don't change this - it doesn't hurt to clock the SD card a bit slower after power on Best Regards, Thorsten.

It looks like a software issue, but I've no explanation under which circumstances it could fail this way. Ok, only assumption: somewhere MIOS_BOX_CFG0 is overwritten - but I should notice this on my MBLC as well Best Regards, Thorsten.

Note that I'm using a LM317 based voltage regulator to supply the SD card (same circuit as for the MBHP_USB module). Also a LF33 could be used (same circuit as for the MBHP_CORE_STM32 module) to ensure stable power supply. The diode circuit could work at your side (as it worked for Ilmenator), but there is no guarantee I haven't removed this resistor to ensure that the core will read static-1 if no SD card is connected. Yes - with higher resistor values the level conversion will get unstable depending on the input impedance SD card. Best Regards, Thorsten.

What happens if LC_STAT, LC_STAT_GLCD is explicitely set? (just remove btfsc instruction and build a new .hex file) Best Regards, Thorsten.

Thats really strange - MBLC should switch to GLCD mode if the LCD driver notifies that this capability is available: Inside USER_Init (-> main.asm) ;; use LC_STAT.LC_STAT_GLCD as indicator if graphical LCD ;; or character LCD is connected bcf LC_STAT, LC_STAT_GLCD btfsc MIOS_BOX_CFG0, MIOS_BOX_CFG0_USE_GLCD bsf LC_STAT, LC_STAT_GLCD [/code] Accordingly no source code or setup change is required, it should work with the prebuilt .hex files. Especially with setup_midibox_tk.hex, as this is the file I'm using for my own MBLC - when you apply a diff over the setup_*.asm files, you will notice that the only difference is the default value of "TOUCH_SENSOR_MODE"... So - please don't change the source code. Remove your changes (or rename the directory), and start with the original release. Could it be, that you are trying an expired release package which doesn't provide this "GLCD selfdetection" mechanism? And are you using the original pic18f452/midi/mios_v1_9f_pic18f452.hex file, or did you build (and modify) MIOS by yourself? Best Regards, Thorsten.

http://www.midibox.org/forum/index.php/topic,10421.msg78755.html#msg78755

It's my intention to give the new mode a cheesy name! For the case that you haven't noticed it yet: the name "Super-Poly" was already a joke... You can call it SDP mode if you don't like this kind of humor ;) Best Regards, Thorsten.

I already fixed these bugs, the new code is in the repository (see comments in the logs) and will be released very soon. However, there are still situations where the SIDs can go out of sync, e.g. if a huge bulk of SysEx data is received in parallel to MIDI notes (a MIDI IN buffer overrun will happen). A different, more complicated concept is required to solve this failsave (centralised voice assignments handled via CAN). I'm not sure if I will implement this for the PIC based solution, or if it will be only available for a future STM32 based solution (where I'm planning a Super-Duper-Poly Mode with 8 individual voices :)) Best Regards, Thorsten.

Ok, so the displays are working with non-inverted CS The left GLCD works as expected, the right GLCD shows a scrambled screen. Since my 240x64 display uses 4 CS lines, and the demo screen (as well as MBLC screen) is displayed correctly, my assumption is a wiring error. Could it be, that the CS3 line of the right GLCD is always enabled (=1), because it shows all components of the screen. CS line mapping: USER_LCD_LAT_CS1 EQU LATC ; Pin C.5 USER_LCD_PIN_CS1 EQU 5 USER_LCD_LAT_CS2 EQU LATC ; Pin C.4 USER_LCD_PIN_CS2 EQU 4 USER_LCD_LAT_CS3 EQU LATD ; Pin D.0 USER_LCD_PIN_CS3 EQU 0 USER_LCD_LAT_CS4 EQU LATC ; Pin C.2 USER_LCD_PIN_CS4 EQU 2 It could be a bridging fault (check your solderings) Best Regards, Thorsten.

If you know, how to edit this code, it will be possible for you to do such modifications. This is the current LED/Button setup Best Regards, Thorsten.

How does it work now when inversion is disabled in the main.asm file? Best Regards, Thorsten.

Are you able to re-assemble the code? I think that I found a MPASM->GPASM conversion error in app_lcd.inc: USER_LCD_DetermineCS SET_BSR MIOS_LCD_OPTION1 BRA_IFSET MIOS_LCD_OPTION1, 0, ACCESS, USER_LCD_DetermineCSInv [/code] Should be: [code] USER_LCD_DetermineCS SET_BSR MIOS_LCD_OPTION1 BRA_IFSET MIOS_LCD_OPTION1, 0, BANKED, USER_LCD_DetermineCSInv If you are not able to modify and rebuild the code, please let me know and I will send you a new .hex file Best Regards, Thorsten.

See README.txt o setup_j5_enabled.hex (similar like setup_default, but MBHP_CORE::J5 enabled for 8 gate outputs)[/code] And from the Webpage Best Regards, Thorsten.

It looks like the CS lines have an inverted polarity. Could you please try this test application: http://www.ucapps.de/mios/lcd7_ks0108_v2.zip The ASM version has inverted CS lines enabled by default, so that you can try it out w/o rebuilding a .hex file The C version has inversion disabled Note that the inbuilt GLCD driver of MIOS allows to invert the polarity as well. I can search for the details once I know if this is the issue... Best Regards, Thorsten.

or a single STM32F103RE for EUR 12? ;) Note that a lot of code (e.g. timestamped MIDI handler which allows to pregenerate streams) already exist, since MBSEQ V4 - but also vX32 - are working very similar... but it seems that you are just searching for a challenge ;) Best Regards, Thorsten.

But you could prepare placeholder files (e.g. bank1.bin, bank2.bin, ... bank1000.bin) which are large enough to hold as much data you need. See also Ilmenator's project. Advantage of FAT: you can easily copy files between your PC and MIDIbox w/o time consuming SysEx transfers Disadvantage: searching files in a large directory increases the latency if cluster references are not buffered in RAM. And once the number of sectors is higher than a single cluster, you will notice some additional latency due to FAT accesses. Advantage of your own FS: you can optimize it for your needs (e.g. direct sector addressing, no allocation table) Disadvantages: reverse advantages of FAT However, for your project I guess that using an own FS is the better idea due to low latency requirements and RAM limitations of the PIC There is no advantage by using these serial flash chips, since the PIC slows down the data rate, not the memory (SD Card is already accessed as fast as possible) wasted money, wasted development time... Best Regards, Thorsten.

And especially here: SD Card Driver Demo Applications Best Regards, Thorsten.

press SHIFT + modulation column button good idea good idea. But question: which button combination should be used without the need for adding more buttons? Best Regards, Thorsten.