Microcontroller with clocked 10-bit parallel input?

[MarkL]

Does anyone know of a microcontroller with a 10-bit (or more) parallel synchronous input?

I'm trying to passively capture the bus state going to an 16x2 character LCD controller so I can add a remote display to a piece of non-open hardware.

The data gets written to the LCD on the falling edge of the clock and I need to capture all 10 bits present on the interface at the same time.  The required hold time after the clock falls is on the order of 10ns, so I can't rely on a software solution.

It can be done easily with an external latch, but I was hoping to to keep the chip count down.

Thanks...

[vvanders]

How about a PSoC4?

Putting together a quick 10 flop sample only uses ~30% of the macrocells which should give you headroom for any other logic you could add.

[dannyf]

The required hold time after the clock falls is on the order of 10ns

That would be very difficult to most mcus to do. Simply too fast.

[fcb]

dsPIC33E/F series.  The ports are 16 bit. I use dsPIC33FJ128GP202/206 on loads of projects.

[MarkL]

Hmm... The PSOC4 is a good fit.  I'm just not too sure I want to dive in with PSOC creator again.  That ended in a lot of frustration when I tried it with PSOC3 & 5 a few years ago for a different project.  But using a PSOC is a great idea.

So, the dsPIC33 suggestion is a software-controlled read of 16 parallel bits?  Unless I'm overlooking something in the data sheet, there's no hardware clock input for 16-bit ports.  However, while looking, I noticed that some PICs have a "Slave Parallel Port", which is almost what I need.  That can latch 8 bits of input data, but I need 10.

The signals going to the LCD are EN (the clock), RD/WR, CMD/DATA, and DATA[7-0].  It's probably safe to assume that the device is not reading data back *from* the LCD (even though the LCD supports it), so I might only need 9 and assume the LCD is always being written *to*.  I need to get the logic analyzer on it to confirm.

Any PIC with TWO slave parallel ports?  Just one more bit!

[fcb]

Just re-reading what you are trying do.

I would tackle it with a pair of 74HC573's or similar, and then use your favorite microcontroller.

[mariush]

I don't think you really have to do something able to catch something within 10 ns

The lcd displays I have require about 38us (microseconds) to process a comand, at least, so the controller will be most of the time busy and you won't have "traffic" on the wires. Some commands require as much as 1.5 ms.  So between commands you'll have plenty of time to do some processing.

See the following pdf files and see the instructions and see the minimum times (for example in the Sunplus controller, see page 21-23). I doubt a product will use the absolute minimum holdup times (which seem to be about 20 ns) and if you get a microcontroller running at 48-80 Mhz or something like that, you should be able to catch pretty much everything.

SPLC780D sunplus lcd controller.pdf http://savedonthe.net/download/544/SPLC780D-sunplus-lcd-controller.html
lcd_4x16.pdf http://savedonthe.net/download/545/lcd_4x16.html

[MarkL]

Any PIC with TWO slave parallel ports?  Just one more bit!

One more bit?  I could feed the clock and that one bit into an SPI peripheral and let it capture it.  Ugly, but it *is* an edge triggered data capture device.

[MarkL]

I don't think you really have to do something able to catch something within 10 ns

I agree, probably not, but then it becomes a race condition of how long the driving microcontroller wants to leave the data and other signals valid.

I'd have to look at the logic analyzer to determine exactly what they do.  But it could also change when they upgrade their firmware.  I also don't know if they're driving other devices off that bus (but I doubt it).

Another method of attack is to record the bus state every time there's a change via pin change interrupts and then assume you have the right values recorded when the clock falls.  Again, it's a race condition, but on the other side of the clock.

There also might some micocontrollers that could support a fast DMA port read triggered by the clock to at least minimize the race window, but I'm still looking at that.

[dannyf]

via pin change interrupts

If you go through the analysis, you will find that the mcu with that kind of speed + latency necessary to react within 10ns does not yet exist.

Your best bet is external hardware (a latch or PSoC4 styled digital blocks or fpga).

If you put more reasonable constraint on the timing (aka you may not be dealing with that super-duper lcd available in 2059), you have a better shot at doing it via a mcu - For example, many of the logic analyzers use a particular silab mcu. That is an approach you could take as well - no nearly as fast to meet your 10ns timing requirement.

[MarkL]

via pin change interrupts

If you go through the analysis, you will find that the mcu with that kind of speed + latency necessary to react within 10ns does not yet exist.

Your best bet is external hardware (a latch or PSoC4 styled digital blocks or fpga).

