Jump to content

TK.

Administrators
  • Posts

    15,247
  • Joined

Posts posted by TK.

  1. The good news: this is a feature which can be easily enhanced, because I implemented a fully scalable solution (and I'm really proud of this, because usually I can't do this for everything due to memory limitations! ;-)

    Current divider values:

    const u16 din_sync_div_presets[] =
      // 1    2    3    4   6   8  12  16  24  32  48  96  192  384 ppqn, StartStop(=0)
      { 384, 192, 128, 96, 64, 48, 32, 24, 16, 12,  8,  4,   2,  1, 0 };

    the maximum possible divider value is 65535, but as you can see, I only prepared up to 384 for 1 ppqn

    Which additional dividers would be useful?

    Best Regards, Thorsten. 

  2. Nobody reported such an issue so far.

    The ignorable upload error can be... ignored! It happens when MIOS Studio uploads a new block while flash programming is in progress. MIOS Studio retries and gets a success message -> flash programming done -> don't worry about this. Depending on the machine you could get 20...30 ignorable errors but application is still uploaded correctly.

    8004004 isn't the boot loader section anymore, it's the application section.
    It's normal that this range will be overwritten.
    Which .hex file did you compare? The boot loader or MIDIbox SEQ?

    You could upload the MIDIbox SEQ binary directly with ST-Link, it contains the boot loader + the application code, the result should be the same as if you would upload the application via USB MIDI.
    This is also the way how you can continue troubleshooting.

    It's btw. strange that the LCD is blank, the MIOS32 boot loader update application should initialize the LCD and print a message.

    The only explanation that I have for this effect (application not started, LCD blank) is, that the blue USER button is still pressed for whatever reason (defective button?) - because in this case the boot loader won't start the application.

    Best Regards, Thorsten.

     

  3. Hi *,

    the midibox.org server will be moved to a new location this Friday evening (CET).
    The forum will be down for ca. 2 hours, thereafter it will be available under  http://134.119.32.105/forums
    Once the updated domain records have been propagated to the DNS server of your service provider, you will be able to use the URL http://forum.midibox.org again!


    I would like to take this opportunity to thank Twin-X for hosting midibox.org on his server for more than 10 years!
    He helped us to keep the site online during a difficult situation anno 2005 where bandwidth did matter.

    I remember the times where the previous midibox.org servers that we tried were dramatically slowed down or just not available for the remaining month once we exceeded the bandwidth limits (typically after new MIDIbox SID V1 demo publications)! No issue after Twin-X jumped in - I was even able to publish videos w/o the downtime danger (for the younger fellows of this forum: the time before YouTube or Facebook which started to provide this possibility for free!!!)

    Twin-X gave us a solid home which resulted into a growing user base and a nice place to talk with so many people who follow the same DIY spirit! :)

    Times have changed, technology improved, cloud based servers are common today, easy to setup and fast enough to host a site like midibox.org
    The new server is owned by myself, and it’s completely founded by the community, thanks to the donations that I got in the last months (I got more „beers“ than I could actually consume!!! ;-)

    Looking forward for the next years of fruitful discussions & publications about our hobby: MIDIbox DIY fun!

    Best Regards, Thorsten.

  4. There is no AINSER related change between pre15 and the current version.

    See also: http://svnmios.midibox.org/comp.php?manualorder=1&repname=svn.mios32&compare[0]=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1&compare_rev[0]=2211&compare[1]=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1&compare_rev[1]=2243&comparesubmit=Vergleiche+Pfade

    Could you please check if one of the examples (such as cfg/tests/ainser64.ngc resp. ainser8.ngc if you are using the unmuxed PCB) is working at your side?

    Best Regards, Thorsten.

  5. Hi,

    did you already try to access the PIC via MIDI by using MIOS Studio?

    If this isn't working, it could be related to a power supply issue - check the supply voltages of the PIC
    (a "hard-reset" resp. re-installation requires that the PIC is properly powered, but very likely the PIC will run again once you clarified the basic infrastructure)

    Best Regards, Thorsten.

     

  6. I noticed that the last firmware version was released more than one year ago! Time to release a new one officially (after more than 20 beta versions):

    MIDIbox NG V1.033
    ~~~~~~~~~~~~~~~~~
    
       o with this release, .NGR scripts running on a STM32F4 are directly executed from RAM in a compressed
         format, and therefore they are significantly faster, so that they could even be used for timing
         critical operations.
    
       o added basic support for SPI_MIDI
         This feature requires an update to MIOS32 bootloader v1.018
         In the bootloader update app, enter "set spi_midi 1" to enable the SPI MIDI device at J16 (RC2 chip select line).
         This will also disable the OSC ports via MBHP_ETH module, which is normally connected to this port.
    
       o support for WS2812 LED strips (currently only for the MBHP_CORE_STM32F4 module).
         The data input has to be connected to J4B.SC, ground to J4B.VS and +5V to an external PSU (required, since
         each RGB LED can consume up to 20 mA!)
    
         Following meta event commands are available:
         - RgbLedClearAll (clears all LEDs)
         - RgbLedSetRgb:<led>:<r>:<g>:<b> (led=1..64, r/g/b=0..255)
         - RgbLedSetHsv:<led>:<h>:<s>:<v> (led=1..64, h=0..359, s=0..100, v=0..100)
         - RgbLedRainbow:<speed>:<brightness> (speed=1..255, brightness=0..100)
    
        Most simple way to test a LED strip: enter following command in MIOS Terminal
           ngr exec_meta RgbLedRainbow:9:100
        (don''t forget to wear sunglasses, or start with brightness 20!!! ;-)
    
       o added EVENT_RGBLED
         See cfg/test/rgbled_1.ngc for usage examples
    
       o .NGR file: added "set_hsv" command which allows to control the hue parameters of a RGBLED
    
       o SRIO num_sr=<value> reconfiguration works correctly with DIN/DOUT matrices now
    
       o added "inverted=1" to EVENT_BUTTON and EVENT_LED
    
       o .NGR file: added "load <setup>" command which allows to switch to another setup (.NGC, .NGS, .NGR, ... files)
    
       o implemented new meta command "SendEvent" which allows to remote control one or more events from a single event
         within a given value range and direction.
         See cfg/test/metalrn.ngc for a usage example
    
       o implemented new meta command "LearnEvent" which allows to learn SendEvent based controller assignments during runtime.
         See cfg/test/metalrn.ngc for a usage example
    
       o added new meta command "SaveDelayedSnapshot:<seconds>"
         It will request to store a snapshot after at least the given seconds.
    
       o added new event type "NoteOnOff", which will send a NoteOff event immediately after NoteOn (resp. actually it will
         send Note On with velocity 0 for runtime event optimisation)
    
       o added possibility to calibrate the delay_slowest values for each individual key of a keyboard.
         New terminal commands:
         - set kb <1|2> key_calibration on: delay values will be measured (method described at the MIDIbox KB webpage)
         - set kb <1|2> key_calibration off: captured delay values will be used: (<measured-delay> * delay_slowest / 1000)
         - set kb <1|2> key_calibration clean: shows the captured measurement values
         - set kb <1|2> key_calibration_value <key> <value>: allows to modify a calibration value directly
         - kb <1|2> delays: shows the measured delay values
    
       o keyboard calibration values are stored in a new file: .NGK, and can also be edited there
    
       o bugfix for DELAY_MS
    
       o bugfix for fwd_id to a non-existing ID with specific value
    
       o bugfix for maps with duplicated values
    
       o bugfix for sporadic file access errors reported during snapshot restore

    The documentation has been updated as well

    Best Regards, Thorsten.

  7. Well done and nicely documented! :)

    The assembly code remembers me on the cycle accurate hacks that I did for MBHP_TV years ago - it's a nice experience to work on this level, as long as users don't start with enhancement requests ;-)

    But it seems that your solution is simple & powerful enough to satisfy requests at host level :)

    Best Regards, Thorsten.

  8. Testing the BLM the last couple of weeks I was getting intermittent behaviour. Notably the SEQ was having trouble communicating at power on and the miniCore would reset if too many blue LEDs were lit.

    While reading your posting an idea came into my mind: the PIC device configuration (which comes with the MIOS bootloader) is preconfigured with a brown-out reset detection at 4.5V, which means if the supply voltage falls below this limit, the PIC will be reset, although it also works at lower ranges.

    I selected this high BORV setting to ensure, that for example an ongoing IIC EEPROM programming operation will be interrupted (by resetting the PIC) before the external device is outside the valid voltage range during power-off - this could lead to data corruption.

    But the BLM16x16+X doesn't access external EEPROMs, so actually the BORV could be lowered to 2.89V or even 2.14V

    Unfortunately this can only be done with a PIC programmer.

    Best Regards, Thorsten.

     

  9. Does it make a difference if you replace the 8 100 ohm resistors by 220 ohm?

    100 Ohm has been selected in the original circuit since the LEDs are driven from 3.3V pins - but in your case they are driven from 5V pins which could lead to these ghosting effects.

    Best Regards, Thorsten.

     

  10. No, it won't help.

    The problem is, that the TPD has many DOUT shift registers, but only a single DIN shift register (as far as I remember). This results into an unbalanced serial output which leads to trouble when another module with DIN/DOUT registers (such as the BLM16x4) is connected.

    So - this kind of module will only work at the end of a serial chain, or with some buffering (and some luck) - it's a complex topic, I can't give you a fool-proven solution without further analysis (and I won't have the time for this anyhow... ;-)

    Best Regards, Thorsten.

×
×
  • Create New...