Hi,

This is my first post in this community. The project I'm planning would be driving an LED display module (MIPI interface) from an MCU along with a few other devices. This is probably going to be the most involved piece and I'm trying to figure out: 

A) if I'm selecting the right device to drive it. Right now I'm looking at 8-bit PIC but I might find out down the road that I need to select another.

B) if another MCU comes with driver capability onboard that will make this setup easier. I saw STM32 has a MIPI interface so I should probably go with something like this...

Is anyone available to do a quick google hangouts call or something to talk through a couple of the components and offer your advice? I don't expect it to be perfect but something like this could save time on the front-end since I'm just doing searches here to find different things and am reading to see what will work and what is needed. Maybe there's something I'm not seeing that makes this a lot easier.

In total it would be reading from (4) push buttons, (2) LCD character 16x2 displays, (1) LCD display module, (1) keyboard... I'm considering knocking out the LCD display for now and replacing it with character displays though since this is clearly the most expensive and difficult part to pull off, however adding a nicer end experience.

So in summary, what would be the best MCU for driving these devices? And where can I find a MIPI breakout board to test this if I go with the screen?

Thank you,

Nick

If you're new to uController development, I'd suggest trying to fit it into an 8 bit device. I looked at the STM32 and saw a learning curve roughly as a wall. Others will differ, but at my age, I just don't integrate data into info as 20 ago. I adopted the STM8 and Really like it. Like any uC, it has tradeoffs, but I found it easy to learn - BIG upside by me. Then again I've been coding assembler since '78.

You need to be a Lot more specific, not on what it does, but more how it needs to do it. Things like loop response time (keyboard reads to display updates, etc), data tables and variables, math precision. Basically what does it need to do in how much time, worst case (then add 25+%).

I agree with using a character LCD instead of graphic, for now. You can always port in the graphics if the code is modular (it IS isn't IT?!). Good Hunting  <<<)))

While I agree that learning a 32-bit uC coming from an 8-bit background might be steep, it's not really the core that makes it hard. It's just what surrounds it. With a 32-bit core you can do so much more than with an 8-bitter, so these chips contain sophisticated peripherals, including fairly complex power and clock management and pin configurations and whatnot, so just to set up the run-time environment for the core is usually at least one page worth of C code.

But the core itself is simple. I have done a fair amount of assembly programming on all sorts of 8, 16 and 32 bit chips and I write hand-crufted speed/size optimised library routines for the ARM as well. It's assembly is actually simpler than that of an 8-bitter, because the instruction set is reasonably orthogonal, its load-store architecture offers pretty good addressing modes (that don't cost you extra clocks!) and it has a pretty clean instruction set. Plus, it's a 32-bit ALU and register file, so it doesn't really matter whether your data are 8, 16 or 32 bits. You load an 8-bit datum into a 32-bit register, signum extended if you are so inclined, and work with it. Easy as.

Hmmm, so it's the classic "once you get the first little code running" the rest cascades into line ?

Whee, an orthogonal addressing aspect I MUST explore. I wrote a fair amount of MC68000 code and LOVED it. If the STM32 has those features, maybe the learning curve became justified. Any beginners guides to absolute assembler examples?

That series of chips has So many features simple 8 bit folks get flooded by the possibilities.

Not trying to hijack the thread, a PM or pointer of "go here next" is Fine by me. Good Hunting - by Me - Eyes open  <<<)))

Well, ARM has many instruction sets. There was the original 32-bit ARM ISA. Then, for embedded systems they came up with a more code-space efficient limited subset, called THUMB. Don't worry about those, as they are kind of in the past. 

What you might want to look at is their Cortex-M0 (low-end, entry-level) cores and the Cortex-M3 (quite powerful) cores. There are two books that I can suggest, both are written by Joseph Yiu: The Definitive Guide to ARM Cortex-M0 Processors and The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors (the M4 is M3 with a bunch of DSP instructions and optional float point added).

If you liked the m68k, you will like the Cortex-M3 and will be a bit frustrated by the M0, but if you look at the M0 with an 8-bit eye, it will still feel like opening the door to a new universe.

Thanks Kocsonya for the detail, M3 sounds like a great winter endeavor. But, to the OP now (Captain wants the plane back).

It would be waiting for a keyboard input, writing that keyboard input to the LCD displays, changing line when enter is pressed, then continuing to display it, and then shifting those strings to different displays when the PIC reads certain button press conditions (4 connected buttons to adjust score).

If the LCD character displays are 16 pins with standard 1602:

1602 standard 16-pin interface, including: Pin 1: VSS is the ground power. 

2 feet: VDD then 5V positive power supply 

3 feet: V0 LCD contrast adjustment end, then the positive power supply when the contrast is the weakest, the highest contrast when grounded power, the contrast is too high will have a "ghosting", when used by a 10K potentiometer to adjust the contrast. 

4 feet: RS for the register selection, high-level data register selection, low-level instruction register selection. 

5 feet: R / W for the read and write signal lines, high-level read operation, low-level write operation. 

6th foot: E end is enable end, when E end jumps from high level to low level, the liquid crystal module carries out the order. 

7 ~ 14 feet: D0 ~ D7 for the 8-bit bidirectional data lines. 15 feet: the positive power supply backlight 16th foot: backlight power negative

