ilmenator

You may find more enthusiasm once people actually knew how much they could save compared to the original solution - how much was that again (not Schaeffer's price, but your's)?

Oh, I see. You don't want to do it that way, then. It might be okay for a prototype setup to test things, but I would definitely not recommend this as a final solution. Also, your board will then be probably rather large, which creates some extra leverage. But, maybe you could use the SIL headers on the base PCB (those north and south of the PICs) just for mechanical stabilization, like a sort of "blind" headers?

"Stacking" boards is very common practice, just google for "Arduino Shield" and you will find millions of add-on boards meant to be stacked on top of little microcontroller boards. I guess you are talking about having the control surface board and the base board at a 90 degrees angle to each other, using angled headers then?

So how much do you charge for this, and how does it compare to the other one?

I'd say without the math (and some hard numbers) all is speculation...

Thanks Rufus, apparently I missed your reply, when I get access to a proper computer again I'll look at the schematics and see if it works the same way in my B75. Best, ilmenator

Yes, come here and check the forum from time to time. Visiting frequency would depend on how sure you want to be not to miss the next bulk order for knobs.

Come on, are you serious? If this was business and you were a customer that could be made money from, then maybe...

For features (and differences) see here: PIC 18F4685 or PIC 18F4620. Plus there's the older =452]PIC 18F452 with basically less RAM but still good (and recommended) for MIDIbox64.

Yes, that's right!

We do audio, video, and audiovisual quality assessments on a regular basis, sometimes involving MIDIboxes as input controllers. There is a huge number of different experimental setups you can choose from, depending on what the research question is. One of the main principles in these experiments is that you never ever ask questions in a suggestive way, and of course that you keep all parameters controlled so that you really "measure" the one variable you are interested in. Consistently identifying small differences usually requires a lot of training for test subjects, and even then the notion of "better" or "worse" sound can be astonishing. MP3 generation anyone :D ?

No

For a C program, you would add something like __asm clrwdt __endasm; to your code. Best, ilmenator

Rufus, do you happen to have some documentation for the B405 or a description of how the inputs are multiplexed? I will face a similar problem soon (MIDIfying a B75 organ keyboard), and I could not find a service manual yet...

You want DIN for the buttons.

I have finally finished an "old" Core32 board - it is an STM32_V2. Upload of bootloader / application via ROM based UART Bootloader was successful. Unfortunately, there is something wrong with the USB part. Windows 7 sees a new device when I plug it into the PC's USB connector, but it does not recognize it, and will not install any device drivers. USB power works fine, and MIDI in/out 1 and 2 also work as they should, i.e. I can upload new applications via MIOS Studio etc. But the MIOS32 device does not show up, as it does not get installed... This is on two different Win 7 machines, so there is probably something wrong with the board. Where should I look for faults?

Thanks - will do that.

Well, I am not sure, I can see the codesourcery folder name, but I have installed the toolchain according to the instructions in the WIKI. That was about 10 months or so ago.

Looking into the neighboring folder, \mios32\trunk\bootloader\updater, I found the update which compiles fine and seems to be ok to use on a virgin STM32, according to the readme. I can flash the bootloader okay, and afterwards the two MIDI ports work okay. Unfortunately, there is something wrong with the USB port. Windows 7 does not recognize the device and fails to install proper drivers. This is on an STM32_V2 board, and I am wondering if this is somehow related to R3 which I could not stuff, as I could not find any info on this. It is located next to J27, the boot jumper, and as I could not find any info on it I left it open.

