MIOS V1.9c released

T.K · August 27, 2006, 7:28pm

Hi *,

MIOS V1.9c is now available for download; this version got a small but useful improvement in the button debouncing routine: debouncing can now be enabled without disadvantages when rotary encoders, LED matrices or timing accurate digital outputs (e.g. 1 mS drum triggers) are scanned by the serial IO chain.

Here a short list, under which circumstances an update to MIOS V1.9c makes sense (ok, normaly it always makes sense!)

MIDIbox64: debouncing enabled, but no rotary encoders and no timing critical digital outputs - therefore update not required
MIDIbox64E: debouncing not enabled due to connected rotary encoders and led rings - with MIOS V1.9c you could optionally use it
MIDIbox LC: debouncing not enabled due to connected rotary encoders and led rings - with MIOS V1.9c you could optionally use it
MIDIO128: in the past it was suggested to disable debouncing if timing accuracy where desired at the digital outputs (e.g. 1 mS drum triggers) - now debouncing can be optionally used. But please note, that the debouncing routine of MIOS is a real cheap implementation, since it suspends the scanning of all digital inputs (except for encoder inputs) at the same time. This means: buttons are not debounced individually to save RAM
MIDIbox CV: debouncing is enabled, update only recommented if source code has been enhanced by CV gates/triggers via DOUT
MIDIbox SID: debouncing not enabled due to connected rotary encoders - with MIOS V1.9c you could optionally use it
MIDIbox FM: debouncing not enabled due to connected rotary encoders - with MIOS V1.9c you could optionally use it
MIDIbox SEQ: debouncing was wrongly enabled, with the result, that encoders with >= 24ppr produced jumping values when rotated too fast. Update to MIOS V1.9c recommented

[br]The change in MIOS_MIDI_InterfaceSet/MIOS_MIDI is only relevant for MBSEQ V3 users

Download: http://www.ucapps.de/mios_download.html

(press the refresh button of your browser if you don’t see the mios_update_v1_9c.zip file)

Best Regards, Thorsten.

QBAS · August 27, 2006, 7:48pm

very good - thanx again

docbrown · August 28, 2006, 5:29am

TK,

Thanks for this update. I’m still running the mios_v1_9c_rc1 and it seems my encoders are a lot more stable on my SEQv2.

I will replace this 1.9c rc1 with this final release.

thanks again.

Lall · August 28, 2006, 9:43am

Hi Thorsten,

I’m reading about the improvement on the flickering with the separate DIN and DOUT ISR.

Am I assuming correctly that there’s no change in hardware required in order to get that improvement working?

When I’m looking at the Core schematic (v3 from June06), I see that Rc and Sc are common to both DIN and DOUT and I was actually wondering how you could solve this issue purely with software.

Best regards,

Lall

stryd_one · August 28, 2006, 10:32am

GDay Lall,

No hardware mods required, cool eh

The changelog explains it well:

o Changed the way how MIOS debounces buttons. Before this change,

the whole SRIO scan was skipped, with the result, that DOUT

registers were not serviced as well. This led to the unwanted

side effect, that LED matrices were flickering and rotary encoders

with high resolutions were jumping.

With this release, only DINs which are not assigned to encoders

are debounced, and the SRIO scan is continued so that the DOUT

registers are always updated

Lall · August 30, 2006, 11:15am

Hi Stryd_one,

Thanks for the pointing out.