If you put more reasonable constraint on the timing (aka you may not be dealing with that super-duper lcd available in 2059), you have a better shot at doing it via a mcu - For example, many of the logic analyzers use a particular silab mcu. That is an approach you could take as well - no nearly as fast to meet your 10ns timing requirement.

Hi dannyf,

I think maybe there's a misunderstanding about the constraints.  It's 10ns hold time.  I said that to try and head-off suggestions of a software solution like: "Wait for the clock to drop and read the pins!"

It's this module, and not the year 2059 model:

http://www.tslcd.com/uploadfile/20131126145534888.pdf

There's also a setup time of 40ns.  Without making any assumptions on how the LCD is accessed by existing software, the data capture has to meet those constraints.  After looking on a logic analyzer I might be able to see that they set up the data long before they flip the clock, or leave the data set after the clock.  But in any software solution it's a race and in the end potentially unreliable because they could change their driver.

My original question was looking for a microcontroller with the ability to latch at least 10 bits of data on the edge of an externally supplied clock.  That's all that's needed, but it seems to be an unusual requirement in today's product mix.

The PIC slave parallel port is a HW solution that almost fits the bill, but it's not natively wide enough.  I'm still fishing for any other creative solutions that might use, say, external memory buses or other synchronous peripherals.

I just hate adding extra parts when it can be done by selecting the right microcontroller in the first place.

I fully agree it's doable in PSOC or FPGA for a one-chip solution, but I'm not convinced I need that level of complexity to emulate such a lame interface.  The old Z80A peripherals could do this, for what it's worth.

[dannyf]

the data capture has to meet those constraints.

I would venture to say that you probably mis-read the datasheet. Your lcd sounds awfully likely the good old (and very slow) hd44780. The tH < 10ns spec there is for the outside signal to be present on the pins for at least that long. How long that signal will actually be will depend on how the originating device (a mcu likely) can react and I would say that in general, it is much longer than that.

The lcd itself has nothing to do with the states of those signals. So if I were you, I would actually put a logic analyzer on those pins and see in real life how fast it is before doing anything else.

As to PMP, read the datasheet and understand 1) if it asynchronous or synchronous (it is). If it is synchronous, it cannot meet your timing constraints; 2) if it is asynchronous, how would you assemble those bits together.

Basically, if you want to live by the 10ns minimum hold time, go for a hardware solution. It is highly unlikely that a mcu can do it (putting aside a mcu with internal hardware like the psoc4 or fpga+mcu type solutions).

[MarkL]

the data capture has to meet those constraints.

I would venture to say that you probably mis-read the datasheet. Your lcd sounds awfully likely the good old (and very slow) hd44780. The tH < 10ns spec there is for the outside signal to be present on the pins for at least that long. How long that signal will actually be will depend on how the originating device (a mcu likely) can react and I would say that in general, it is much longer than that.

No mis-reading here.  Perhaps you've got what I'm trying to do incorrect.

There's an MCU not under my control driving 10 pins + clock on an LCD (the MCU is not "reacting" to anything the LCD is doing).  The LCD spec says there's a 40ns setup time and a 10ns hold time on its input around the clock edge.  What this means is that the driving MCU is not REQUIRED to have valid data on the LCD pins outside of this window.

This fast timing needs a hardware latch.  No question on that.  I was looking for an MCU with a built-in latch, like the PIC parallel slave port, but with 10 bits (and I can probably get away with 9 as I mentioned).

Also, this is not a serial LCD.  It uses the ST7065/ST7066 chip set and not the HD44780.  Please read the datasheet link provided.

[hans]

Sorry, but I may still be missing something.

You're talking about the hardware setup & Hold times. But those are minimum specifications. That means the LCD will not respond properly if you drive the pins faster than that.

Moreover that signal "E" is the 'clock' signal for any data or instruction. The minimum pulse width of that is 230ns, and the period must be >500ns. That's "only" 2MHz.

Since you're already trying to hack 1 targetted 3rd party device (I suspect), why not probe the signals and see how fast it goes. Unless you're trying to make this an universal HD44780-alike-display tapper (where you may on 1 day find a device that really drives the LCD @ 2MHz), I would not worry too much or measure & verify it. Because I highly suspect a MCU with some external interrupts + 1 port wide input will do the trick just fine.

[MarkL]

No, I don't think you're missing anything.

You're right that a more detailed examination of exactly how they're driving the LCD would very likely result in a solution that could be done in software.  But it *is* dependent on what they're doing.