Then correct me if I'm wrong - I believe I can use UART, SPI, or I2C. So if one of the 8-bits the PIC18F26K40 supports 2 UART, 2 SPI, and 2 I2C, then I should be able to drive 6 off this thing. The point is two are on player side and the other screens are future players. If that works then I have 2 on either end and 4 in the center where they can display 8 names which would be good. Have I missed anything in this assumption? Then I still need to read from the keyboard and 4 push buttons. I might need multiple PICs in which case they can communicate to each other with SPI and then each will share some of the I/O work. In total, 4 ADC for push buttons, 6 LCD character displays, and a keyboard which could go through a USB-UART converter and be handled as another serial device. That's the whole thing. 

I apologize if this seems disorganized, just trying to confirm the thinking.

EDIT: From Digital Peripherals for PIC18F26K40:

• Serial Communications: – Two Enhanced USART (EUSART) with Auto-Baud Detect, Auto-wake-up on Start. RS-232, RS-485, LIN compatible – SPI – I2C, SMBus and PMBus™ compatible 

• Up to 35 I/O Pins and One Input Pin: – Individually programmable pull-ups – Slew rate control – Interrupt-on-change on all pins 

 If the PIC has 35 spare I/O pins, those can also be used to drive the LCD displays right? If each LCD char is 4-wire protocol that's 4 * 8 LCD displays requiring 32 lines which could all be from the I/O pins? Or would I have to drive the 8-bit bidirectional data lines on LCD character displays for each. In this case requiring 8 I/O pins per display in addition to available SPI/I2C.

I've written for Many different LCD chr units, 1602s are like Corn Flakes. The only difference I've seen is starting address of each line, or half line.

It's a parallel interface: on powerup you initialize to be 4 or 8 bit data, then set cursor options. You can run multiple LCDs in either mode by paralleling the data, R/W* and C/D* just using separate E lines. So 6 displays would need 12 lines (data(4),R/W* & C/D*) plus 6 of E. If you've got the lines go 8 bit, I rarely do, 4 bit is slower but works for my projects. 

I tried the PIC series, got frustrated, but it may do well for you. I'm pretty sure an STM8 (I like the 105S series) would do Very well. G.H.  <<<)))

MIPI DSI is a specification to delivers video (and configuration) data with high-speed differential signalling. I doubt that an 8-bit PIC could do it. An ARM based chip most likely, but you need to send the raw video over it, which means that you need to have a frame buffer, which is usually a lot of memory.

There are displays out there that use the FT81x chip, which drives the display and you talk to the chip via SPI, orders of magnitudes simpler than DSI.

What do you want to build?

Thanks for the replies. Kocsonya, I think you've confirmed that in order to get the process down with a simplest version I should just move forward with 8 bit MCU driving character displays. This functionality can be added later if I can buy myself that kind of time. Needs to start more basic first.

It's a part of a standalone game type thing. It's just meant to take text from the keyboard, and show it on the character displays. They'll be pushed to other displays or replaced when certain pushbutton conditions are met. There's some basic scorekeeping functionality which is incremented on the device with pushbuttons. That's basically it, just takes in a list and moves it around along with keeping score. Hope that makes sense

I'm currently working on a Microchip Curiosity HPC to try and get certain functions down and tested. I think it can all be run with PIC 8 bit chips, but I'm still not totally clear how many I need. Looks like the LCD character displays have 16 pins. Does that mean it would have to be a bunch of PICs communicating with each other that drive each LCD character display?

Currently still working out exactly what peripherals must be used and pick a device. Hopefully if so it is available in PDIP so I can put it together myself instead of having to get a PCB designed.

I came from 8 bit world - we had 8 bit PARALLEL ports. the 32-bitters are hard to get a good parallel port read - its all I2C/SPI now-a-days.  With the faster chips (>80 Mhz) you can load up each GPIO pin , then 'strobe' the device/chip select and get a pseudo-PORT.  Some of the earlier ARMs had a fastGPIO setup - never looked into it.

Another issue is keybutton noise for mechanical switches - haven't done the rubberized-carbon type.....

WAtch out for USB data transfers - if you need to 'reset' the PCB, then Windows & Linux resets the USB assignments and you loose data/time/etc.

I personally like the serial ports though they are hard to find. some of the USB/serial dongles will reset your board !!!!

DISCLAIMER: I use these NXP-based ARM products and have been beta-testing some of the designs.

No, I don't get a commission , etc. {don't even mention my name}

Any way - I am using the "Coridium.us" products. He has a very good ARMBasic software product and many eval pcb's.  

I currently use the LPC54005/LCD kit.  The display can be set up for landscape mode, has a goodly amount of GPIO. I've tested the older 4330 {it has an LCD driver on board that I have not dealt with}.  His ARMstamp is a good beginning and I have done a project on it also - see the forum - I go by Olzeke51 most of the time. Tod Wulff (Megahurtz) also has contributed to the forum and even some of the pre-made Libraries.

I have put the 16 x2 LCDs on his boards.

I hear what you're saying about the USB to Serial. Since I want to use a waterproof IP68 keyboard I found that there was a cheaper USB keyboard, but I would rather just take the PS/2 signal so I think I will stick with that and use it on USART

Ah, seeing more, I'll suggest a uC for each display and a central one as master. More hdwe, but the slaves are easy, master is also easier since it isn't doing it all. It also allows expansion to many more than 6.

Here a PIC would do well. If all your slave display text lines are common, they can be distributed. If sending, say count updates, those can be part of the master/slave command set. A tip: that you go this way, leave room for half-again more commands as later things pop up. It's a Lot harder to recut your protocol than having a little more latency for more options. G.H. <<<)))