mios1.2 and midi sid stepB troubles and questions

[chriss]

hi all,

first i wanted to thank Thorsten for this inredible nice work.

I took the chance to upload MIOS 1.2 with the new midi sid stepB application and my lcd still shows MIOS 1.1. I don´t know if this is an fault by Thorsten or the upload didn`t work. When i load MIOS 1.1 i can see after reboot >ready<, with MIOS 1.2 there is nothing on the sreen. I just have to power on the midi box, start midiox and send the new MIOS version. right? then boot again and send the application sysex.?

The second question concerning the midi sid stepB application.

Everthing is working ok so far, but there are some little questions. In local mode the box works like StepA only with midifeedback. thats very cool. But the lcd data does not change!!! So when i change for example the cutoff midiox is reseiving the data but on the lcd the value is not changing. when i close the midi input in midiox the lcd works fine again.

Another problem which may have the same cause. As soon as i change to sid 1-4 the midi sid is sending a lot of data when i hit a note and never stops untill i change to local mode again.? Closing midi in port in midiox and everthing is fine.

My setup is still using the to com interface. what me leads to the third question.

Does the Pic 16f877 with hexfile sid v1.4 only work with midi baudrate? Where can i change that? otherwise i have to wait till the usb2midi is released and build.

One last question about the hardware. whitch pins of the slavecore module can be left open or have to be grounded or need a pullup resistor.  i mean only these pins which are normaly connected to the I/O boards, bankstick, and lcd.

Thanks and be ready for the stepD

chriss

[TK.]

Hi Chriss,

first i wanted to thank Thorsten for this inredible nice work.

thanks! :)

I took the chance to upload MIOS 1.2 with the new midi sid stepB application and my lcd still shows MIOS 1.1. I don´t know if this is an fault by Thorsten or the upload didn`t work.

It seems that the upload didn't work. This means also that there is a potential risk that the OS is corrupted, and therefore causes problems.

When i load MIOS 1.1 i can see after reboot >ready<, with MIOS 1.2 there is nothing on the sreen.

this is strange!

I just have to power on the midi box, start midiox and send the new MIOS version. right? then boot again and send the application sysex.?

yes, but an OS update only works with the first-level bootstrap loader which is active during the first 2 seconds after power-on. It's important that every SysEx acknowledge string which is sent by the PIC during the upload procedure ends with a "0F xx F7". If it ends with a "0E xx F7" you propably got an checksum error due to a bad MIDI connection - in this case the code block will not be stored in the flash memory.

The second question concerning the midi sid stepB application.

Everthing is working ok so far, but there are some little questions. In local mode the box works like StepA only with midifeedback. thats very cool. But the lcd data does not change!!! So when i change for example the cutoff midiox is reseiving the data but on the lcd the value is not changing. when i close the midi input in midiox the lcd works fine again.

I just checked this with my MBSID - the LCD screen will be updated, so this is either a problem with the corrupted MIOS version, or a MIDI-feedback problem caused by MIDI-Ox. See also:

http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1054029058

Another problem which may have the same cause. As soon as i change to sid 1-4 the midi sid is sending a lot of data when i hit a note and never stops untill i change to local mode again.? Closing midi in port in midiox and everthing is fine.

ok, this is definitely a feedback problem, because only in the common mode the MIDI merger will be enabled, means: everything which goes to the MIDI In will be forwarded to the MIDI Out. The merger will be disabled in local mode. In your sequencer application you have to take care about these relations (only enable the MIDI In which is connected to your MBSID when the MBSID is in local mode)

My setup is still using the to com interface. what me leads to the third question.

Does the Pic 16f877 with hexfile sid v1.4 only work with midi baudrate? Where can i change that? otherwise i have to wait till the usb2midi is released and build.

I could compile a special PIC16F firmware for you with to-COM enabled.

One last question about the hardware. whitch pins of the slavecore module can be left open or have to be grounded or need a pullup resistor.  i mean only these pins which are normaly connected to the I/O boards, bankstick, and lcd.

All outputs can be left open, the analog inputs are disabled, Pin RA4 requires a 1k pullup, pin RD1 a 10k pullup resistor

Best Regards, Thorsten.

[chriss]

hello Thorsten and all others,

thanks for the reply at the moment i have to work a lot, but i will keep you informed when i make progress.

This with the midifeedback problem makes sense, didn´t know that midiox is so mean.

About the sid v1.4 to com: if it takes less then 2 minutes i would accept that offer, otherwise i can wait.

chriss

[chriss]

hello Thorsten,

i solved the MIOS 1.2 problem by reburning the pic. don´t know what went wrong but now it works. also the midi feedback problem is solved.