I've been trying to compile the bootloader for STM32 core, as I have a "virgin" chip and want to program it via ROM based UART Bootloader as described here. I have done this before, but for some reason the compile action fails. "Normal" code compilation works, but with the bootloader I get the following error message: CD: C:\mios32\trunk\bootloader\src\ Current directory: C:\mios32\trunk\bootloader\src make Process started >>> make -f Makefile.bsl_MBHP_CORE_STM32 cleanall make[1]: Entering directory `/c/mios32/trunk/bootloader/src' rm -rf project_build rm -f project.hex make[1]: Leaving directory `/c/mios32/trunk/bootloader/src' make -f Makefile.bsl_MBHP_CORE_STM32 make[1]: Entering directory `/c/mios32/trunk/bootloader/src' rm -f project.hex Creating object file for startup_stm32f10x_hd.c Creating object file for main.c Creating object file for bsl_sysex.c bsl_sysex.c: In function 'BSL_SYSEX_Cmd_WriteMem': bsl_sysex.c:293: warning: suggest parentheses around assignment used as truth value Creating object file for mios32_srio.c Creating object file for mios32_din.c Creating object file for mios32_dout.c Creating object file for mios32_enc.c Creating object file for mios32_lcd.c Creating object file for mios32_midi.c c:/mios32/trunk/mios32/common/mios32_midi.c: In function 'MIOS32_MIDI_SYSEX_Cmd': c:/mios32/trunk/mios32/common/mios32_midi.c:1479: warning: implicit declaration of function 'BSL_SYSEX_Cmd' c:/mios32/trunk/mios32/common/mios32_midi.c: In function 'MIOS32_MIDI_SYSEX_Cmd_Query': c:/mios32/trunk/mios32/common/mios32_midi.c:1562: warning: implicit declaration of function 'BSL_SYSEX_ReleaseHaltState' Creating object file for mios32_osc.c Creating object file for mios32_com.c Creating object file for mios32_uart_midi.c Creating object file for mios32_iic_midi.c Creating object file for mios32_iic_bs.c Creating object file for mios32_mf.c Creating object file for mios32_sdcard.c Creating object file for mios32_enc28j60.c Creating object file for mios32_bsl.c Creating object file for mios32_sys.c Creating object file for mios32_irq.c Creating object file for mios32_spi.c Creating object file for mios32_i2s.c Creating object file for mios32_board.c Creating object file for mios32_timer.c Creating object file for mios32_stopwatch.c Creating object file for mios32_delay.c Creating object file for mios32_ain.c Creating object file for mios32_usb.c Creating object file for mios32_usb_midi.c Creating object file for mios32_usb_com.c Creating object file for mios32_uart.c Creating object file for mios32_iic.c Creating object file for printf-stdarg.c Creating object file for stm32f10x_gpio.c Creating object file for stm32f10x_flash.c Creating object file for stm32f10x_adc.c Creating object file for stm32f10x_dac.c Creating object file for stm32f10x_spi.c Creating object file for stm32f10x_usart.c Creating object file for stm32f10x_i2c.c Creating object file for stm32f10x_dma.c Creating object file for stm32f10x_tim.c Creating object file for stm32f10x_rcc.c Creating object file for stm32f10x_rtc.c Creating object file for stm32f10x_bkp.c Creating object file for stm32f10x_pwr.c Creating object file for misc.c Creating object file for core_cm3.c Creating object file for usb_core.c Creating object file for usb_int.c Creating object file for usb_mem.c Creating object file for usb_regs.c Creating object file for otgd_fs_cal.c Creating object file for otgd_fs_dev.c Creating object file for otgd_fs_int.c Creating object file for otgd_fs_pcd.c c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/bin/ld.exe: project_build/project.elf section `.text' will not fit in region `FLASH' c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/bin/ld.exe: region `FLASH' overflowed by 848 bytes collect2: ld returned 1 exit status make[1]: *** [project_build/project.elf] Error 1 make[1]: Leaving directory `/c/mios32/trunk/bootloader/src' make: *** [MBHP_CORE_STM32] Error 2 <<< Process finished. ================ READY ================ I have not changed anything in the code itself, it is what is in the repository under \mios32\trunk\bootloader\src Thanks for looking, ilmenator

Oh boy, it seems that E-MU went so cheap in their final days they could not even afford proper encoders (or proper markings on them) by then. On my ESIs and E-5000 they used proper Bourns encoders, but that was a few years before the MP-7 came out. I'm not saying that the Bourns encoders were of high quality, but at least they were easy to identify and replace.

That might well be your problem. The one encoder that was in there originally should bear some model name or number. With that you could identify pin-out and look for alternatives.

Ugly... Anyways, I would not assume that the left side pin is not connected - that would not make sense, we all know how rotary encoders work, after all ;-). Also, it does not make sense to use multi-layer boards for something that low-complexity. There must be a track on the upper side of the board, but under the encoder. Remove the frontpanel, then you should be able to see it. The "empty tiny pad hole" is just a via, where the track goes from top to bottom layer. Once you have removed the front panel, measure if there is continuity between each leg of the encoder and the nearest component (e.g. resistor) or via. If this is the case, your encoder might be busted. If not, you will have to solder again. Good luck! PS: This is a very good example why one should not go with the minimum trace width the board house offers, when designing a PCB. This wouldn't have happened if EMU had chosen to use wider tracks...

Size of the boards is usually a problem - the smaller the board, the more expensive it gets. There are, however, web sites that offer PCB space to share with others, thus reducing costs significantly. I have recently bought from here, and I can only recommend this highly! The only minor "issue" might be that you will have to buy boards in multiples of three.

If you rotated the IC by 90 degrees you would probably get away with less cutting of the strips?