nsunier

You have done a so beautiful, precise, well-thought work! I am very impressed. Nice of you to share your experience with us.

Maybe it could worth to create a new dedicated topic with a well documented post with pictures, specs, ... in order to interest more people.

I could be interested in buying about 10 pcs of C-51850NFQJ-LG-ACN. Please send me a PM if that becomes a reality.

Hi mr_DK, At this time, I've received 2 samples from SK. One with RGB backlight and another one with "only" red/green backlight. I've stopped the development due to the lack of time. But for sure I'll continue. At this time I've only partially developed the architecture of a VHDL design for a Xilinx Spartan3 FPGA and built a small PCB to fit these 2 samples with my FPGA developer's kit. Have you knowledge of VHDL design?

I'm not convinced that a serial interface is a good solution. There is a lot of information to transmit in order to update the complete display information: about 110 bytes per button. The idea is to allow up to 20 buttons. At first I'm considering parallel interface. I think it should not be a problem to affect a CORE module to only manage these buttons (like motor faders which require many resources). MIDI-link could be used to allow using other features like LCD, faders, ... What do you think about that?

I'm wondering if I it's a good idea or not to develop a CPLD or a FPGA to interface the screenkeys. The functions to include in this component are listed below: generate and distribute the continuous clock to the screenkeys without monopolizing the uC the screenkeys are write-only, then the CPLD/FPGA will have independant registers which could be written and read by the uC the screenkeys button pressed is a simple contact then I could add a register which contains this information What do you think about the points above? Now, I need some informations about the MIDIBOX architecture. What is the "best" communication interface which could be simply added to the existing PIC-based system and to the new ARM-based one? Please feel free to add all your questions/comments. I want to design something which could really be useful and which is well thought in harmony with the existing system.

I'm sorry but I can't find the topic called: "programmer's lounge". Can you give the direct link? About the MBHP_CORE_STM32 module: this design is much more powerful than the PIC-based one. 1. I think it would be better to directly start with this new concept. Is it a good idea? Is the design sufficiently mature and stable? 2. Even if some features are disabled by using the SPI ports, it is not a problem. I'm planning to use 2 or 3 CORE modules in chain (MIDI-link). Can I mix ARM-based CORE modules with PIC-based ones? 3. Have you (or anyone) designed a working printed circuit board? If yes, can I get the files in order to make them? It is not a problem for me to solder SMD parts. Best regards, Nathanael

Hi TK, Thanks for your answer. Not all is clear for me but I'll try it by myself and than ask you for more specific details. It will be probably in a couple of weeks because I still not have received my ordered CORE module. In addition I need some time to experiment. In the meantime can you tell me more about MBHP_CORE_STM32? What is this new project? Are you planning to upgrade the core module with a new uC (still a PIC)? If yes, I've you an idea of the release date? If it isn't in a too long time, I probably would have better to go directly with this new architecture!? Best regards, Nathanael

Hello, This message is specially intended for TK. I intend to develop an interface for screenkeys. I've acquired two of these buttons. It's simply a synchronous serial data communication interface (clock + data). The only negative point is that clock has to be permanent in order to refresh the LCD. The faster is the clock (50kHz min to 4MHz max), the faster will be the access and the display refresh rate. But before beginning, I would like to know the opinion of TK. What are the hardware and software possibilities of a core module? I would not like to develop a hardware and/or a software which goes against the architecture developed by TK. Thanks for your help.

Hi Michael, Ok, now I understand well. Is it possible to define a 9bit or 67bit structure? Or is it limited to a single 8bit data? Best regards, nsunier

I haven't noticed about this very useful function. Thank you! ;) I've another question about the example header "main.h": // status of analog toolbox application typedef union { struct { unsigned ALL:8; }; struct { unsigned DISPLAY_UPDATE_REQ:1; // requests a display update }; } app_flags_t; What is the function of the 8 bits named "ALL"? Best regards, nsunier