Just another Question concerning the encoder mode.  

As you may remember i am using the alps stec16b encoder like you i guess. when i turn it 360 degree it changes 36 steps. shouldn´t that be 72??

And yesterday i got one stec11b which has an inbuild switch ( i want to use it for the menu and exec button), but it is detented.  so i changed the enc mode in Mplab and loaded it up. what comes out was that it only moves at every second step, and in the main menu only every fourth step.

Then i uploaded the old version (non detented) and couldn´t see any difference?

so how does this work actually? If on cycle is from low to high to low, then one cycle is one step or two? (with non detented) Because i checked today the alps stec11b with an osci  and every detent (raster) is half a cycle (changing from high to low for example).

I already checked the connections and they are allright (ABC for stec16b and ACB for stec11b).

Thanks for all that support and i hope we can clear things.

chriss

[TK.]

Hi Chriss,

the SID firmware changes the resolution of the encoder depending on the max value so that the value can be entered with an accurate precision. But you are right, I'm also not satisfied with the encoder "feeling", I've planned to add more parameters to the encoder handler so that more settings than "SPEED_SLOW", "SPEED_NORMAL" and "SPEED_FAST" are possible.

I never tested this application with a detented encoder, therefore it will possibly not run correctly. In the main menu the value will be scaled by 4 (same reason like above). It seems that an additional option will be required which disables this scaling for detented encoders, I can build this into the application as soon as I receive the detented encoders from Ian.

Quick&dirty workaround: open cs_menu.inc, search for CS_MENU_EncSpeedSet. Add following code to the first lines:

CS_MENU_EncSpeedSet
      movlw      MIOS_ENC_SPEED_NORMAL
      movwf      MIOS_PARAMETER1
      movlw      0x00
      goto      MIOS_ENC_SpeedSet

Menu scaling: search for all "#if CS_MENU_USE_INCDEC_BUTTONS == 0" in cs_menu.inc, change this to "CS_MENU_USE_INCDEC_BUTTONS == 2" to disable the scaling of the menu position.

Could you please also test the encoders with the enc_* examples in the meantime? Because these examples are using the encoder only in normal mode, without the progressive mode and without scaling.

It would also be interesting for me if your detented encoder runs better with the undocumented third encoder mode. Replace MIOS_ENC_MODE_DETENTED by 0x81 to test this. I never was able to use the driver with a detented encoder yet, so I really rely on your inputs!

Best Regards, Thorsten.

[chriss]

Hello Thorsten,

so these are my results:

Did the quick and dirty and it works by stepping one with every second detent in the main menu and all others.

tested the enc example #1 and i would say:

non_detented mode: stepping two with one detent;

detented: stepping one with two detent.

0x81: stepping like detented

So we need exactly the middle of both.

funny though.

Is there a difference in enc_example #2 and #3 concerning this issue? because i could try these as well.

Ps:  Are you able to compile the PIC16F firmware with to-COM enabled for me? Maybe its usefull for others too.

Thanks

chriss

[TK.]

Hi Chriss,

it's not clear to me why 0x81 behaves exactly like 0x80, are you sure that you did compile and convert the firmware correctly? Do you see the same results when pin A and B are exchanged.

Just for clarification reg the non-detented encoders:

As you may remember i am using the alps stec16b encoder like you i guess. when i turn it 360 degree it changes 36 steps. shouldn´t that be 72??

Until some weeks I used OEM encoders from Alps without type number (I guess that these are customized types, Alps offers this option if you order more than 1000 pieces).

I got them for a few bugs from Ebay. I guessed that these are the same like STEC16B, but this was wrong. They have the same size, but the pinning is ACB. Also the resolution is different, they are sending 12 ticks per revolution. And with the interpolation feature I get 48 ticks per revolution.

Also the statement made in the MIDIbox16E introduction page is not correct (STEC16B from RS sends 36 pulses) - a misinformation (I never used the encoders from RS...) so I should update this page.

Ok, to make it clear:

STEC16B are non-detented (type 0x00) and they are sending 24 pulses. The MIDIbox16E and MIOS driver detects every rising and falling edge, the result are 96 pulses per revolution

Detented type 0x80: every second edge, result: 48 pulses per revolution. I know only one detented encoder (a jog-wheel) from Rasmus which works correctly with this type

Detented type 0x81: should be the default setting for detented encoders, 24 pulses per revolution are sent like known from the specification. Another encoder from Rasmus needs this setting. I guess that this is also the case for Alps encoders.

Best Regards, Thorsten.

P.S.: hope that I get the detented encoders from Ian soon so that I'm able to test the driver by myself ;-)

