Jump to content

TK.

Administrators
  • Posts

    15,198
  • Joined

Posts posted by TK.

  1. the only drawback seems to be the MIOS32_LCD_PrintString-Function. if you print the static screen in the while-loop (KS0108-Test), as it is, both displays and the four leds on the board flicker. whereas if you print the static screen before the while-loop it runs perfect without any flickering. i cant believe, that the printstring-function works slower on the stm32f4 than on the lpc17, where the ks0108-test runs without flickering out of the box. do you see any reason for that ??

     

    It's either related to a wrong configuration or to a misinterpretation of the LED at your side.

     

    I tested the execution time of the while() loop in apps/mios32_test/app_lcd/ks0108.

    On a LPC1769 one iteration takes ca. 10 mS, whereas on a STM32F4 it takes ca. 5 mS - so, definitely faster.  :wink:

     

    Possible wrong configuration: check the LCD parameters in the bootloader.

    For KS0108 you've to specify lcd_num_x 1 and lcd_num_y 1, because the two GLCDs are handled like a big display with 4 segments (this is the way how the driver is implemented)

    If you've specified lcd_num_x 2, the driver would try to access a non-existing GLCD, and this slows down the execution.

     

    Possible misinterpretation: are you testing from a background task, or from a main task (e.g. APP_Tick())?

    What else is running in your application?

     

    Best Regards, Thorsten.

  2. so ive thought, i update the sources (again) to see what happens and voila it works with one display ! dont know what the difference between 1.014 and 1.015 is, but something magically changed...

     

    Great!

    Seems that the immense effort that I spent yesterday to qualify various displays at various cable lengths on the STM32F4 was worthwhile :)

     

    You can retrieve the differences with the comparison tool of the svnmios page: http://svnmios.midibox.org/log.php?repname=svn.mios32&path=%2F&isdir=1&

     

    Select revision 1938 and 1936, and then click on the compare button.

     

    Best Regards, Thorsten.

  3. Well done!!! :)

     

    How did you mount the frontpanel? It looks like it only lays on top, but isn't screwed with the side panels?

     

    I would like to see this case as the official alternative solution to the Heidenreich case.

    Since it can be ordered at Formulor, people are free to choose the material and color and to do customizations (especially on the backpanel).

     

    Could you please start a new Wiki page and publish your .svg file (packed into a .zip) there?

     

    Best Regards, Thorsten.

  4. AOUT is really 6 signals (Vs, Vd, SO(SI), SC, RC1 and RC2) but Vs is common to the Core and doesn't need a separate ground.

     

    Only Vs/Vd/SO/SC/RC1 (not RC2)

     

     

    1 sync input to control the master clock/ forwarded to the additional clock outs.

     

    yes!

    The sync input will be located at a dedicated IO pin of the core.

    I will probably take the CAN IO at J18, because it's available for all core variants, and I'm sure that CAN won't be used for the MBCV application.

     

     

    What about analogue inputs? These would be pretty cool to interface from a modular system back to the Core. Diode clamps to protect the input pins?

     

    Yes, the 8 analog inputs will be available in the modulation matrix.

    Note that LPC17 will only provide 6 analog inputs, because J5B.A6 and A7 are allocated by MIDI3 IOs

     

    Protection diodes: yes!

    + 220 ohm resistor in serial to the input for short circuit protection.

     

     

    5 AOUT

     

    Transfering the serial signals to an external breakout board is problematic, because actually the cable to an AOUT module shouldn't be longer than 30 cm!

    We have to do some experiments with line drivers and receivers, see also the bottom of this posting: 

     

    Best Regards, Thorsten.

  5. We've a problem here: the application can only open one file (because there is only a single read buffer).

    This was never a problem before, but now you found a case where it does matter.

     

    I've to consider to overwork the file handling to cover this case, but this will be a complicated change, and I won't have the time to do this in the next 3..4 weeks... :-/

     

    Best Regards, Thorsten.

  6. I remember that some people had the same issue with OLEDs because they don't support the 4bit mode properly.

     

    Fortunately the MBSID V2 application comes with an alternative LCD driver for 8bit mode.

    The driver can be selected with LCD type 7 in the PIC ID.

     

    Upload following application to change the ID: http://www.ucapps.de/tmp/device_id_00_lcd7.zip

    Thereafter upload the MBSID application again...

     

    For 8bit mode, D0, D1, D4, D5, D6 and D7 of the OLED display have been connected to J15:D0/D1/D4/D5/D6/D7 of the core (as usual)

    D2 and D3 have to be connected to  PIC pin RE1 and RE2, which are available at J5:A6 and J5:A7 (see schematic: http://www.ucapps.de/mbhp/mbhp_core_v3.pdf)

     

    Best Regards, Thorsten.

  7. For MBSEQ V3 the gates will be available at J5A and J5B, DIN start and stop at J10B

    4 MIDI IOs are available at J11E

     

    For MBCV V2 gates and DIN signals are only accessible via DOUT shift registers (which also act as level shifters).

    I consider to add the same possibility for MBSEQ V4 (as an option).

     

    So: if you want to create something which is compatible with both applications, go for two DOUT shift registers (resp. use a MBHP_DIO_MATRIX module)

     

    Best Regards, Thorsten.

  8. but compiling the bootloader-updater-application fails, because of the app_lcd/universal-driver. whenever you have chance, can you try to compile the updater for the stm32f4 ? there are too many errors and i agree that all these compiler-options are really a mess...

     

    I'm always doing this whenever I update central code.

    It's completely automated at my side for all derivatives - therefore I'm surprised that it fails at your side! 

     

    Maybe you've changed a file locally which is not in sync with the repository anymore?

    I would propose that you download the complete repository again (e.g. into a separate folder) and try it from there.

     

    However, I just have finalized the new universal LCD driver, again many changes in the MIOS32 base, and again the danger that you miss an update if you are doing local changes in MIOS32 sources! ;-)

     

    So - please try it again with a fresh download.

    And for the case that you are still not able to compile, here are the prebuilt binaries of the new bootloader:

    http://www.ucapps.de/mios32/mios32_bootloader_v1_014.zip

     

    Best Regards, Thorsten.

  9. I know the next gen CORE won't have USB host mode

     

    The Discovery board on the MBHP_CORE_STM32F4 module has a Micro USB socket which could also be used for USB Host direction with a special adaptor.

    It's on my long term agenda to support this, but don't expect it before summer... ;)

     

     

    I volunteer to do a board layout for this.

     

     I will come back to your offer in February/March :)

     

    Best Regards, Thorsten.

×
×
  • Create New...