My C course is several years old and I don't remember very clearly one thing. I've defined an array: unsigned char cur_but_solo[96]={0}; In my code, sometimes I set one value of this array to 1 or reset to 0. At the end, I want to check is this array is still equal to {0} without using a for loop. Is there a "clean" way to proceed? Best regards, nsunier

The GLCD_FONT_NORMAL font is initialized in the void DISPLAY_Init(void) function. When do you display your copyright message? Before when this function is called? For the reboot message, yes it's acceptable. Best regards, nsunier EDIT Oups! :'( I've read too quicly your previous answer. If I put the initialization in the Init() function, it works!

:D It works now! But... The system font used for your copyright message and for the rebooting message is corrupted. How can I modify the MIOS in order it uses the new font? Best regards, nsunier

It's just a question. I've added the new font (and disabled all unused ones: like I was already doing). And I get this message: rm -rf _output/* rm -rf _output rm -rf *.cod *.map *.lst rm -rf *.hex mkdir -p _output sh ./bin/mios-sdcc -c -mpic16 -p18f4620 --fommit-frame-pointer --optimize-goto --optimize-cmp --disa ble-warning 85 --obanksel=2 -pleave-reset-vector -I./src -I ./include/c -I ./modules/glcd_font -DDE BUG_MODE=0 modules/libdev/pic18f4620.c -o _output/pic18f4620.o ./bin/mios-gpasm modifies _output/pic18f4620.asm, result in _output/pic18f4620__mios-gpasm-tmp.asm sh ./bin/mios-gpasm -c -p p18f4620 -I./src -I ./include/asm -I ./modules/app_lcd/ks0108 -I ./modules /glcd_font -DDEBUG_MODE=0 -DSTACK_HEAD=0x37f -DSTACK_IRQ_HEAD=0x33f -I ./modules/mios_wrapper modul es/mios_wrapper/mios_wrapper.asm -o _output/mios_wrapper.o sh ./bin/mios-gpasm -c -p p18f4620 -I./src -I ./include/asm -I ./modules/app_lcd/ks0108 -I ./modules /glcd_font -DDEBUG_MODE=0 modules/app_lcd/ks0108/app_lcd.asm -o _output/app_lcd.o sh ./bin/mios-sdcc -c -mpic16 -p18f4620 --fommit-frame-pointer --optimize-goto --optimize-cmp --disa ble-warning 85 --obanksel=2 -pleave-reset-vector -I./src -I ./include/c -I ./modules/glcd_font -DDE BUG_MODE=0 main.c -o _output/main.o ./bin/mios-gpasm modifies _output/main.asm, result in _output/main__mios-gpasm-tmp.asm sh ./bin/mios-gpasm -c -p p18f4620 -I./src -I ./include/asm -I ./modules/app_lcd/ks0108 -I ./modules /glcd_font -DDEBUG_MODE=0 modules/glcd_font/glcd_font_normal.asm -o _output/glcd_font_normal.o sh ./bin/mios-gpasm -c -p p18f4620 -I./src -I ./include/asm -I ./modules/app_lcd/ks0108 -I ./modules /glcd_font -DDEBUG_MODE=0 modules/glcd_font/glcd_font_big.asm -o _output/glcd_font_big.o sh ./bin/mios-gpasm -c -p p18f4620 -I./src -I ./include/asm -I ./modules/app_lcd/ks0108 -I ./modules /glcd_font -DDEBUG_MODE=0 modules/glcd_font/glcd_font_meter_icons_v_big.asm -o _output/glcd_font_m eter_icons_v_big.o gplink -s ./etc/lkr/p18f4620.lkr -m -o project.hex _output/pic18f4620.o _output/mios_wrapper.o _outp ut/app_lcd.o _output/main.o _output/glcd_font_normal.o _output/glcd_font_big.o _output/glcd_font_met er_icons_v_big.o error: no target memory available for section ".MIOS_EEPROM_ReadPage" make: *** [project.hex] Error 1 Where is the extra available memory of the PIC18F4620? Best regards, nsunier