TK.

Evtl. liegt das Problem bei den restlichen Verbindungen zwischen SID und Core Modul. Hast Du schonmal den SID Interconnection Test ausprobiert? Damit kann man mit Hilfe eines Messgeraets ueberpruefen, ob der Core die Daten-, Adress- und Controlpins setzen kann. Gruss, Thorsten.

Cool! :smile: I just have release a new version: MIDIbox NG V1.012 ~~~~~~~~~~~~~~~~~ o The application boots a little bit faster now o support for more than 2 LCDs. A documentation can be found under http://www.ucapps.de/midibox_ng_manual_lcd.html Have fun! :smile: Best Regards, Thorsten.

With V1.012 the Multi-LCD handling is fully integrated. The buffer size has been increased (again) to cover multiple GLCD displays. Documentation: http://www.ucapps.de/midibox_ng_manual_lcd.html Best Regards, Thorsten.

Hi, MIDIbox SEQ has all these features, see also http://www.ucapps.de/midibox_seq_manual_m.html (search for the places where the keyword arpeggiator is mentioned). But: for your plans it's a bit overweighted, because I guess that you want a small unit - like the midipal - with just some additional buttons? Something like this hasn't been developed for the MIDIbox platform yet, but for the case that you would like to implement it by yourself: the basic pieces are there - and they are working pretty well (most of the introduced library elements are part of MIDIbox SEQ) See also following tutorials: http://www.ucapps.de/mios32_c.html Tutorial #018 shows how to implement a very simple arpeggiator. The previous tutorials explain, how to handle buttons and encoders. It makes sense to read the tutorials from the beginning to get a basic understanding about the MIOS32 architecture. Best Regards, Thorsten.

I've updated the KS0108 interconnection diagram, so that it also shows the connections to J28 of the MBHP_CORE_LPC17 core: http://www.ucapps.de/mbhp/mbhp_lcd_ks0108_mios32.pdf Best Regards, Thorsten.

WinXP isn't a 64bit OS, therefore you can't install a 64bit driver... It looks like a Windows issue which I can't solve anyhow. Good that it works with newer Windows versions. Best Regards, Thorsten.

I created a separate topic. In order to get a better understanding of this issue, it would be interesting if the bulk transfers are working when only a single USB port is enabled? Please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_012_pre1_singleusbport.zip (Core module has to be re-powered after installation, MIOS Studio has to be restarted after power-cycling) And please try it with and without the GM5 driver Best Regards, Thorsten.

Since the correct SysEx message is received by MIOS Studio, and your MIDI interface correctly transfers loopbacked data, the issue is located around the MIDI IN circuit of sammichSID. Therefore it makes sense to continue the TEST IN checks: TEST IN2 isn't relevant for sammichSID (the sockets are directly soldered on the PCB) But the remaining IN tests are definitely for interest - do you have a spare LED for these tests? Best Regards, Thorsten.

No, the schematic is matching with the silkscreen on the PCB (prototype and final version). Could it be, that the socket is soldered in the wrong direction? The notch should show to the border of the PCB It's caused by the .NGC configuration, the label definitions have to be written in a way that artifacts are overwritten - at least by spaces. Best Regards, Thorsten.

Wird immer interessanter - ich mag "True Stereo" Synths! :smile: Gruss, Thorsten.

Welcome to the Ctrlr world! You've to use the specified release in the first posting of this thread, because Atom isn't able to ensure that panels are compatible with older (or even newer!) versions - it's a real challenge with this guy, but take it easy and just follow my proposals! ;-) Best Regards, Thorsten.

Please enter "set debug on" in the MIOS Terminal. Which messages are print out when your DAW sends NRPNs to MBNG? Best Regards, Thorsten.

Yes, use KS0108 (without inversion), and check that J28:SDA and J28:SC output pulses whenever something is written to the GLCD (e.g. during power-on when the boot message is displayed) Or even better: please use this test application, it frequently sends pulses at J28: http://www.ucapps.de/mios32/ks0108_test.zip Best Regards, Thorsten.

