Antichambre

Have fun ! Bruno

One which uses the LCD routines, you can write it. ///////////////////////////////////////////////////////////////////////////// // Include files ///////////////////////////////////////////////////////////////////////////// #include <mios32.h> #include "app.h" #include <glcd_font.h> ///////////////////////////////////////////////////////////////////////////// // Local variables ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// // This hook is called after startup to initialize the application ///////////////////////////////////////////////////////////////////////////// void APP_Init(void) { // initialize all LEDs MIOS32_BOARD_LED_Init(0xffffffff); } ///////////////////////////////////////////////////////////////////////////// // This task is running endless in background ///////////////////////////////////////////////////////////////////////////// void APP_Background(void) { int i; // clear LCDs MIOS32_LCD_DeviceSet(0xff); //select all lcds MIOS32_LCD_Clear(); // endless loop while( 1 ) { for(i=0; i<16; i++){ MIOS32_LCD_DeviceSet(i); MIOS32_LCD_GCursorSet(0, 0); MIOS32_LCD_FontInit((u8 *)GLCD_FONT_NORMAL); // 6x8 font MIOS32_LCD_PrintString("This is a test for:"); MIOS32_LCD_GCursorSet(0, 8); MIOS32_LCD_PrintFormattedString("LCD#%02d ", i); } } } something like that... obviously you must include the app_lcd in your makefile: # application specific LCD driver (selected via makefile variable) include $(MIOS32_PATH)/modules/app_lcd/$(LCD)/app_lcd.mk check your LCD variable is "universal", of course. And LCD must be configured in your bootloader(updater) Did you check it?

I was serious with the bootloader check, but doesn't matter... Did you try an app with a correct clear of the oled on init and write something after... (not just the legacy boot sequence) ???!! But Andy is maybe right, you have to check your core boards first and the resistance network there's on the J15 lines, check the 595 too it can put too much load on the RS line. If the boards you use are not the ones you made, swap the cores of the two mbhp to see if it comes from board or Core...

first go in your bootloader updater (terminal) and check if there's difference in the configuration between the two cores...

Yes it was happened to me recently, it was a bad clearing in software... The noise appears on startup you have to clear it correctly. MIOS32_LCD_Clear

I received the boards, I paid extra 25€ for customs, it seems Serbia is not an European country Grrrrrrr ... this is the first reason why I will quickly redesign this board, the second reason is that it works fine. Have a good day Bruno

Yes it makes sense, one side of your ribbon seems to be wrong (left connector on your picture) Welcome here... Best regards Bruno

You know that you've got the same thing here with the line driver same principle ;) best Bruno

Ah ok this is not ethernet! You will just use Cat5e cable to transmit a "balanced" MIDI. like the RS422 is the balanced version of the RS232 This is just an extender, that's great.

Kissbox so.

No no don't worry, my fault I kept it secret, but it's ready now! No SPI port on your "circuit"?

Or you just wait a few... I've got a surprise .

yes for sure! MikroE is expensive in general but the work is done here. I will not waste time around design, at least in the beginning. it will save time, adding this proc to my MIOS first and in a second time I will optimize the board for the MIOS. I don't want to buy this each time I need it. It's a good start and the format(size) I need. I already ordered one, shipping is expensive too. Try to reuse Andy's USB and SD Cards maybe, just change the main board. And MIDI8 or legacy MIDI_IO Module

I just found this: https://www.mikroe.com/mini-stm32f4 which is exactly what I wanted to do. Then I don't need mnmlCore anymore Best Bruno

smaller Your idea from beginning...

Yes, some small adaptation have to be done in MIOS32, but not in App(except if it use a port we removed). Not very complicated if we stay in the same uC family, and everything can be tested before PCB design with a waveShare 405

Hello, this is an excel chart I use for pin mapping, just as example. Here I tried to map the pin of a STM32F405RG LQFP64 to the needed MIOS32 functions: - 3 SPI and their respective RC, J16, J8/9 and J19. - 2 UARTs (2 MIDI ports) - 1 SDIO port for SD Card - USB FS, static Upstream, but ID can be added for downstream - USB HS in FS Mode for static Downstream. - 4 ADC - 1 I2C - 1 CAN - The User button - No LED - I kept some lines to connect a serial screen like OLEDs. Just a basis for work, DMAs should also be taken into account! Best regards Bruno PS: I can share the whole chart

You connect the BLM directly to your main Core32? What is the use of the FPGA? handling the BLM part?

Then you want to replace the miniCore of your BLM by a FPGA?

Just maybe for the RAM, more RAM could be fine, but Yes everything else is enough. That's the reason it should be fine to try to put the SD Card on SDIO, e.g. this will help to change presets in RAM quicker. And in the same time it will unload the J16 SPI of course. Then yes I reach it sometimes but I always found a workaround for the moment. And this is enough ;)

Changing the uC, adding a new family is a lot of work, even if we stay in the STM32F family, e.g. from STM32F4 to STM32F7 between the 2 references ST changed the Low-Layer Driver, The F7 has HAL new driver now and MIOS32 was written around the old driver. This is not easy to do mostly for the Bootloader part of the MIOS32. This is deep changes first, and a lot of support after to fix issues and bugs! Here don't want a new Core, just a smaller version of the existing one. As I already said, we need a clever alternative to the existing big Cores, not a concurrent, Andy's new wCore is already available for normal purpose, and I've got 4 running wCore for my experiences, I can say that's a good one. Interesting, which brand and model you use?

Because it's a lot of work...

Beautiful ! I like the light which falls like ink from the top of trees. I hope you used an old cam for that ;)

Hello Guys, Putting the stm on DIP40 package was just an idea!!! Something we have to talk about... I checked and the problem is not the design, a small 64pin stm32f405rg or an old stm32f103 can fit on DIP40 board. But replacing a PIC on a Core8 will require some level shifting to get the exact same pinout and port cause the core8 is fully 5V. Yeah! was just an idea... For me the minimum ports are - the USB, the OTG FS - J8 / 9 in 5V Spi for SRIO - J16 / J19 an other SPI 5v / 3.3V switchable. - J11 can be reduced to 1 or 2 MIDI ports - by reducing the used port we can maybe put the sd card in SDIO instead of the regular SPI...(speed-up) - we can maybe limit the LCD to a serial connection, no more // connection. - reduce the number of I2C and Analog I/O. - It will probably seem stupid, but I want to keep the CAN port on ;) About the USB, for the moment the Core uses the OTG FS, but there's the extra OTG HS which can be used in FS and maybe limited to a HID and/or MIDI devices connection.

personally this is what drives me to give them a helping hand when I can, thanking them for giving us this opportunity. There will be just some basic and obvious rules to respect which we had a little talk ... as for example: good documentation must be provided to be marketed, the creator is responsible for the support of his project..( and logic stuff like that...)