Expansion board ideas

From DIY contraptions to sophisticated FreeEMS-specific designs! Plus general hardware development!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Expansion board ideas

Post by Fred »

Hi, I'd like to propose some ideas for future further layers to sit below the soon to be existing two main boards and get your suggestions on other ideas.

Firstly a multiplexed digital output board. There are many chips like this one that take a serial signal and turn it into a parallel one. This is ideal for non time critical stuff such as shift lights, fuel pumps, etc. If the this part is used instead then that I/O expander can do PWM duty too! This would be extremely handy for many applications.

This paper describes how to do data acquisition using an 68HC912 which is very similar to what we are using from the inside. The chips mentioned can do ADC duties (which we are short of for serious data logging duties) and DAC duties (which we don't have on board at all).

Using some of these chips carefully would increase the amount of pins available to us under our direct control (without another MCU involved).

So in summary, we can have (at least) more PWM, ADC, DAC, and digital IO pins on board using these methods. This would be ideal for addition as an extra third layer of board.

Thoughts on this? Other ideas for expansion boards in the same or other form factors?

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
ababkin
LQFP112 - Up with the play
Posts: 215
Joined: Tue Jan 15, 2008 5:14 pm

Re: Expansion board ideas

Post by ababkin »

Here are some of my expansion ideas:

First off, i am the proponent of having all the extra (non time- and safety-critical) stuff to be on a separate CPU/MCU, to offload all the extra number crunching off the main CPU as well as remove the risk factor of the extra non-critical code somehow undermining the safety of the critical code. This is of course a luxury at this point (having 2 CPUs, PCB's etc), but should be considered for the final "bullet-proof" solution nevertheless.

It would be very nice to have a "human" and datalogging interface integrated with freeEMS, as opposed to having to lug around a laptop all the time.

By this interface i mean:

a. A character or graphical screen of some sorts
b. A manipulator interface of some sorts
c. A physical removable storage solution of some sorts

I have made an effort to achieve those in the past for the MS using a PDA (never really completed it), see this thread for more detail:
http://msefi.com/viewtopic.php?t=25169

It makes a lot of sense to have these a,b,c items implemented on a separate CPU/MCU and not on the main one.

Allow me to expand on each item:

a. I would propose a character VFD display. Here are some examples (no affiliation): http://www.matrixorbital.com/index.php? ... fc6f867ed6

The undisputed benefits of VFD are:
- extreme brightness levels, which enables the user to read the displayed info from the cockpit even on a bright sunny day (unlike LCD types)
- very high resilience to shock, vibration and very wide operating temperature range (again unlike LCDs)
- reasonably priced (under $100)
Also a variety of colorful LEDs can be used along with the character screen, to have different levels of warnings, etc

b. A keypad of some kind can be used to manipulate the interface state by the human operator. This can be implemented as a simple hierarchical-menu-style interface (kind of like what TVs and DVD players have) and is useful to turn on and off the datalogging, set-up warnings/alarms, etc.
Another random example: http://www.matrixorbital.com/product_in ... ay-inserts

c. Removable media for datalogging - pretty self explanatory: drive around, remove the media, stick it in the home PC, analyse the data and change the tunes. I'd suggest some sort of SD or CF card hardware device for this.
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Expansion board ideas

Post by Fred »

Hi,

I think A and B should be together and should communicate with the EMS through the same interface (thats what interfaces are there for after all) as the PC tuning software.

I totally agree with C however I feel that the best idea is a USB connector and flash storage interface chip. Why? Because you could put a 2.5" HDD in there and leave it on. Also, it would then be dead simple to pull it out and have a look at whats on there in a pc wherever you went. Whereas with an SD or CF car (much as I like them) not every PC has the capability to read them.

Still, You are right to suggest that it should all go on another board. All of the raw UART and SPIO connections come out through our 100 pin headers, so to populate a lower (or upper or in the middle) board with a bunch of neat stuff such as what I posted in the hardware wishlist thread is a good idea.

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
ababkin
LQFP112 - Up with the play
Posts: 215
Joined: Tue Jan 15, 2008 5:14 pm

Re: Expansion board ideas

Post by ababkin »

I wanted to keep A and B logically separate in this context. The implementation can combine things which ever way is convenient.
I can think of a way of mounting the B not at the A location, but at location most convenient for hand-manipulation (somewhere beside the shifter or steering wheel), so this is a matter of taste really.

I wouldn't use movable parts for datalogging, thus my solid state media preference. CF/SD cards + USB card readers are cheap and plentiful these days.
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Expansion board ideas

Post by Fred »

ababkin wrote:I wouldn't use movable parts for datalogging, thus my solid state media preference. CF/SD cards + USB card readers are cheap and plentiful these days.
Both have physical contacts in them which are prone to dust vibration etc. I don't see the difference except that the DOS on a chip chips are much more convenient to code to and provide heaps more flexibility storage wise. In fact, you could just mount the USB reader in a hard way such that the interface was through DOS on a chip too.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Expansion board ideas

Post by Fred »

http://www.sunspotworld.com/docs/Purple ... T7411.html

Ran across that while looking for something else, thought it might become useful as an example later.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: Expansion board ideas

Post by AbeFM »

I'm a fan of USB drives, but I have to admit, it's nearly impossible to find a computer that can't read SD cards. They are not my favorite, but they are everywhere. And many laptops come with readers built in. My phone uses those micro cards, and I just got a USB adapater for $5.

The nice part about any of this is 1MB is all the storage you'd ever need. Personally, I'd like to see CF slots, you can get hard drives for them and I have a bunch around, but... Really just a USB flash drive is the way to go. Small enough - and easy to put code on there so the computer can self update. I don't like pulling my laptop out - I want to just put the new firmware file on a drive, and the box should see it and update itself. :-)
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Expansion board ideas

Post by Fred »

That is an interesting idea if we access it directly. Hmmm, anything is possible. Talk to me about it again in 9 months ;-) lol
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
fastmonkeywheels
TO92 - Vaguely active
Posts: 3
Joined: Tue Apr 01, 2008 3:48 pm

Re: Expansion board ideas

Post by fastmonkeywheels »

I have SD-FAT code written for an ST processor. The only thing that needs porting is the SD interface. Interfacing to an SD card is much easier and less firmware intensive than USB host code. Also, my code actually used the MMC protocol over SPI, therefor no SD licensing issues.

I realize this isn't a primary task, just posting that I have written/tested firmware that might be a solution. It's also my first post, so hi.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Expansion board ideas

Post by Fred »

Awesome, great to have you along :-) I'm sure we can make use of it at some stage!

What is the bandwidth of doing it the MMC way? It's been a while since I read up on this...

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply