-
Posts
15,198 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by TK.
-
-
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.
-
Yes, this should work.
Best Regards, Thorsten.
-
KS0108 works at my side (I can only check the non-inverted type, 0x80)
Best Regards, Thorsten.
-
Please note that I just had to change the schematic.
J10B.D11 is now connected to PE2, and not to PE3 anymore to solve a conflict with the onboard MEMs chip.
Best Regards, Thorsten.
-
This results into the same problem like for the AOUT module, because also DINs/DOUTs are scanned with superfast SPI.
+ the big problem that the connections to LCD (and OLEDs) should be short as well (<= 30 cm)
Best Regards, Thorsten.
-
Yes
Best Regards, Thorsten.
-
Thanks! :)
Best Regards, Thorsten.
-
This kind of buffering is not sufficient for the superfast SPI signals. I hope that the signal quality can be improved with differential drivers.
Best Regards, Thorsten.
-
Novski, could you please do me a favor and check if following binary is still working at your side?
-> http://www.ucapps.de/tmp/mios32_test_app_lcd_ssd1306_LPC1769__20140119.zip
In the last days I did some changes in the LCD driver to support STM32F4.
I want to ensure that I haven't broken the LPC17 variant before releasing a new bootloader (and MBNG) firmware
Best Regards, Thorsten.
-
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.
-
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 AOUTTransfering 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.
-
Highlight: the break at 1:20 while the plane targets the moon! :thumbsup:
Best Regards, Thorsten.
-
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.
-
For MBCV V2 I guess J5A/B will be used as analogue inputs then?
Yes
Best Regards, Thorsten.
-
Did you try the "debug on" mode? It reports the function calls during an event is processed.
It could help you to understand, under which circumstances the LED status is changed.
Best Regards, Thorsten.
-
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.
-
Reichelt hat ein paar recht guenstige Knoepfe im Angebot, so wie bspw. diesen: http://www.reichelt.de/KNOPF-10-150E/3/index.html?&ACTION=3&LA=446&ARTICLE=73960 und diesen: http://www.reichelt.de/KNOPF-13-164E/3/index.html?&ACTION=3&LA=446&ARTICLE=73962
Allerdings haben die keine Markierung; die muesste man sich selbst draufmalen.
Gruss, Thorsten.
-
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.
-
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.
-
Do i have to do anything more after uploading setup_midio128.hex for sensing the buttons of DIN module?
Yes, for PIC based applications you've to upload MIOS8 first, thereafter upload the application (MIDIO128)
Best Regards, Thorsten.
-
You've to disable the datawheel encoder with:
# SR Pin Type ENC_DATAWHEEL 0 0 DETENTED3
Or you've to assign it to different pins
Best Regards, Thorsten.
-
Yes, no problem.
Use this template for your C++ applications: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftemplates%2Fapp_skeleton_cpp%2F
Here a typical application which applies object oriented C++ code (located under src/components): http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fprocessing%2Fmidibox_cv_v2%2F
Best Regards, Thorsten.
-
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.
-
Ok, added this chip to my Reichelt shopping basket (I will order by end of this month... ;))
Best Regards, Thorsten.
STM32F4-CORE and LCD-Display
in Testing/Troubleshooting
Posted
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.