My approach was to take the worst case, which is the specs on the LCD.  Then it doesn't matter what the driving MCU is doing (but does assume they're adhering to the LCD specs, which should be pretty safe).  It's harder to do it this way because the timing needs a latch to meet the LCD spec, but the upside is I never have to go back and do this again if they should change the timing in their driver.  (At issue is when and how long they hold the data lines valid.)

You're also right on the clock cycle time.  I wasn't too worried that I could read data that fast, at least in bursts.  But I seriously doubt they're clocking bytes into the LCD that fast anyway.  It's just a character display and gets updated a few times a second by the looks of it.

[MarkL]

So it turns out that the PIC Parallel Slave Port has a mode (Addressable Buffered Mode) which can latch two additional bits of input.  These two additional bits are usually used as address bits, but whether they were a 0 or 1 on the clock transition can be determined by looking at some flags (IBnF).  These two bits, plus the regular 8 data bits provides the 10 bits I need without using external logic.

Thanks, fcb, for making me look at the PIC.  I think I'll try this path.  It's been years since I used a PIC in a design.

[andy_silicon]

You could consider the Cypress FX2 which has 16bit parallel bus with a capture engine.

Its been a few years since I used one - but from what I recall there is a good chance. Also these are ram devices and can be programmed via USB. They are 8051 based - and SDCC supports them.
http://www.keil.com/dd/docs/datashts/cypress/fx2_trm.pdf
Ebay is full of cheap boards which use this device.

Rgds.

[MarkL]

Hey, the FX2 is pretty interesting.  I'm looking at the CY7C68013A and friends.  I like the FIFO since then bursty writes going to the LCD are handled automatically.  And it looks like the setup and hold times are both 10ns in slave asynchronous mode.  Nice.

The FIFO structures are closely linked to the USB interface for obvious throughput reasons.  But I don't really want to drag USB into a simple display repeater if it can be avoided.  Can the FX2 still access and control the FIFO without USB?  A quick read of the manual says yes, but I need to to sit down and read the whole thing.

I've worked quite a bit with Silabs 8051 parts, so I'm already comfortable with SDCC.

No built-in flash on any of the FX2's?

This is going to need a closer look.  Thanks!

[andy_silicon]

No flash - but can be bootloaded off an i2c eeprom if you need standalone.

[abyrvalg]

MarkL, sure, you can handle FIFO data w/o sending it over USB - just don't activate "AUTOIN" feature, but look for bigger QFP version of FX2 (typical chinese boards use smallest 56 pin FX2 which doesn't have interfaces other than USB and FIFO - no way to output your data).

Edit: oops, forgot already, there are several shared GPIOs that can be stolen from FIFO even on 56 pin version, so it's still possible to communicate somehow.

[andy_silicon]

Good point though - if you want the hardware uart - don't use the 56pin device.

But it all depends how you decide to output your data.

[MarkL]

Looks like the 100 pin version makes the most sense for me.  All you get with 128 pins is external memory, and I don't see adding that.

I was planning on sending the data via one of the USARTs at logic levels to keep it simple.  I'm expecting I'll need to do a little parsing of the incoming data from the LCD so I can rebuild what's on the display, and then output that copy at a slower rate.

USB is tempting.  Although more complicated, I'm still mulling that over.  There are times when the system runs on batteries, so I need to be cognizant of how a USB choice is going to effect power consumption.

[abyrvalg]

USB is tempting.  Although more complicated, I'm still mulling that over.  There are times when the system runs on batteries, so I need to be cognizant of how a USB choice is going to effect power consumption.

Who will be on the other end of USB? If you plug it into some PC then you'll have enough power supplied via cable. Also you can simplify the FX2 part in this case: just put it into AUTOIN slave FIFO mode (there is a sample in FX2 SDK), catch the raw data on PC and do all processing there.

But if you just need to output the same data to another display few meters away then just use some MCU on the other end and UART for link (using an MCU with USB host will be an overkill for this task)

[BravoV]

Not sure if this is related, its just happened I'm in the middle of reading the new TI arm m4f mcu TM4C1294NCPDT datasheet since I just got the brand new TI Tiva C Series Launchpad EK-TM4C1294XL(Photo). There is a thread discussing this new TI product -> HERE.

Warning though, I'm no expert on this  , let alone using it since its so new. It just by coincidence, bumped at this thread while I was reading the EPI peripheral section at this mcu's datasheet. Fyi, its still not officially released yet though. 