Yes, it's ok to leave V0 of J15 open, because the contrast voltage is supplied by your external trimpot. Currently I'm out of ideas! Facts are: - your GLCD is a KS0108 without inverted CS (proven) - the CS pins are located at J28 (I measured this with a scope and can see the pulses) - the CS pins are not properly supported by the bootloader update package V1.010, but they are supported by latest application releases. How should we continue... do you have access to an oscilloscope? Best Regards, Thorsten.

CS1 has to be connected to J28:SDA CS2 has to be connected to J28:SC Did you try this? Best Regards, Thorsten.

Thanks for finally mentioning the Test ID (TEST PC1) - this makes clear what kind of loopback you mean, and it should be obvious that the optocoupler is not involved in this part. -> Rewind -> Rewind -> Rewind I was reading your initial posting again, and finally understood what is going wrong here: The Query detects the loopback - this is good, because this means that SysEx is sent and received correctly! The test via MIOS terminal doesn't work, and this is actually a bug which went into MIOS Studio 2.4.0 (and higher) with the introduction of the MIOS Filebrowser! It filters too many messages, so that this test won't work like in older versions! I'm sorry for the confusion caused by this issue (actually the terminal based loopback test is the only usecase where this bug occurs)! So: SysEx is working, which means that the firmware upload should work as well! You haven't mentioned in your posting if you ever tried this? Best Regards, Thorsten.

Hi, you could use the related SW driver which is already available in the repository: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=/trunk/drivers/STM32F10x/v3.3.0/STM32F10x_StdPeriph_Driver/inc/stm32f10x_tim.h http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=/trunk/drivers/STM32F10x/v3.3.0/STM32F10x_StdPeriph_Driver/src/stm32f10x_tim.c It's even compiled into the project by default, so that you can directly start to use these functions via #include <stm32f10x_tim.h>! :smile: Best Regards, Thorsten.

Good decision! Best Regards, Thorsten.

Thanks for the snapshots! They prove, that the CS lines are not inverted. And good news: I think (resp. hope) that I found the issue! :rolleyes: Bootloader V1.010 was released with r1599 of the SVN repository - at this state, the J28 lines were not addressed correctly by the KS0108 driver. It has been fixed in r1603, and this change went into the latest firmware releases (e.g. MBNG, MBSEQ, MIDIO128) So - could you please check if the LCD works correctly when one of the precompiled binaries mentioned above is uploaded? Best Regards, Thorsten.

J28 should work as expected - this requires further analysis. Could you please show me (create snapshots) what happens after power-on if: - both CS inputs are connected to Ground (J28:Vs) - both CS inputs are connected to 3.3V (J28:Vd) - both CS inputs are connected to 5V (J2:Vd) - CS1 is connected to Vs and CS2 is connected to 5V - CS1 is connected to 5V and CS2 is connected to Vs Best Regards, Thorsten.

Did you already update to Bootloader V1.010 before the change? Best Regards, Thorsten.

CLCD: 1024 characters GLCD: 512 characters (because the other half of the buffer stores the used fonts) /edit: buffer size has been increased, see next topic Best Regards, Thorsten.

of course, otherwise we wouldn't be able to detect a short. Since the usage of this testmode seems to be confusing: could you please do me a favor and write a documentation for it, so that they usage is clearly specified? Or alternatively improve the messages which are print out? Such a cable length shouldn't be problematic. Are you using a 74HC595 or 74HCT595? The recommended chip is a 74HC595. If you are using a 74HCT595 - are you using a 74HC595 on your MBHP_CORE_STM32 module? Then swap it and check if this makes a change. Best Regards, Thorsten.

Yes, the voltages should be measured at the LCD. It's interesting, that the feedback is working: D7 input pin is logic-0 when D7 outputs 0V, and it's logic-1 when D7 outputs 5V So: my assumption wasn't correct. Another reason could be, that you've a short somewhere... direct measurements at each data/control line help to clarify this! Best Regards, Thorsten.

ok, and what are the results with the "testlcdpin" procedure? Best Regards, Thorsten.