Microcontroller with clocked 10-bit parallel input? - Page 1
Forum section: electronics / general

author: MarkL
author_rank: Unknown
timestamp: March 30, 2014, 08:32:34 pm
content: 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...

author: vvanders
author_rank: Regular Contributor
timestamp: March 30, 2014, 09:19:57 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: March 30, 2014, 09:34:06 pm
content: QuoteThat would be very difficult to most mcus to do. Simply too fast.

author: fcb
author_rank: Super Contributor
timestamp: March 30, 2014, 09:44:41 pm
content: dsPIC33E/F series. The ports are 16 bit. I use dsPIC33FJ128GP202/206 on loads of projects.

author: MarkL
author_rank: Unknown
timestamp: March 30, 2014, 10:51:34 pm
content: 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!

author: fcb
author_rank: Super Contributor
timestamp: March 30, 2014, 11:09:41 pm
content: 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.

author: mariush
author_rank: Super Contributor
timestamp: March 30, 2014, 11:20:05 pm
content: I don't think you really have to do something able to catch something within 10 nsThe 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.pdfhttp://savedonthe.net/download/544/SPLC780D-sunplus-lcd-controller.htmllcd_4x16.pdfhttp://savedonthe.net/download/545/lcd_4x16.html

author: MarkL
author_rank: Unknown
timestamp: March 30, 2014, 11:31:24 pm
content: Quote from: MarkL on March 30, 2014, 10:51:34 pmOne 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.

author: MarkL
author_rank: Unknown
timestamp: March 30, 2014, 11:44:22 pm
content: Quote from: mariush on March 30, 2014, 11:20:05 pmI 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.

author: dannyf
author_rank: Super Contributor
timestamp: March 31, 2014, 12:53:36 am
content: QuoteIf 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.

author: MarkL
author_rank: Unknown
timestamp: March 31, 2014, 01:45:14 am
content: Quote from: dannyf on March 31, 2014, 12:53:36 amHi 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.pdfThere'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.

author: dannyf
author_rank: Super Contributor
timestamp: March 31, 2014, 10:32:52 am
content: QuoteI 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).

author: MarkL
author_rank: Unknown
timestamp: March 31, 2014, 02:25:21 pm
content: Quote from: dannyf on March 31, 2014, 10:32:52 amNo 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.

author: hans
author_rank: Super Contributor
timestamp: March 31, 2014, 02:42:30 pm
content: 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.

author: MarkL
author_rank: Unknown
timestamp: March 31, 2014, 11:20:36 pm
content: 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.

author: MarkL
author_rank: Unknown
timestamp: April 01, 2014, 05:34:29 pm
content: 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.

author: andy_silicon
author_rank: Regular Contributor
timestamp: April 02, 2014, 06:41:12 pm
content: 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.pdfEbay is full of cheap boards which use this device.Rgds.

author: MarkL
author_rank: Unknown
timestamp: April 02, 2014, 07:44:37 pm
content: 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!

author: andy_silicon
author_rank: Regular Contributor
timestamp: April 02, 2014, 08:27:16 pm
content: No flash - but can be bootloaded off an i2c eeprom if you need standalone.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: April 02, 2014, 09:02:13 pm
content: 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.

author: andy_silicon
author_rank: Regular Contributor
timestamp: April 02, 2014, 09:55:38 pm
content: 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.

author: MarkL
author_rank: Unknown
timestamp: April 02, 2014, 11:13:04 pm
content: 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: April 03, 2014, 07:53:11 am
content: Quote from: MarkL on April 02, 2014, 11:13:04 pmWho 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)

author: BravoV
author_rank: Super Contributor
timestamp: April 03, 2014, 10:04:10 am
content: 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.QuoteThe EPI peripheral is part of the "System Modules" :

author: MarkL
author_rank: Unknown
timestamp: April 03, 2014, 02:04:21 pm
content: Quote from: abyrvalg on April 03, 2014, 07:53:11 amAfter 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.