Sorry for not having carefully RTFM (Read The Fucking Manual) :-[

Best regards,

Lall

stryd_one · August 30, 2006, 12:20pm

No worries man I assume that you didn’t download it seeing as you weren’t sure if you were going to be able to use it … I’m a MIOS addict, I try to read every line TK releases

Lall · August 31, 2006, 8:10am

Indeed, you got it right. I only looked at the website.

I know what I have to do next time I’ve such a question

Best regards,

Lall

reboot · September 3, 2006, 11:48pm

hello

i have a problem with last update

my sid reboot itself again and again with setup 6581.hex

i have no problem with 1.7a with mios 1.8

i can’t put my first slave because i loose the 1.7a file and i have just one master

i would like to use the lastest one but i don’t understand

if someone have an idea …thank you

Jack · September 4, 2006, 6:52am

Hi!

The bootloader is updated, too!

See download page:

Please read the README.TXT carefully before uploading any .hex file of this package!

Jack

reboot · September 4, 2006, 10:03am

hello

thank you for your help but it’s still the same

i use the folder mios update v1_9C

bootloaderv1_2 + mios v1_9

then i dump via midi-ox a file i generated with convert.bat after renamed the file setup6581 by main

the upload works with setup with cs but with setup6581 the sid reboot itself again and again

thanks

audiocommander · September 4, 2006, 12:03pm

Hi reboot,

seems the issue fits to your username ;D

then i dump via midi-ox a file i generated with convert.bat after renamed the file setup6581 by main

the upload works with setup with cs but with setup6581 the sid reboot itself again and again

???

Sorry, I don’t understand what you did there.

The normal procedure is:

Burning the bootloader
Uploading MIOS
Sending the application

The normal upgrade procedure is:

Sending the MIOS 1.9 update; get the right one for your PIC. This also upgrades the bootloader
Upload the application

Have you tried with midibox_sid_v1_7303b.zip or another package?

You must not rename any file!! Just renaming the extension from *.hex to *.syx won’t work.

If you’re not using MiosStudio, you have to use hex2syx.pl to generate a sysex-file out of the hex-file.

Regards,

AC

reboot · September 4, 2006, 1:58pm

ok

my question is

why does my master reboot itself ?

when i “burn” the file without cs enabled it works

i’m sorry to tell that but the installation is a bit strange…and about the id of the core i can’t see the files corresponding to the slaves

sorry ,but 3 weeks with the same problem gets me nervous

see u

audiocommander · September 4, 2006, 2:05pm

Hi reboot.

It would be easier to help you if you’d answer the questions and give us some more informations.

Regards,

Michael

T.K · September 4, 2006, 6:55pm

Hi Mr. Reboot,

the installation is so complicated since I had to change the bootloader concept in order to make it more future proven. In order to avoid, that 100es of users have to reprogram their PICs with a PIC burner, I developed an update mechanism which allows to update the bootloader via MIDI. I made it so secure and comfortable as possible (with CRC check before update, with MIDI messages sent via MIDI for people who don’t own a LCD, etc..) but: the update can only work properly if you select the right .hex files which are matching in your situation. All the possible scenarios and the right selection of the .hex file is clearly documented in the README.txt file. If you select the wrong one, it can happen, that the bootloader will be destroyed in a way where is no solution anymore to reprogram it via MIDI. Such a worst case scenario - where the wrong .hex file has been uploaded - can be found here http://www.midibox.org/forum/index.php?topic=6560.0

I must say that I don’t know how to avoid this without spending even more days in thinking about possible scenarios and building protections + new tools around this. In general all what people have to do is to read the README.txt - and if they are unsure - to ask which .hex file is the right one before trying anything out.

However, “Reboot”: I think there is a chance to revive your PIC. It seems that the problem was, that you tried to upload the new MIDIbox SID release with an older MIOS version - this cannot work, because one of the great advantages of MIOS V1.9 is, that it frees 1k of flash memory which is now used by the MBSID (see ChangeLog).

Since you’ve used MIDI-Ox to upload the MBSID code (which is too large), you propably didn’t see the error messages during the upload. The meaning of these messages are in your case, that you tried to write code into a protected area (they don’t appear with MIOS V1.9). Now, after a reboot, the CS enabled application (which contains much more code) jumps into a location which doesn’t contain valid code. Instead it contains the bootloader v1.1b code (in worst case the MBSID application jumps to the routine which erases the flash).

So, this explains, why the version without CS worked properly.

What to do now: don’t panic!

Don’t try to upload any .hex file of the update package now before we know in which state your PIC is, and before we’ve confirmed which .hex file is the right one for reviving the PIC w/o reburning the bootloader

So, which .hex files of the update package did you try to upload exactly?

And a hint: please use MIOS Studio - it makes the upload more secure than MIDI-Ox

Best Regards, Thorsten.

reboot · September 4, 2006, 9:56pm

hello

first thank you to help me

i describe what i do

1----with a virgin pic i burn with ic prog :mios update v1.9c/pic 18F452/burner/bootloader v1_2pic18F452.hex

2----open mios studio then dump mios v1_9pic 18F452.hex with "don’t use feedback"and 750ms

3----can read mios v 1.9c and “ready.”

i did this process a lot a times

4----again with mios studio i dump this

midibox_sid_v1_703b/setup_6581.hex

5----IT WORKS but when i press edit the machine REBOOT ok maybe it’s normal at this point

6----take second pic with id value 0000…1 with ic prog

7----mios studio; same file with device id 01

8----sid is “ready.”

9----again with mios studio i dump this

midibox_sid_v1_703b/setup_6581_without_cs.hex

10----"MIDIboxSID V1.7303b CS not enabled! "

11----i plug the first core and the second one as slave and…my sid reboot again and angain

i have to tell that the master has the chips stuffed in sid part and slave don’t have

i checked twice the connections of j11

i also tried to change the device id by using mios studio

something is wrong in my slave area but where ?

i did the 2 pcb’s with 2 core and sid

do i have to unplug everything to do a test ? i’m no sure it’ll be usefull

thanks again

T.K · September 4, 2006, 10:11pm

Alright, so the code upload was successfull, the applications are up&running, and you don’t need to do this again, because the error must be more hardware related - it isn’t normal that the PIC resets when you press the edit button, maybe there is a short circuit there? Check the button connections. I think that we can continue this discussion in the troubleshooting section if you don’t find the error, it’s neither MIOS related, nor worth for beeing spreaded in the news section

Best Regards, Thorsten.

reboot · September 12, 2006, 12:24am

hello TK

i noticed a bug encoder with deph env

the parameter don’t come back when it’s -64 and only decrement

is it a bug or my machine (i put a picture of it but it’s not finish yet)?

thank you

docbrown · September 12, 2006, 3:48am

hello TK

i noticed a bug encoder with deph env

the parameter don’t come back when it’s -64 and only decrement

is it a bug or my machine (i put a picture of it but it’s not finish yet)?

thank you

Nice one!!

T.K · September 12, 2006, 7:30am

i noticed a bug encoder with deph env

the parameter don’t come back when it’s -64 and only decrement

is it a bug or my machine (i put a picture of it but it’s not finish yet)?

Why do you post such questions in the news in an article which introduces a new MIOS version?

Of course, it is very likely that it is a bug in your DIN module wiring, or what did you expect? That 100red of people are not able to use the Depth ENV encoder and never reported this?

We have a special forum section where you can ask for help, it’s called “Troubleshooting” and not “News”

Best Regards, Thorsten.