Hey All

I ran across a few posts from way back talking about building an LCD interface for bin switching adapters. As far as I could find, nothing ever came of them, so I decided to pick up from there and build my own. Normally I'd wait until I had everything finished before posting about it, but I figured I'd open this project up to anyone with new ideas or a desire to work on it as well. I've still got a some hardware and software work to do, but it's mostly minor stuff at this point.

The LCD is a 16x2 line display with an HD44780 controller. I got it off ebay for about $7. The microcontroller I'm using is a PIC16F628A running at 4MHz. I'm thinking of possibly switching to one with analog/digital converters and more I/O pins to do other stuff like monitoring sensor inputs, or possibly tying into the ALDL stream. That's all way down the road though.

I haven't got schematics drawn yet, as the circuit isn't really that complicated. I'll draw some up and post them when it's time to etch the circuit boards though. I wrote the software in assembly, and if there's any other PIC programmers here on the board I'd be happy to share it. I don't think I'd have the means or the will to market this, so everything's open source.

I haven't seen the moates bin switching adapter, but I imagine interfacing to it should be rather trivial. The EEPROM memory in the PIC itself is 128 bytes, so it could only store enough text for 8, 16 character user-inputted strings. I know the moates adapter can switch up to 16 bins, so this is an issue that would have to be worked out.

Anyways, here's some pics, let me know what you think.

-Bryan

 

Looks good, I like the idea. Little on the big side for my interior setup but would be nice in any case. I can never remember more than 3 of the stacked bins I have. With displayed names it would be easier.
One thing I thought of is that the displayed name of the bin is probably held in the display memory an called by position number. That is the easiest way to do that. This would be great if the ascii could be pulled from a location on the ALDL or bin file as a variable in the display. That way when you edit the bin, the name will follow it. Wouldn't need to assign a numbered lookup table for the name you want to associate with the selected bin position. BTDT with industrial systems w PLCs and display panels.
It can get to be a pain as you make mods to chips and change the order you stack them in.
Not sure if that is possible on your setup. Just thought I'd throw that out there.
Keep up with it and post your progress.

 

Putting an ASCII string for each bin onto the actual ECM PROM and reading out from there would definately be nice. All I'm doing at this point is tying into the upper address bits of the PROM to switch between 32Kb chunks of address space. Perhaps the ALDL route could work. I haven't looked into the actual $8D disassembly at all though, so I don't know how hard such a thing would be to implement. Would be really nice though, just enter in a title for each bin in tunerpro and burn.

The LCD itself is pretty small, the viewing area is about 2.5" x 0.6". I was originally going to cut a window in my cowl blockoff plate to put it in, but decided to put it in the heater vent instead. I used 0.10" aluminum plate and lexan for the window.

 

Good stuff! Mark and I had kicked around a 4x20 ALDL data display & storage unit for a while, just haven't gotten around to finishing really. But we got the 44780 stuff working pretty smoothly in the process.

Myself, I do most of my micro coding on the Atmel AVR stuff in assembly. Same principles apply though. I just finished up a couple variations of the 'EX' simple single-digit remote switcher, making it a little 'smarter' and working off a micro for debounce and a few other goodies. But nothing on the bench for display strings which correspond to binary selections.

You planning on having a PC-based configuration utility to set everything up and then upload it to the device via USB/serial? That'd be slick.

If you need a hand, just let me know. I'll be glad to share the pinout of the switching adapter stuff to get you going and help however I can.

 

I had one of these mostly finished and functional on a breadboard about a year ago, but I had to move and ended up taking it apart and loosing the code. Been way too busy to work on it since then. Mine used a 2x20 but was essentially the same as what you have there. The reversed 2x16 looks nice at night, wish they were as easy to find as the standard type (dark characters on a lit background).

My design used an AVR rather than a PIC and the last thing I was working on was deciding the bast way to have the uC remember the last bin selection. I was hesitant to write it to the EEPROM since it someday down the road fail due to being written too many times (It still takes thousands of rewrites I think). I also toyed with the idea of a battery backup keeping the uC in low power mode while the ignition is off, as well as runing off direct battery power like the clock in your radio. Have you given this much thought?

I do seriously suggest that you finish the version you are currently working on before trying to add complex features like reading the bin itself to display a bin name. Feature creep could easily delay or kill something like this.

Anyhow, it looks good.

 

Looks like the AVR's are dominating around here. I'll probably go that route eventually due to the free C compilers available for those microcontrollers. For now it's PICs and assembly though.

Punisher, I am using the EEPROM to store user data. That includes bank names, last bank selection, and display brightness. Microchip lists the 628A's EEPROM endurance at 1,000,000 writes, so even if I'm switching banks 250 times a day it should be fine for well over 10 years. I'm currently not verifying writes to the EEPROM though, I think I should probably implement that as a safeguard just in case.

