rusefi.com

So my 20x4 LCD Character Display + IIC/I2C/TWI/SPI Serial interface Board Module has arrived.

Now that it has arrived it's time to ask the question which I should have asked before: what part of it is SPI? There are only two signal wires and the line names - SDA and SCl - remind me of I2C, not SPI?! I want my Chip Select line

Anyway, I would appreciate any info - so far I cannot even find a datasheet for the chip on the interface module. It looks like the chip is called pcf85741. What is it?

IIC requires device addresses be sent whereas SPI requires chip select signals, so if the busses are shared, SPI devices will only respond if their chip select is set.
SPI devices so connected, I believe, must be able to receive a request (receive data) on the same line they respond (transmit data).
There are also some clocking and data signals that may have issues, as in the shared bus can only run as fast as IIC.

All the SPI implementations I have seen so far were three/four wires: clock, data in, data out, chip select (line enable)

Open question is what does SPI have to do with the bundle I've got...

check up this data sheet
http://www.alldatasheet.com/datasheet-pdf/pdf/37318/SAMSUNG/KS0066.html
give us close up photo! the seller's description is a bit messy...

puff wrote:give us close up photo!

Will take a picture tonight, but I think it says 'pcf85741' on the chip

With some googling I now suspect that it is pcf8574t - not pcf85741

This case it is just I²C-bus to parallel port expander, nothing to do with SPI? I wonder if that means I should open an eBay case

You could open a case about misrepresentation, and probably should anyhow. You may or may not prevail.
Thing is that I2C and SPI can 'technically' run on the same bus if a few conditions are met:
1) Clock speeds used are compatible with both.
2) Data transfer to / from the device can be handled with one signal wire.
3) Data sent to or from an SPI device doesn't inadvertently broadcast a valid I2C device ID: this would cause an I2C device to act on subsequent data on the bus.

This site gives some minimal details about sharing I2C and SPI on one bus.

You might be able to get away with a pair of transistors, one NPN and the other PNP, and a spare GPIO pin to select which "bus" is in effect at that moment. I.e. if GPIO is high, SCL/SCLK (or whatever) is connected to I2C devices and if it's low, SPI devices get the clock. Think of it like a "bus select" pin?

You might even be able to parallel it with the SPI chip select(s) to have it go to SPI devices if SPI is active:

Status update: got a refund for both my orders - one was "20x4 + SPI module", another one was just "SPI module".

Fine, for the grand total price of $0 for two modules and a free 20x2 LCD I would consider trying I2C

i'd like to see how you plan to utilize it. is it any better than a dedicated bluetooth tablet pc or jailbroken ipod?
btw, thinking of error logs, reports etc., i've got a question: will we be using a usual clock to count the real-life time? any fram modules to log some important data?

puff wrote:i'd like to see how you plan to utilize it. is it any better than a dedicated bluetooth tablet pc or jailbroken ipod?

I think it would be better for some people because it is bolted on the control unit and for instance it cannot loose connectity or power. it would be a lame display with high reliability

puff wrote: btw, thinking of error logs, reports etc., i've got a question: will we be using a usual clock to count the real-life time? any fram modules to log some important data?

Yes Real Time Clock should not be hard. Doubt any data is "important" - I think SD is just fine.

SD is not enough. you can't always log to the card, or can you? anyway, for me it seems too bothersome. Is SD reliable enough? What if I forget inserting the card?

As for display - just explain me how the user controls it? When we have a large screen we can put detailed info or even use several tabs (thanks to touchscreen). What about that module? Just four lines? What info will you display there?

Say we write 200 bytes 10 times a second, you do the math - how many seconds would be fit on say 2Gb? On 32Gb?

As for 20x4, I see the main purpose as displaying all the errors/warning in human-readable way. Anyway, let's not fanatical about any of these options - my approach is to try them all and see which one proves to be useful and which one not. These are all so easy to implement anyway

Turned out these have a 4-bit parallel mode, so just 6 GPIO wires total - that's not so bad. Easier to allocate 6 GPIO than I2C pins which are shared with other peripheral...

what would you put there in these 16x2 symbols? human-readible errors like what? "cyl 2 misfire"?

puff wrote:human-readible errors like what? "cyl 2 misfire"?

Yep, more or less so. Actually the plan for tonight would be to solder the wires to a 20x4 screen and to change the source code accordingly. Yesterday I've wasted an hour before I've realized this stupid screen needs a resistor on the Vo 'contrast' line.

