View unanswered posts | View active topics It is currently Tue Oct 17, 2017 4:59 am



Reply to topic  [ 13 posts ]  Go to page 1, 2  Next
Expansion board ideas 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14820
Location: Home sweet home!
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!


Sat Feb 09, 2008 2:07 pm
Profile WWW
LQFP112 - Up with the play
User avatar

Joined: Tue Jan 15, 2008 5:14 pm
Posts: 215
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.


Mon Feb 11, 2008 10:19 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14820
Location: Home sweet home!
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!


Tue Feb 12, 2008 12:51 pm
Profile WWW
LQFP112 - Up with the play
User avatar

Joined: Tue Jan 15, 2008 5:14 pm
Posts: 215
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.


Tue Feb 12, 2008 10:39 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14820
Location: Home sweet home!
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!


Tue Feb 12, 2008 10:52 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14820
Location: Home sweet home!
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!


Tue Mar 18, 2008 12:24 pm
Profile WWW
Post Whore!
User avatar

Joined: Sat Feb 16, 2008 12:11 am
Posts: 629
Location: Sunny San Diego
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. :-)


Mon Mar 31, 2008 7:44 pm
Profile ICQ YIM
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14820
Location: Home sweet home!
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!


Mon Mar 31, 2008 8:08 pm
Profile WWW
TO92 - Vaguely active

Joined: Tue Apr 01, 2008 3:48 pm
Posts: 3
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.


Tue Apr 01, 2008 4:20 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14820
Location: Home sweet home!
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!


Tue Apr 01, 2008 4:36 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 13 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: Bing [Bot] and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.