I etched and populated a board last night, then realized today I had the IDS connector laid out the wrong way I think I'll wait awhile before making a new one, I'm kind of getting ahead of myself building boards before the program's even finished.

The code's in a semi-useable state right now. Most of the menus are working; most importantly the bank select menu. There's still a few small quirks to iron out, and I haven't yet figured out how I'm going to let the user actually change the bank names. It's easy enough for me to simply reprogram the PIC whenever I change the PROM, but there needs to be an easier way to do it. I'll probably start with a simple character-by-character selection menu, but I like Craig's idea of updating the user data serially. The 628A has a UART that would make such a thing straightforward from the microcontroller side, however my experience with C/C++ and PC programming boils down to a few hello world programs, so that'll probably have to wait until I'm finished with everything else.

Thanks for the good ideas guys, external input helps a lot. I'll be sure to post more as the project progresses.

 

Once you're to a place where you're ready for it, I'll write a simple interface Windows application for the device. Again when you're ready, send me the details on the serial requirements (baud, commands, etc).

M
mmansur at hotmail

 

Bryan, I guess I didnt really think it through on just how long it would take to re-write the eeprom to the point of failure.

I started programming with PIC's doing my own NB AFR meters on 2x20 lcd's. I quickly switched to AVR's though when I discovered you generally get more speed and features for your dollar. If you havent been there yet go to avrfreaks.com

 

Mangus, thanks for the offer. I might take you up on that sometime. Last night I coded up a simple editing menu to let the user program the bank names manually. It's a little awkward scrolling through so many characters with three buttons, but still tons better than having to reprogram the whole microcontroller. Also, the currently active bank is also now shown on startup, and I hardcoded a button sequence password that must be entered before moving on to the main menu. I'm still not totally happy with the current user interface layout and operation.. I think I'll have to drive around with it for awhile to figure out exactly how I want it all to work.

I know it's kind of hard to discuss something like a user interface without some kind of visual element. Maybe later I'll post a video of the system actually operating so everyone can see how everything is actually set up.

-Bryan

 

If you want a way for the user to easily input characters without having to hook up to a computer you could just add an "AT" keyboard interface. Very simple to do, only costs you a couple of pins and you can find dozens of schematics and code examples. It is also very easy to interface a 3x3 or 3x4 keypad. You could have the keypad detached and just plug it in for programing.
Many people have extra "AT" keyboards laying around, probably alot more people than than those who own laptops. And even if the user didnt have an extra keyboard they can be purchased for under 10 bucks.

 

I figure that anyone who's tuning their ECM almost certainly has a laptop for datalogging, or at the very least a has computer at home for bin editing, so I think the serial interface would be fine for uploading batches of new bank names. If you just want to edit one or two bank names while you're, say, sitting at a stop light, I think the three-button interface will probably be adequate, especially if I spend a little more time improving it. A keyboard interface is probably a little overkill, as I'm currently running out of I/O pins as it is. I'd like to have a few that I could assign to be asserted when certain banks are selected. Of course, the address select lines could be tied into a 3to8 or 4to16 decoder to accomplish the same task, but I think software-programmable outputs would be nice. Like say to arm nitrous solenoids only when one bank is selected, or to disable the ignition circuit when a "No Start" bank is selected, etc. I'll probably just bring out all the unused pins to a header on the circuit board, and design an "expansion" board later on when I get the time to work on all the extra stuff.

I took a video of the basic layout of the interface as it stands today, as I've said before it still isn't ironed out completely, so any input would be great.

BankSelect v0.20

 

Wow, very nice! Can't wait to see this available to everyone.

A suggestion: since I too use a "no start" switch position, and since this device makes it clear to a potential thief how to "fix" this, how 'bout a button combo "password" to change bins? Thsi would also be valuable for valet mode.

 

Yeah, I'm still trying to figure out exactly where to ask for the password. Currently, the system requires a password every time it's powered up and when you put it in "lock" mode. I figured that once a user entered in the passcode, all functions would be enabled so that bins could be switched quickly on the road/track/etc without having to go through a long key sequence every time. However, when not locked, it would also be somewhat easy for a few buttons to get bumped and a new bin selected, which could definately be a bad thing. Perhaps I could create a boolean variable the user asserts that enables or disables a password prompt for each bank selection.

The words "No Start" do kinda tip one off as to what mode the ECM is in. I guess it could be looked at both ways: as a deterrent in the same way that most car alarms advertise themselves with a little blinking light, or as a challenge to the thief to try harder. I think a screen blanking option would work in this case.