author: MarkL
author_rank: Unknown
timestamp: April 03, 2014, 02:31:09 pm
content: Quote from: BravoV on April 03, 2014, 10:04:10 amThis is a nice chip (and a pretty big hammer for this problem). I've evaluated Stellaris chips but never used one in a design. I haven't been keeping up with them - thanks for pointing out the EPI.I looked through the EPI section on the data sheet and I don't see where they provide an edge clock input (aka slave mode). In what they call "Host-Bus Mode", they do provide a wait signal (RDYEN), but it's synchronized to the internal EPICLK and not to an incoming clock edge.I know you said you're just picking this up too, but if there's some other mode you have in mind, please let me know. (There's way too many MCUs out there! Aaaah!)

author: peter.mitchell
author_rank: Super Contributor
timestamp: April 03, 2014, 02:36:09 pm
content: http://www.parallaxsemiconductor.com/products/propellerchips

author: MarkL
author_rank: Unknown
timestamp: April 03, 2014, 03:00:48 pm
content: Quote from: peter.mitchell on April 03, 2014, 02:36:09 pmOk, a little bit of a learning curve on this one since I don't know Spin. And a solution doesn't pop out at me after perusing the Propeller data sheet and manual.But I'm game to listen... How would you use the cogs to capture 10 input bits in parallel on an external clock edge? If you've read the rest of this thread the timing constraints are pretty tight.

author: Jeroen3
author_rank: Super Contributor
timestamp: April 11, 2014, 08:53:09 pm
content: There is SGPIO in some higher-end NXP parts.

author: MarkL
author_rank: Unknown
timestamp: April 12, 2014, 02:57:16 pm
content: Ok - so the SGPIO on the LPC4300 series I think finally fits my application. I can configure a 10-bit input port using 10 SGPIO slices. And I get the FIFO as a bonus.Thanks, Jeroen!

author: David Hess
author_rank: Super Contributor
timestamp: April 13, 2014, 05:51:26 pm
content: If the data rate is not too high, then a pair of 74597 latched parallel to serial converters in the logic family of your choice can handle this sort of thing. At higher data rates, 8-bit latches with tristate outputs would be faster.

author: Jeroen3
author_rank: Super Contributor
timestamp: April 13, 2014, 06:49:26 pm
content: By default most 32 bit microcontrollers already have at least one 16 bit parallel input, some even 32 bit.Just route all lines to a single IO port block (eg A_0 to A_15), then use interval or triggered DMA to read the input registers to a circular buffer.Only when your datarate is reaching a burst speed of more then a factor of your MIPS rate you should be worried doing it "by software" like this.But using dedicated hardware is probably much easier and faster, and more flexible since it won't be a easy choice to surrender a full IO port bank to gpio. There might be other features sharing a pin.

author: lewis
author_rank: Frequent Contributor
timestamp: April 13, 2014, 06:50:32 pm
content: Does the display have all the data pins connected? These displays are very often used in 4-bit mode to save MCU I/O. You can then use a low end PIC with the 8-bit parallel slave port.If it's used in 8-bit mode, use the parallel slave port on the 8 data bits, the LCD's 'E' becomes the clock, and you can use any two other port pins for the R/W and RS pins. Why? because the datasheet specifies a min hold time for these two pins of Tpw = 230ns after the low to high transition of 'E'. Plenty of time for 'E' to trigger an edge-enabled interrupt in the PIC and for the interrupt routine to poll these pins.Come on dudes, all this talk of FPGAs and PSOCs is far too OTT for reading data being sent to an HD44780 display

author: Jeroen3
author_rank: Super Contributor
timestamp: April 14, 2014, 05:13:00 pm
content: HD44780 can easily be captured and sent over RS232 by software using an 8 MHz ATMEGA32 chip, the wait states of those LCDs are massive.However the goal seems to be an interface bridge. A hardware solution might be more fancy to focus more the following serial (wireless) interface