[TK.]

Hi again,

I've compile the PIC16F based firmware with the to-com option, it can be found in the

http://www.ucapps.de/midibox_sid/midibox_sid_v1.4.zip

Archive

(untested!)

Best Regards, Thorsten.

[TK.]

addendum: I just have realized that the output signals of the STEC11 are different - I compared the waveforms from the datasheet with the waveforms traces with Rasmus' encoders.

So - it isn't your fault, it's an imperfection in MIOS. I have to integrate some additional encoders types (0x82, 0x83, etc.).

Best Regards, Thorsten.

[TK.]

By shifting the Inc/Dec states I finally found a solution which should also work with the Alps STEC11b without an additional encoder type ID.

Chriss: could you please try this new MIOS version:

http://www.ucapps.de/mios/mios_v1_2c.zip

with encoder type 0x80?

Best Regards, Thorsten.

[chriss]

Thanks Thorsten,

at the moment i can not test any of your codes, cause i am 3 hours away from my sids, but thursday/friday i can report my results.

thanks

chriss

[chriss]

hi Thorsten,

Yesterday i managed to work on my MBsid.

The firmware for the slaves work so far, though it just react on note on/off when the menu is on Sid 1 and i can not change anything. It only plays the generic patch. I think thats because of the device ID.

At the moment i don´t know how i can change the devicenumber.  When i go into the submenu i can only change the devicenumber of sid 1, in sid 2-4 submenu the field for the device ID doesn´t react and stays like that ___. i guess the core does not realize that there is a slave.

Is the sid v1.4 default ID 00? Do i have to change it before i burn it? I read in the MB64 zip that the ID is not changeabel over sysex when connected to the to_com!

When i send a ping to the box, with any ID, i get the same ID back (from 00 to 0F) The same when i try it with the device change syx. string. I just get the same string back. When i burned the bootstrap loader for the core i gave it ID 00, was this correct?

Now to mios_v1_2c.

Unfortunatly i couldn`t change the hex to syx. I really tried it two hours. but i only get weird signs in the command shell and the syx. file is empty.

So no tests here. If you still want me to test the encoder handler (i read in an other post that you will release MIOS 1_3 soon), send me the mios_v1_2c as syx.file.

thanks

chriss

[TK.]

Hi Chriss,

I just have answered your questions in the new Step B documentation.

MIOS V1.3 and the updated SID application can now be found in the MIOS download section. Hope that the interaction with the STEC11B is working now :)

Best Regards, Thorsten.

[chriss]

Hi Thorsten,

thanks alot so far. Yeah you answer the questions with the steb B documentation.

Stec11B: it works nicely after changing the main.asm and the mios_tables to detented.

Unfortunatly the sidv1.4_to_com is not talking to my pc. no ping, no changing device. (just plugged one core with the sid v1.4 to my pc). The LCD prints >sid v1.4< and from time to time >Midi time out whats up< and it does not react on note on/off.

thanks

chriss

[TK.]

Could you please check the next try? ;-)

(same location, once more: untested)

Best Regards, Thorsten.

[chriss]

Hello Thorsten,

just the same. sorry.

What i didn´t say the last time: Your whole sidproject is really awsome. Never dreamed of doing something like that.

thanks

chriss

[TK.]

Hi Chriss,

thanks! :)

before I have to burn the code into my PIC16F in order to check the settings, could you please ensure that you've downloaded the correct .zip file? Some webbrowsers don't regognize that a file with the same name has been updated, so possibly you've got the old file from the file cache.

The new firmware has following timestamp: Jun 24 19:39 midibox_sid_v1.4_to_com.hex

Sorry for the circumstances, but I'm not able to burn a PIC16F877 under Linux anymore (no driver for the JDM, and the new PICstart firmware doesn't work with picp)

Best Regards, Thorsten.

[chriss]

Hi Thorsten,

thanks for the circumstances, at the moment i have some trouble with my JDM programmer, but i definetly downloaded the last version.  

Hope to check evererthing out before i have my midi interface.

chriss

[TK.]

Ok - so when I have nothing else to do I will try it out by myself in order to ensure that it really works.

Best Regards, Thorsten.

[chriss]

Hello Thorsten,

finally we can close this thread, i found the mistake. Now everthing works fine. Since i build only one core for the 18F hardwired to the to_com interface, i had to put all the slavespics into that core. But the 16F877 needs a 20MHZ crystal!!!

ok stupid me and sorry for the wasted time.

But without you i will still search.

thanks

chriss

[TK.]

Alright - just a new possible error found which can be made ;-)

Best Regards, Thorsten.