Thanks for the good suggestion,
Bryan

 

I almost forgot. Craig, if you would be willing to give me pinout/interfacing information for the bank switching adapter, that'd be great. I could go with the 10-pin connectors you're using so this would be interchangable with the rotary dip switch.

Address is noble 95
at cinci dt rr dt com.

Also, this system currently only supports 8 banks. The PIC only has 128 bytes of storage space for user-defined bank names, so 8 was as high as I could go. However, I'm still designing everything around 4 address bits, so moving up to 16 banks would only require some more routines to be written to handle hexidecimal to decimal conversions (ie. Banks 1-16 instead of 0-F), and a few additional tweaks here and there. 8 of the 16 would have to have permanently stored names though, such as Bank 9, Bank 10, etc. For now though, the firmware only supports 8 banks.

 

Update: I can switch banks! Software's still changing and I've still got a breadboard and ratsnest of wires in the passenger seat, but I did manage to interface with a 2 megabit chip tonight and switch through 8 banks via the LCD interface. I built a little adapter so I could plug the PROM into my ZIF socket, and everything seems to work great.

I'm trying to finalize the hardware design at this time so I can get the main board built. My main area of uncertainty is actually driving the address lines. I'm tying the ground on my breadboard directly to the ECM ground, and driving the address lines directly from the PIC (i.e using the 5V supply from the PIC, not from the ECM). I put conditioning capacitors on the lines to keep any noise down, and right now they're tied to the PIC output pins through 1k resistors. Since the PIC I/O lines don't sink current when it's off (I think), I'm thinking of using 100k pulldown resistors on the address lines to keep them low (i.e. revert to bank 1) if the PIC ever loses power. I'm not sure if 100k is too much resistance to be effective, but I'd like to keep the voltage drop across the address lines as low as possible. If anyone has any suggestions concerning this it would be much appreciated.

Once the hardware's done, I'll release schematics. I'm still pretty much a newbie at this, so I can't guarantee they'll be optimal. That's why I ask for input. I've got some work to do on cleaning up the code for release, as I'd like to comment it thoroughly so people will be able to see a method to my madness. As soon as that's done, though, I'll relase a firmware v1.0 with source and hex files.

I was browsing through Microchip's site last night and came across the PIC16F88. It's pin-for-pin compatable with the chip I'm currently using (16F628A), but has twice the program and EEPROM memory as the 628A. Once *everything else* is finished, I'll devote some time to porting the code over to that chip. That would allow for 16 custom bank names to be stored, as opposed to the current limit of 8. Ah, hindsight's always 20-20.. Fortunately, due to the pin-for-pin compatability, it should simply be a drop in replacement for the 628A.

-Bryan

 

cool!
Sounds like you are making headway.
Don't get too hung up on the names thing, people will deal with whatever you come up with.
You could try a "two press" to switch bins (with a release between bumps) to ensure a change was indicated. That way holding the button down will not cycle the bins either.
Also the "no start" can still be bypassed if the conditions are just implemented in code. Hardware can still take over.
Just some more thoughts.
Ed: I thought I saw the switching pin setup somewhere in Craig's docs.

 

I recall someone (JP?) using bin 0 as the no start and just unplugging the switch. That would mess up the chip failure default thing your were working on though I suppose.

Now for feature creep...this for TPI's would be great. http://www.fullthrottlespeed.com/items~Cc~SCAN~iTpStatus~0~Tp~~Bc~.htm

 

Yep, I use a 10-pin IDC header. Here's the pinout:
The Moates.Net Web Site
On some stuff, I've used the extra pins for the ISP (hint!).

 

Craig, thanks for the pinout.

I noticed in the notes you said the address lines are floating high. Are you essentially treating them as low-assert and programming the banks backwards? I noticed the tunerpro bin stacker application wrote the "last" bank starting at 0 hex, so I guess this is why. Just seems like kind of a strange way to do it to me. No big deal though, I'll just add some transistors to sink the address lines with.

Do you have an idea how much current can safely be drawn from the ECM's EPROM supply line? If I could draw my power from there instead, that would eliminate the need for the 12V source and voltage regulator I'm currently using.

 

Might have been some old documentation there. I usually pull them high locally via 1k or 10k and then pull them down remotely via switch to ground. The fundamental reasoning for this originally was so that 5v wouldn't need to be carried out remotely to pull the lines high upon switching, and that you could switch low to any ground.

In terms of current draw, that's kinda hard to say. I'd try and stay under 100mA though. You probably have some draw from the LCD backlight, but that's about it.

In terms of transistors and such, there's probably no need. I assume you have enough I/O on your micro, right? Just pull the lines low directly, and you should be OK I think. I'm doing it on another similar application, and no problems. Powering off the VCC of the ECU, too. Only 30-40mA max on that one.

 

