-
Posts
15,198 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by TK.
-
-
:thumbsup:
-
I guess it's possible that some incomplete uploading action has compromised the PIC in some way so i'll put this problem away and focus on the CS for the moment.
You could "repair" the app installation the following way:
- put the PIC into the first socket (normally used for the master core)
- open MIOS Studio and select device ID 2 in MIOS Studio (assumed that you've already programmed the correct ID)
- power-off the MIDIbox
- load the mios_v1_9g/pic18f4685/midi/mios_v1_9g_pic18f4685.hex file into MIOS Studio and push the start button
- power-on the MIDIbox -> upload should start (if not: doublecheck the device ID)
- thereafter install the MIDIbox SID application
-> done
Best Regards, Thorsten.
-
Just to doublecheck: "TEST SW2" requires that you flash this program into the device: http://www.ucapps.de/mios/mios_bootstrap_picstart_workaround_v1.zip
It sets the ID field to 0000000000000000 which leads to a valid MIDI configuration.
Did you do this?
I've programmed the PIC with Mplab IDE with the end setting to fff all is okWhat do you mean with "end setting to fff" and what means "all is ok"?
Best Regards, Thorsten.
-
It's the normal behaviour that the master PIC tries to clone to all 3 slaves, regardless if they have been detected or not (fail-save measure).
But it isn't normal that cloning starts without pushing the MENU button during the boot phase.
In other words: it will only start on demand.
So, I assume that something is wrong with the DIN shift registers, because it seems that the firmware scans an actively pushed MENU button.
Or the pull-up resistors for digital inputs haven't been mounted yet.
Assumed that you've soldered at least the 10k pull-up at Pin #20 of the first PIC, it's better if you would remove all 74HC165 until the CS has been completed.
Thereafter cloning (and other random actions) shouldn't take place anymore.
Try cloning again once the CS is complete, and once you've to install a new firmware release.
Best Regards, Thorsten.
-
A 10bit map is less problematic, it would only consume 2k RAM and therefore could be put into the memory pool which also stores the EVENTs.
Currently only 8bit maps are supported, 10bit maps will require some changes at many places, but at least I can confirm that it's feasible.
Best Regards, Thorsten.
-
Hi Jakob,
cloning will only work if the MBSID firmware is already installed on each PIC core.
Did you already check if the third PIC is working by putting it into the socket of the first PIC core?
If it isn't working: are you able to upload the firmware with MIOS Studio?
Best Regards, Thorsten.
-
There is a snapshot button function at D4 of the first DIN SR.
Before switching off the device, you can store the current configuration by pressing&holding the button for 3 seconds (a LCD would show a message... unfortunately you've no LCD so that you probably missed this feature)
Best Regards, Thorsten.
-
Mute sync issue: go to the option page, check the value of Option 1 ("Steps per Measure")
Probably you set it to 1, the default value is 16
- If I activate "ALL" (pattern mode) it is not possible to delete or activate single steps.
This is intended.
The ALL button only affects parameter layers and no triggers layers.
- Is it possible to have the "STEP VIEW" status display on the LCD by LEDs?
-> 1-16 -> LED1, 17-32 -> LED2 and so on?
(Perhaps by additional use of the REW/FWD LEDs)
from V3: "Step View: either one LED which shows if step view 17-32 selected, or two LEDs which display if step view 1-16 or 17-32 are selected."
On V3 this was easy, because it allowed to play 32 steps maximum, therefore only two LEDs were required.
But V4 can play up to 256 steps, which means that 16 LEDs would be required.
Best Regards, Thorsten.
-
It looks like your PICKIT3 hasn't programmed the ID field to all-zero, therefore the bootloader sends an incomplete upload request.
You could fix this as described under "TEST SW2" at the bottom of this page: http://www.ucapps.de/howto_debug_midi.html
Best Regards, Thorsten.
-
This is what I wrote him via mail:
Hi Alexandre,
in order to use the bootloader, you've to locate the reset vector of your code to 0x0400, and the interrupt vector to 0x0408
At 0x0404 the value "0x4711" is expected.
Summary:
org 0x0400
goto Start
dw 0x4711 ; magic number - if != 0x4711, the bootloader won't branch to 0x0400!
org 0x0408
goto Irq
I'm not sure how this can be done in C, but I'm sure that you will find a way (google might help)
The bootloader itself doesn't use the EEPROM
The device ID is stored in the ID header instead, which is normally not used by an application.
The ID header should be all-zero (by default it's all-one)
If your PIC programmer doesn't allow to program the ID directly, you could use the program linked in "TEST SW2" from this page: http://www.ucapps.de/howto_debug_midi.html
In MIOS Studio you can upload new code the following way:
- open the .hex file
- push the "start" button
- reset (or power-cycle) your core
The query button won't work while your application is running because it expects a SysEx based communication with the PIC which is only implemented in MIOS.
However, the upload via power-cycling is already more comfortable than using a PIC programmer...
Best Regards, Thorsten. -
A 14bit map would allocate 32k RAM.
For STM32F1 and LPC17 it wouldn't be possible to provide such a feature, because memory is already completely used by the application.
For STM32F4 there would be a possibility, but it contradicts with other planned features, such as the .NGR bytecode interpreter.
And I got a request to provide individual delay parameters for each key of a keyboard which will consume some memory as well.
Therefore it's very unlikely that I will provide a map with such a high resolution - It's probably better to work on a dedicated application for this usecase.
Best Regards, Thorsten.
-
See http://www.ucapps.de/midibox_ng_manual_lcd.html
Under "3..6 CLCDs" you will find the required bootloader configuration + a schematic
Best Regards, Thorsten.
-
The Standard Control Surface has to be connected to J10A
Connection to J8/9 isn't the standard - means: most applications (such as MBCV V2) don't support this.
In addition, Ilmenator's SCS based PCB has some additional button and encoder functions which are not supported by most apps as well - only by his own app.
The good news: Ilmentator created a new PCB with the actual SCS circuit which can be directly connected to J10A :smile:
Best Regards, Thorsten.
-
It also configures the SID to play the test tone.
However, it's a very simple application. It wasn't intended to extend it by sequencing capabilities.
If somebody wants to test the SIDs, just upload the MBSID application and play some patches. This could be automated with an external sequencer.
Best Regards, Thorsten.
-
Hi Kai,
this isn't the normal behaviour, actually the usage should be straightforward.
Especially normal MIDI events (no SysEx data) should work with any MIDI interface - even with the blacklisted ones.
And with any other MIDI device (such as a MIDI keyboard) of course.
I'm surprised that after an optocoupler replacement and successful firmware upload there are still issues with receiving MIDI data.
The need for a replacement is already very unusual.
Therefore I think that the replacement didn't solve the actual issue.
Rowan, if you are reading this posting: did you check if MIDI notes can be received correctly after the repair?
Anyhow, here a link to the troubleshooting guide which helps to identify the problem: http://www.ucapps.de/howto_debug_midi.html
Best Regards, Thorsten.
-
Hi Pawaga,
I found the issue and (hopefully) fixed it.
Could you please check if it also works at your side?
Here the prebuilt binary: http://www.ucapps.de/mios32/midibox_seq_v4_088_pre6.zip
Best Regards, Thorsten.
-
Either the wrong device ID is selected in MIOS Studio, or there is a problem with your Linux installation.
Did you already work through the troubleshooting guide?
http://www.ucapps.de/howto_debug_midi.html
Which tests are working, which ones are failing?
Best Regards, Thorsten.
-
Thank you for reporting this! I will check this soon
Best Regards, Thorsten.
-
Hallo Ansgard,
"normale" MIDI Events lassen sich bereits jetzt in SysEx streams uebersetzen (und umgekehrt natuerlich auch).
Man definiert einfach einen EVENT_RECEIVER, der das Event empfaengt, und einen EVENT_SENDER, der ein Event sendet
Mit EVENT_RECEIVER fwd_id=SENDER:<hw-id> wird der Wert, der vom Receiver empfangen wurde an den Sender weitergeleitet
Gruss, Thorsten.
-
Probably I will be able to provide my solution earlier :-)
Best Regards, Thorsten.
-
The electrical difference between your configuration and the rgb=r:g:b is, that rgb=... allows to dimm LED brightness
Best Regards, Thorsten.
-
It seems that your PIC programmer hasn't programmed the ID field, it's probably 0xff (all-one).
See this page how to solve this: http://www.ucapps.de/howto_debug_midi.html
Search for "TEST SW2"
Best Regards, Thorsten.
-
-
would be an option to let the midibox listens to itself (without creating a midi-loop of course). This could be useful, if I have one potentiometer for resonance and another one for cutoff and I want to control both values at a time with another encoder f.e.
This is actually possible with the "LearnEvent" meta event (which is not officially released yet, and therefore not documented. But you can read the details in this posting)
Did you try "MidiLearn" (which is matching with your observations) or "LearnEvent" (which is matching with your request)
Best Regards, Thorsten.
Connect SEQ V4 to MBCV V2 with USB?
in MIDIbox SEQ
Posted
Yes it works! :)
Best Regards, Thorsten.