Quoting the EPI section from the mcu datasheet below and looking from the description, it looks like the "General-Purpose mode" or the "General parallel GPIO" may fits with your need there, again, CMIIW.

External Peripheral Interface (EPI)

The External Peripheral Interface is a high-speed parallel bus for external peripherals or memory. It has several modes of operation to interface gluelessly to many types of external devices. The External Peripheral Interface is similar to a standard microprocessor address/data bus, except that it must typically be connected to just one type of external device. Enhanced capabilities include µDMA support, clocking control and support for external FIFO buffers.

The EPI has the following features:

• 8/16/32-bit dedicated parallel bus for external peripherals and memory
• Memory interface supports contiguous memory access independent of data bus width, thus enabling code execution directly from SDRAM, SRAM and Flash memory
• Blocking and non-blocking reads
• Separates processor from timing details through use of an internal write FIFO
• Efficient transfers using Micro Direct Memory Access Controller (µDMA)
• Separate channels for read and write
• Read channel request asserted by programmable levels on the internal Non-Blocking Read FIFO (NBRFIFO)
• Write channel request asserted by empty on the internal Write FIFO (WFIFO)

The EPI supports three primary functional modes: Synchronous Dynamic Random Access Memory (SDRAM) mode, Traditional Host-Bus mode, and General-Purpose mode.
The EPI module also provides custom GPIOs; however, unlike regular GPIOs, the EPI module uses a FIFO in the same way as a communication mechanism and is speed-controlled using clocking.

* Synchronous Dynamic Random Access Memory (SDRAM) mode

• Supports x16 (single data rate) SDRAM at up to 60 MHz
• Supports low-cost SDRAMs up to 64 MB (512 megabits)
• Includes automatic refresh and access to all banks/rows
• Includes a Sleep/Standby mode to keep contents active with minimal power draw
• Multiplexed address/data interface for reduced pin count

* Host-Bus mode

• Traditional x8 and x16 MCU bus interface capabilities
• Similar device compatibility options as PIC, ATmega, 8051, and others
• Access to SRAM, NOR Flash memory, and other devices, with up to 1 MB of addressing in non-multiplexed mode and 256 MB in multiplexed mode (512 MB in Host-Bus 16 mode with no byte selects)
• Support for up to 512 Mb PSRAM in quad chip select mode, with dedicated configuration register read and write enable.
• Support of both muxed and de-muxed address and data
• Access to a range of devices supporting the non-address FIFO x8 and x16 interface variant, with support for external FIFO (XFIFO) EMPTY and FULL signals
• Speed controlled, with read and write data wait-state counters
• Support for read/write burst mode to Host Bus
• Multiple chip select modes including single, dual, and quad chip selects, with and without ALE
• External iRDY signal provided for stall capability of reads and writes
• Manual chip-enable (or use extra address pins)

* General-Purpose mode

• Wide parallel interfaces for fast communications with CPLDs and FPGAs
• Data widths up to 32 bits
• Data rates up to 150 MB/second
• Optional "address" sizes from 4 bits to 20 bits
• Optional clock output, read/write strobes, framing (with counter-based size), and clock-enable input

* General parallel GPIO

• 1 to 32 bits, FIFOed with speed control
• Useful for custom peripherals or for digital data acquisition and actuator controls

The EPI peripheral is part of the "System Modules" :

[MarkL]

USB is tempting.  Although more complicated, I'm still mulling that over.  There are times when the system runs on batteries, so I need to be cognizant of how a USB choice is going to effect power consumption.

Who will be on the other end of USB? If you plug it into some PC then you'll have enough power supplied via cable. Also you can simplify the FX2 part in this case: just put it into AUTOIN slave FIFO mode (there is a sample in FX2 SDK), catch the raw data on PC and do all processing there.

But if you just need to output the same data to another display few meters away then just use some MCU on the other end and UART for link (using an MCU with USB host will be an overkill for this task)

After reading some more about what it would take to do it via USB, I agree.  It wouldn't be a PC on the other end anyway; I was thinking something more like an R-Pi if it was USB.  I'm going to stick with a UART and another MCU on the remote display as was my original plan.

The application, if you're curious, is remote display of two MPPT charge controllers in a mobile solar power system (4x180W panels + 12V battery bank).  The controllers could not be mounted where they were visible and they have no native remote capability.  The controllers also have some keypad inputs (non-matrixed) and some LEDs to remote too, but those are trivial.  The remote would not be more than a few meters away.