Jump to content

MIOS V1.9c released

TK.

By TK.
in Latest News

 Share

Recommended Posts

TK. MIDIbox Guru

TK.

Posted
Posted

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.

Link to comment
Share on other sites
Lall MIDIbox Addict

Lall

Posted
Posted

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

Link to comment
Share on other sites
stryd_one MIDIbox Guru

stryd_one

Posted
Posted

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

Link to comment
Share on other sites
reboot MIDIbox Tweaker

reboot

Posted
Posted

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

Link to comment
Share on other sites
reboot MIDIbox Tweaker

reboot

Posted
Posted

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

Link to comment
Share on other sites
audiocommander MIDIbox Guru

audiocommander

Posted
Posted

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

Link to comment
Share on other sites
reboot MIDIbox Tweaker

reboot

Posted
Posted

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

Link to comment
Share on other sites
TK. MIDIbox Guru

TK.

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
reboot MIDIbox Tweaker

reboot

Posted
Posted

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

Link to comment
Share on other sites
TK. MIDIbox Guru

TK.

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
TK. MIDIbox Guru

TK.

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...