from my point of view the major issue with these screens is the lack of standards (in terms of communications protocols, wiring etc). should you get another model, you'd need to alter the code, which puts the whole idea to the question.
what I believe a much better approach is to 'throw out' these errors (or even error codes, may be with timestamps) via uart, so that anyone would attach any (may be even diy) device and visualize this info to their liking… this seems to be much simpler than tinkering with various screens…

I disagree here. First of all, it seems like HD44780 is a pretty popular protocol with enough cheap units on eBay.

Secondly, it would be wrong to select one way of reporting data and call it the only way. We should have ALL the communications options we find useful. We have MIL light blinking and hi-level protocols already. You can help by figuring our how to display error message state in TunerStudio or by implementing the OBD-II protocol via CAN. We need to cover all options and HD44780 seems to be a good one - it's easy, cheap and it would be useful for some installations. While the others can simply not use it

I'm speaking not just about the protocol, but rather about the product as a whole. I doubt that if you replace the screen with another one (of a bigger size? or even of the same size but different implementation), it would work without editing the code ;-(
you'd even have to specify several sets of error messages since there are 8х1, 16x2, 20x2, 20x4 displays)
another fundamental question is how many error messages do you expect from the firmware?
I've just tried googling if TS displays error messages at all - it seems it doesn't have such functionality. I am no expert in OBDII or CAN, but as far as I know car manufacturers often have their own, specific (if not proprietary) OBDII error codes. I guess the same refers to CAN.

puff wrote:specific (if not proprietary) OBDII error codes. I guess the same refers to CAN.

OBDII has enough standard codes - we already use them, see obd_error_codes.h

Got 20x4 working

It's exactly the same pinout and exactly the same commands! I am starting to like HD44780 because the protocol is so easy I can even output the internal firmware panic error messages, which is HUGE while chasing a bug.

congratulations! at the end of the day, it was not a bad idea at all!

I've tried I2C today and I hitting a wall with it

There were some configuration issues - like DMA conflict between SPI and I2C, I've resolved that with changes to the system configs.

My port extender is supposed to use address 0x20, or at least some address in the 0x20-0x27 range - but it is not acknowledging my commends There was something about using external pull-up resistors - fine, I've added 5.6K pull-ups on both lines - still nothing. I am giving up

Here is a pic from the analyzer - at least there is something on the wires


Here's the troubleshooting guide: http://www.chibios.org/dokuwiki/doku.php?id=chibios:community:guides:i2c_trouble_shooting
And the code is at the bottom of hardware.c
I am getting err 4 which is I2CD_ACK_FAILURE

ha! it turns out I got the same 16x02 module long ago!
seems it should be working?
http://labkit.ru/userfiles/file/documentation/Indication/ACM1602K_rus.pdf

puff wrote:http://labkit.ru/userfiles/file/documentation/Indication/ACM1602K_rus.pdf

Should work - it's the same HD44780 controller

so what do I do to connect it? what's being displayed there right now? do I need to alter the firmware to make it work, or it's plug-n-play?

puff wrote:it's plug-n-play?

it's plug and play, let's ask @ to start a new thread with a howto on the pinout and wiring

I found an old vfd that I had sitting around. Its one of these:
http://www.newhavendisplay.com/specs/M0220SD-202SDAR1.pdf
Its currently jumpered for serial input. Can this work with rusefi? what would the pinout be for serial?
Or is it easier to jumper it for parallel?
Or is it easier to throw this one away and just get an lcd off ebay?

Only HD44780 as of today - so, no serial. See http://rusefi.com/forum/viewtopic.php?f=4&t=481

Have you looked at the new STM Discovery board with built in LCD? $33 is not as cheap as a $9 ebay module but you can do SO SO much more. 3D graphics and realtime graphing / gauges etc. It wouldn't be that hard to make the board an SPI slave also (easiest would be to accept commands over UART)

I would push user text messages out of the ECU over CAN and you can use anything you want to display them. Certain Nissan ecus pump out the most recent thrown OBD trouble code over the can bus without any diagnostic requests for example.

Unfortunately the new Discovery LCD board doesn't leave any CAN capable pins exposed. If you cut traces on the board to disable some USB OTG functionality you can get to usable CAN TX and RX pins.

Have not tried it yet - no time And the screen is so tiny The 20x4 does not have 3D, but the characters would be larger