screenkeys

[nsunier]

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.

[TK.]

Hi Nsunier,

it would be a nice addition to the platform :)

The permanent clock requirement is tough for an application, which is doing a bit more than just outputing graphic icons. It wouldn't be a problem so long a dedicated SPI port would be available for these displays, but this would lead to too many restrictions for the 8bit platform.

Therefore I propose to evaluate following approach:

connect CLK input to J10:PWM (PIC pin RC2), and configure this pin to output 1 MHz (the MBSID application contains a configuration example)

Use any other free pin as data line. It has to be 1 so long no data is transfered.

In order to send data, disable interrupts, synchronize to the rising clock egde by polling RC2 input register (wait for the rising edge), set the data line, wait for the next rising edge, etc... until all bits are sent. Thereafter switch back the data line to 1 and enable interrupts again.

At 1 MHz, the CPU can execute up to 10 instructions (note that a branch/goto will cost 2 cycles!) - this should be sufficient, considered that the driver is written in assembly.

Future compatibility with MBHP_CORE_STM32:

I've proven, that this clock synchronisation method also works with STM32F103, see sid.c driver.

At 72 MHz, there are enough cycles free so that assembly language isn't really required. Even 4 MHz should be achievable.

Alternatively, we could use one of two available SPI ports of the MBHP_CORE_STM32 module (J9 or J16) for full background control w/o bitbanging. This would restrict some usecases (e.g. DOUT SRIO or I2S normaly connected to J9, SD Card normaly connected to J16), but would unload the CPU almost completely, so that LCD transfers can be handled from a background task w/o disabling interrupts. As most application won't require a SD Card, J16 is really predestinated for such jobs.

I hope that this information wasn't too confusing...

Best Regards, Thorsten.

[nsunier]

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

[TK.]

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!?

You will find postings about the details and progress in the programmer's lounge, just one board above this one.

STM32 is not a PIC, it's an ARM Cortex-M based 32bit microcontroller - much more horsepower, much more memory, much easier to program, perfect choice for programming beginners due to less limitations for almost the same price. Only disadvantage: it's a SMT device, therefore hard to solder. Maybe pre-assembled boards could be provided later, but currently you've to solder the chip by yourself.

Best Regards, Thorsten.

[nsunier]

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

[TK.]

Everything answered in the lounge... since it's a section only for programmers, you have to be logged in to read it!

http://www.midibox.org/forum/index.php/board,37.0.html

Best Regards, Thorsten.

[nsunier]

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.

[lucem]

Since the respective IP Cores are readily available for FPGAs at least, attaching such a solution to the IIC bus is probably the best solution.

This way, on the hardware side nothing needs to be added except for level converters to adapt to the 3V3 or 2V5 levels FPGAs normally use (which would belong on the FPGA side anyway), and on the software side of things IIC bus handling is already in the formware, so only higher level code would need to be written.

Level conversion can be done easily using resistors (simplest approach) or MOSFETs (standard conformity).

Plus, IIC operations don't happen too frequently, thus collisions are unlikely to happen.

[nsunier]

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?

[mr_DK]

Hello,

I was also thinking of using some of those nice screenkeys. I was wondering if there's any progression on this matter?

If there's anything I can try to help with?

Best!

[nsunier]

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?

[mr_DK]

Hey nsunier,

Sorry for the late reply, I'm not familiar with the Xilinx system (I know what it is, but that's where it ends...)

I would rather try to fit it in MidiBox... So I think I'm not really able to help, you probably know much more about Xilinx then I do  ;)

Sorry, and good luck!

Best