Jump to content

TK.

Administrators
  • Posts

    15,247
  • Joined

Posts posted by TK.

  1. Hi Matthias,

    I just tested the following at my end:

    • uploaded usb_midi_2x2_v1_010 application to a STM32F4 core
    • no error message noticed
    • disconnected USB cable to my computer, connected USB host adapter
    • STM32F4 powered via J2 (but I also tested power supply via STLink USB socket)
    • connected M-Audio Oxygen49 keyboard
    • reseted the core (pushing black button) to ensure that the keyboard will be found
    • -> MIDI data will be sent via MIDI OUT1.
    • The green status LED on the STM32F4DISCOVERY board will flash whenever the keyboard sends data

    Which error message did you get exactly?

    Best Regards, Thorsten.

  2. Am einfachsten waere es wohl, wenn Du eine bereits vorhandene Funktion, die Du nicht benoetigst, kannibalisierst.

    Bspw. den "BUTTON_MIXER".
    Die Pin-Zuweisung wuerdest Du in Deinem MBSEQ_HW.V4 File eintragen (suche dort nach BUTTON_MIXER)
    Diese wird dann die SEQ_UI_Button_Mixer() Funktion in seq_ui.c aufrufen... ab dort kannst Du dann weitermachen ;-)

    Alternativ eine neue Button-Funktion einbauen, doch das waere umstaendlicher - Du koenntest bspw. nach einem geeigneten Stichwort greppen, so weisst Du, welche Files zu aendern sind.

    Hier ein Beispiel: 

    MacMini2:midibox_seq_v4 TK$ grep -i track_transpose core/*
    core/seq_file_hw.c:	  } else if( strcasecmp(parameter, "TRANSPOSE") == 0 || strcasecmp(parameter, "TRACK_TRANSPOSE") == 0 ) {
    core/seq_file_hw.c:	    seq_hwcfg_button.track_transpose = din_value;
    core/seq_file_hw.c:	  } else if( strcasecmp(parameter, "TRANSPOSE") == 0 || strcasecmp(parameter, "TRACK_TRANSPOSE") == 0 ) {
    core/seq_file_hw.c:	    seq_hwcfg_led.track_transpose = dout_value;
    core/seq_hwcfg.c:  .track_transpose = ((( 0   -1)<<3)+    0),
    core/seq_hwcfg.c:  .track_transpose = ((( 0   -1)<<3)+    0),
    core/seq_hwcfg.c:  .track_transpose = ((( 0   -1)<<3)+    0),
    core/seq_hwcfg.h:  u8 track_transpose;
    core/seq_hwcfg.h:  u8 track_transpose;
    core/seq_ui.c:  if( pin == seq_hwcfg_button.track_transpose )
    core/seq_ui.c:  SEQ_LED_PinSet(seq_hwcfg_led.track_transpose, ui_page == SEQ_UI_PAGE_TRKTRAN);

    In SEQ_UI_Button_FootSwitch siehst Du, wie man einen Doppelklick realisiert.

    Best Regards, Thorsten.

  3. Ich habe eine Vermutung: J10B wird ja beim STM32F4 core fuer die optionalen DIN Clock Outputs verwendet, die stehen nun natuerlich im Konflikt mit den LCD Pins (die ja urspruenglich nicht in der Firmware vorgesehen waren).

    Ich habe nun seq_cv, seq_hwcfg und seq_file_hw so geaendert, dass die Pins nicht initialisiert werden sollten, wenn im MBSEQ_HW.V4 File "J5_ENABLED" auf 0 gesetzt wurde.

    Probiere es mal aus: hole Dir die aktuellen Sourcen aus dem Repository, aendere den Wert fuer J5_ENABLED in Deinem MBSEQ_HW.V4 file auf der SD Karte, und tippe dann "reset" im MIOS Terminal.

    Danach sollten die LCDs eigentlich funktionieren. Falls nicht, muesste man ueberpruefen, ob die Pins noch irgendwo anders gesetzt, und nicht ueber die neue Variable "seq_hwcfg_j5_enabled" gegated werden.

    Gruss, Thorsten.

  4. Die Breakpoints werden bei dem optimierten Code nicht immer zuverlaessig funktionieren.

    Dahinter steht ja:

      // check if if display already has been disabled
      if( !(display_available & (1ULL << mios32_lcd_device)) )
        return -1;
    

    welchen Wert hat display_available? Ich wuerde 15 (hexadezimal 0xf) erwarten.

    Evtl. macht es Sinn, den Breakpoint in SEQ_LCD_Update() zu setzen, bspw. an der Stelle wo MIOS32_LCD_DeviceSet aufgerufen wird - und ab da mal durchsteppen.

    Gruss, Thorsten.

  5. Neither the demonstrated LED behaviour, nor the received MIDI messages make sense, and I'm surprised that anything is working at your side...

    How exactly did you connect the cores via MIDI?
    E.g. are you using optocouplers?

    And are you able to doublecheck the behaviour with a PIC based mini core, just to get more information about the root cause?

    Best Regards, Thorsten.

  6. Hallo Gidien,

    MIOS32 wird standardmaessig nur die beiden ersten LCDs initialisieren.

    Du muesstest also in SEQ_LCD_Init() noch folgendes einbauen (habe das gerade dementsprechend im SVN repository geaendert):

    s32 SEQ_LCD_Init(u32 mode)
    {
      u8 dev;
    
      // first two LCDs already initialized in main.c
      // for the case that more than two LCDs have been configured:
      for(dev=2; dev<LCD_NUM_DEVICES; ++dev) {
        MIOS32_LCD_DeviceSet(dev);
        MIOS32_LCD_Init(0);
      }
    
      // switch back to first LCD
      MIOS32_LCD_DeviceSet(0);
    
      return 0; // no error
    }
    


     

    Quote

    Die beiden zusätzlichen E-Pins sind an J10B D0 und D1 angeschlossen. Wenn ich die app_lcd.c richtig gelesen habe, sind die Pins D0 - D7 auf J10B für weitere E-Pins vorgesehen.

    Sind die Anschlüsse dort richtig ???

    Ja, das sind die richtigen Pins

    Gruss, Thorsten.

  7. I've no explanation for this issue, and I'm not able to reproduce it.

    What happens if you add

    BLM_SCALAR_MASTER_ForceDisplayUpdate();

    whenever one of the horizontal extra buttons is pressed, after the 16x16 grid LEDs have been set?
    Are the LEDs set like expected thereafter?

    I've also no explanation why faders should trigger button events.
    Do they sent CC events?
    You can doublecheck this by displaying incoming events in APP_MIDI_NotifyPackage like shown in this example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F003_debug_messages%2Fapp.c

    Best Regards, Thorsten.

  8. Hi Lamster,

    don't worry, in the past (as a teenager) I programmed PETs as well and know this situation. Let's say it this way: space invaders is already part of the firmware, you only have to configure it (should the spaceships attack vertically or diaconal? ;-)
    Nobody will complain if you've questions how to configure it correctly, as long as you raise up the right questions which allow us at the "remote end" to understand the situation - and this requires sometimes "literature research".

    So, here are two webpages as a starting point:

    This page explains how to setup a STM32F4 microcontroller, which will be the brain of your MIDIbox NG: http://www.ucapps.de/mbhp_core_stm32f4.html

    Even w/o the MBHP_CORE_STM32F4 PCB, you will already be able to flash the firmware (either via MIDI bootloader, or by directly flashing the .hex file - sooner or later you want to access via MIDI anyhow!). But the PCB + some additional modules (such as MBHP_DIN, MBHP_DOUT, MBHP_AINSER64) will allow access to the IO pins. The corresponding documentation can be found at ucapps.de as well; PCBs can be ordered at http://midibox-shop.com

    Once the MIDIbox NG firmware has been programmed, the "First Steps" page help you to do get familiar with the MBNG "programming language": http://www.ucapps.de/midibox_ng_manual_fs.html

    Best Regards, Thorsten.

  9. The optimization takes place in BLM_SCALAR_MASTER, so that you can now work at a higher level where execution speed doesn't matter anymore.

    MBSEQ is a different story - the SEQ_BLM code is a critical element since it is running in parallel to many other UI processes, therefore I had to spent more effort into the optimization (e.g. I had to access variables directly - which is dangerous for programmer newbies because of potential hard faults!)

    Best Regards, Thorsten.

  10. If it works don't change it too much, focus your ideas instead!
    The STM32F4 microcontroller has more than enough horse power to handle unoptimized code; and optimization could mean that it will be more difficult for you to integrate changes (without writing more questions in the forum than writing code into the .c file... ;-)

    Only minor complaints: you could add a for-loop for the row, and I would call the variables "x" and "y" so that it's clear (by reading the code) what should be done:

      if( element_id == BLM_SCALAR_MASTER_ELEMENT_SHIFT ) {
        int y;
        for(y=0; y<16; y++){
            int x;
            for(x=0; x<16; x++) {
              BLM_SCALAR_MASTER_LED_Set(0, 0, x, y,  MtxPart[0][x][y]); //(blm, element_id, led_x, led_y, colour);
            }
        }
      }

    Best Regards, Thorsten.

  11. Alright, the BLM_SCALAR_MASTER driver is available now, an integration example can be found under apps/examples/blm_scalar_communication: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fexamples%2Fblm_scalar_communication%2F

    I've integrated the same driver into MBSEQ V4, and it's working - the code looks much more readable now (which was my motivation... :)

    Back to the example:
    I would propose that you build blm_scalar_communication and test it at your side first to ensure that the basis is working.
    You've to adapt the BLM_SCALAR_MASTER_MIDI_PortSet() assigment if you are not using OUT3/IN3 (resp. UART2) as communication port.

    The next step is to understand the example code in APP_BLM_ButtonCallback() which shows, how to handle received button events, and how to control the LEDs.

    The actual MIDI communication to the BLM works "automagically" in background, driven by TASK_Period1mS(), which calls BLM_SCALAR_MASTER_Periodic_mS().
    This function (located in modules/blm_scalar_master/blm_scalar_master.c) looks complicated, but this is due to some performance improvement measures to ensure high-speed transfers to the BLM. Actually you don't need to look into the BLM_SCALAR_MASTER driver, it just works...

    You've to decide by yourself, if it's better to integrate your existing code into this example, or if you want to try to transfer the example code into your application. I won't be able to help you on this - I can only show you, how it works at my side.

    Best Regards, Thorsten.

×
×
  • Create New...