I haven't measured the current consumption of the backlight yet, but at full brightness it might very well be over 100mA. The PIC I/O pins sink AND source current, so with a separate power supply I didn't want VCC1 and VCC2 to become connected in that manner. If I'm able to use the ECM's 5V rail though, that won't be a problem.

 

What I'll do a lot of times is run the pins as an input for a 'high' and pull them high externally, tristating them at the micro itself. Then when you want to pull low, exert the micro pin as an output with 0. This is also useful for level shifting, if you've got a 3.3v circuit and a 5v micro. Not so useful the other way around though.

 

Ok, I've moved past the breadboarding stage. I managed to squeeze the entire controller onto a 2"x1.3" PCB. I couldn't really go any smaller with a homemade board. It has a 3 pin header for a contrast pot, 16-pin header to connect to the LCD and 3 buttons, and a 10 pin header which (should be able to) connect directly to the Moates G3 adapter. I'm drawing power through the 10 pin connector directly from the ECM, and I added a 100 ohm resistor to limit the LED backlight current to about 50mA, which hasn't affected brightness that much. This is REALLY nice, cause now there's no need to hassle around with tapping into external power sources; put everything in a box and it should plug in just like the EX. (I like mine in the dash though)

Of course, I haven't forgot about all the "extras" such as RS232, 16-bank support, in-circut programming, etc. But I want a fully functional system and solid code written before I start on that.

Here's some pics, please excuse my dirty carpet.

 

Here's the current pinout and schematic of the BankSelect board. The LCD header follows the standard pinout of most HD44780-type LCD modules, with the exception of pins 7-10, which I have used for the three selection buttons (the LCD is operating in 4-bit mode and doesn't use lines 7-10). This schematic will likely change as features are added, but I figured I'd throw it out there for scrutiny. Code will follow when I've cleaned it up a bit.

 

Ok guys, here you go. Source code and a precompiled hex file for BankSelect v0.30. I released the code under the GNU General Public License, as I'd like to see it stay public.

This is the code I'm currently running in my car. Anyone with the means is welcome to build their own bank switcher system from this, just remember that no warranty comes with it.. use at your own risk.

 

This looks awesome! Am I right in thinking that this can be used with the PROMinator to switch between programs?

 

Just because there arent a hoarde of responses doesnt mean we arent keeping track! Keep up the good work and keep us updated.

 

Ought to work with the Prominator, yes.

 

I'm still working on this. Been running the v0.30 code in the car successfully for the last two weeks, and everything's working fine. No Start mode is very effective, especially in the mornings when I forget I've got it selected. I'm in the process of porting the code over to the PIC16F88 processor so I can move up to 16 banks.

-Bryan

 

I can see myself making one of these once I get my new engine installed.

If you had some provision for a numeric keypad to unlock/lock the system when you wanted that would be the ultimate extension.

 

It does have an unlock sequence, though currently it's hardcoded and not customizable. There's a link a few posts up with a video, where you can see I have to enter in a specific key sequence when the system initially starts up, and later on to unlock it after I choose the "Lock" option.

 

I did watch that video and wondered why I saw your fingers dancing around without much happening on the display. I guess you were entering the code in then.

So many gadgets to build, so little time...

 

Amen to that
24 hour days are way overrated.

 

Still working on this, just not so much as work and play are keeping me busy, and, well, the current version has been working perfectly so far, so I haven't had a necessity to do any code/hardware changes. I've got some ported code running on the F88 processor now, but I need to sit down and work out some problems in the routines used to write to the PIC's EEPROM bank. Shouldn't be too difficult, just need to find some more time to sift through all the code.

I'm currently en route to depart from my dearly beloved TPI for an LQ4/LS1 swap if I can find some deals that'll fit into my budget. Will probably be a while before that ever happens though, but I'm gonna miss the simplicity being able to flip EPROM bits instead of reflashing/reburning every time I want to switch modes; fun stuff

 

Cheers for the update

 

Cast your vote now for the 36 hour day upgrade of the earth.

 

that's awesome dude, i'd love to get into something like that just dont' know where to start

 

So, it's nearing 6 months now and the BankSelect system is still working great. There haven't been firmware updates because it "just works." It's been plenty easy to use and I just haven't had a good reason to change anything.

I did port the code over to a PIC16F88 microcontroller and added support for 16 banks. The only hardware change is the controller itself. Swap out the 16F628A for the 16F88, program with this new firmware, and you'll have 16 bank support. This is the code I'm currently running, though I still only use 8 banks.. that's been more than enough really.

 

gosh i would pay you to do something like that for me.