VEMS Home Products Documentation Wiki Webstore
WikiHome ProjectPage DocsPage UnderDevelopment MembersPage SiteIndex RecentChanges Preferences
VemsFrontier/Boards (2005-04-22 12:57:09)

ARM based projects

The idea behind is that different ARM boards should share parts of hardware/software, (and AVR boards too) which would make development more efficient and would ease communication between boards. A common development will also allow us to share development costs.

TODO: find a good way for networking the AVR (mega88) boards

Manufactured as a break-off of a bigger board

With the help of newly created VemsExecutives/CaseDesign the 120x40x2.5 profile (a case that can hold 2 big boards with userfriendly assembly/disassembly) had been approved for some boards. The Round CNC-ing is also prepared.

VemsFrontier/ARM boards:

High prio

Maybe delayed to 2005-05 - but wouldn't hurt to roll a bunch

Maybe postponed - but some proto would be nice

POSTPONED: - indefinitely

Forget thruhole

I write this here because it affects several boards.

Please go with SMD as far as possible. Maybe this should go to DesignGuidelines page.

Thruhole is

Copyrights

The following discussion should be placed elsewhere.

It seems this should be discussed:

I suggest we make software GPL-ed after 0..3 years (depending on type).

I think there is no point in making HW public (at least for 5..10 years). It would benefit only for commercial organizations to steal and sell it without donating anything to development. It wouldn't benefit to a student who wants to manufacture 3..4 boards for himself, as that's extremely high cost in low quantity; much higher than when made in 100+ quantity.

Also, there is huge amount of work from some people already put into v3.x (WBO2, firmware, HW). Swapping a processor shouldn't take away their IP.

Also, making HW open would make it hard to finance developers. If it worths to manufacture, either the developers or a commercial player would make some profit from it. I vote the developers do. For the end-users it's little difference. End-users are happy to donate 150 Euro to developers who developed a 800 Euro system that is otherwise only sold for 5000 Euro.

Also, making HW public would make manufacturing harder. Who would invest 10000 Euro into the manufacturing (2000 Euro had to be spent on the initial Econoseal stock alone !) if it's possible that someone start to sell the same board the next week, maybe for a few pennies cheaper. Waiting for the orders to gather (to be sure) would be slow. The developers would need to wait longer for their own boards, and would have to pay for it!

The big difference between software and hardware is that one student or small enterprise can possibly start to use the software (running on PC or other computers) at once, while hardware is only useful if it's manufactured, and manufacturing only makes sense in 100+ quantities (one could argue 1000+).

But we clearly need to refine CompenSation/Distribution and track efforts and results so anyone who contibutes work should take their share.

Alexei - I'm really surprised by your reaction ! How can you expect to protect the design if you give on this site schematics and software sources ??? When I've been copying these files I have not seen any license (maybe I should ? yes), or registration form. Or do you expect all Internet users are honest ?

When I buy a Motec ECU I can not copy it, it's just a yellow box and a poorly designed PC exe file.

Note that copyright has nothing to do with how easy it is to copy a design. If you didn't find a copyright, that means you are not allowed to copy (check the law, it is very clear): it is actually the case for HW, but you should look more carefully for software, eg. top of wbo2.c and GenBoard/PublicLicense

We definitely intend to get students learn from the design, and play with it, and contribute. But we want m0tec to pay to our developers if they think it is cheaper to develop from this than from scratch.

--

So we have to clearly define the license. (as it's always been).

So you suggest to not disclosure the HW ? As I said, the license

has nothing to do with the HW disclosed or not. I think it's good to have some control over HW visibility, but we definitely make it very easy for our developers, students and installers to get the schematics.

Could I have schematics of one board if I joined another project ? yes. Even if project mapping is mainly done on functional mapping level.

The next question is the usage the developers could make of the board. I would like to sell engine solutions with the EFI included inside. Could I do that ? yes, of course, why not? The reason for the design is so it is manufactured (in a controlled way), used, learnt, improved etc... It's very clearly stated even today. You just need to

Could I make my proper printed circuits with different board connectors ? yes. You can also have the profit from installing it to a large number of vehicles. But - even if you are a core developer - you are asked to contribute from the profit of the EFI sales to the other developers (it is marginal compared to the full project, a few 100 Euro per computer. Very good deal, given that you had much less chance to realize those sales without their work).

Yes, there are decisions. The decision is that profit is distributed between contributors. Naturally, exact contribution factors (credit for architecture, firmware lines, testing etc..) only becomes urgent when sales are boosted. With v3.2 (besides the free HW as always) max 40 Euro per board (unfortunately even that can be delayed so the warehouses and manufacturing can prepare for the upcoming sales boost) can be distributed among developers (100*40 Euro = 4000 Euro) so that's not much difference if one has 10 or 13% in it.

However when we have the proper doc and tuningsoftware, with 5000 boards and 200 Euro distributed per board it makes more difference. But in any case, it's clearly a benefit for the developers to have some control over the HW manufacturing.

Please, make a clear distinction between disclosure and licence aspects. The fact that anyone can see the schematic does not mean that a third party is allowed to steal the design and manufacture 60000 units without any compensation to developers.

"Please, make a clear distinction between disclosure and licence aspects." I do. I just try to point out that if schematics are available, someone planning to sell 60000 units won't even read your license, he will just make a good package to prevent you from discovering it. Especially if he's able to produce 60000 units. Don't think people like Bosch could be interested by our design, they are far far away and just can not use this kind of designs for alot of reasons.

Could you replace this discussion with conclusions and a license definition, please.

The CPU choice

[The old wiki BrainStorming page] contains initial discussions about the MCU choice.

It appeared that ARM cores were often prefered. Currently only ARM7 chips are publicly available, while most of new industrial projects target ARM9/10/11 based chips. ARM cores are assumed to be backward compatible. Even if that's not always true, the big force of ARM is an homogeneous peripheral offer and the same development platform whatever is the chip maker.

VemsFrontier/ARM is the page about different ARM chips

GenBoard/VerFour : another ARM related page (should not be used as the v4 name is confusing)

Currently identified projects (planned or started)

Is really two boards, one with the smarts and the sensitive electronics and onewith the CDI and HV supplies. They are always used together and are installedin the same box.
Top page of IonSense.
The intention is to make an EFI board that is simpler and smaller then the V3, it's meant to do simple ignition and rely on ION/CDI to do (very) advanced ignition.
The intention is to make an external I/O board that hosts a number of high-end functions that does not fit on the other boards. It can also be used to collect all sensor information for the other modules and pass in on as a CAN data stream.

The above three projects is what we call the VEMS frontier project. The V3 is awesome, it's impossible to improve much on it without using a huge board. Instead we build several boards and to make it scale well we build them to work like modules. All three boards must be used to get all functionallity of the v3, but ArmEfi will be able to do most of the stuff V3 does. Engine board will have most of the 'extras' we are used with from v3. Ion will take the ignition to an other level.

Full feature EFI with injection, ignition, idle, NB/WB lambda, knock, turbo management and general purpose inputs/outputs. A simplified version could appear later (i.e. for motorbikes). Note, this is not a VEMS Frontier board!!! -Jörgen
Goal is to define a solution specialized to the challenge to make Internal combustion Motors run with minimal amounts of Combustibles based on GoBox/HydroCarbons.

New project suggestions

Useful pages

Under construction ...

The contents bellow will likely move to the EFI project related pages. Please don't modify for the moment, unless you find a proper name for the new project, or the proper place in started projects

Actually, with a new MCU it makes sense to design the most complex system first. That would mean a GenBoard/VerThree -like board. At a very minimum, the processor-pin mappings need to be assigned (continue ArmProcessorSubsitution ), so the firmware development will not tangle. Remember, we don't use an operating system that hides/abstracts HW from software, so mixing/swapping the IO-pin usage between boards is possible, but not recommended.

I/O chip: Looks like it won't be used.

To simplify scaling most of the boards use our new standard IO chip to control most outputs. The IO chip is an extension of the '259 multiplexers we use on V3. Currently it looks like an Atmel Mega8 will be used.

The I/O chip in together with the new DPAK switches make it easy to implement the controlled flyback used on Genboard v2.2. The more full featured v3 made it impossible to fit 8 controlled flybacks. The IO chip can also be used to collect analog data using its 8 A/D converters. (Our main ADC is still the Microchip MCP3208.)

The IO chip will have a standard program that is common for all boards utilizing it. It will receive configuration information from the main processor (over SPI?) on start-up. This includes information about high or low impedance injectors and peak hold times.

After this the main processor will only have to signal the IO chip to open and close the injector. The IO chip will take care of the rest. The same goes for ignition; the IO chip will keep track of when to start charging the coil and will only have to be signalled to release the spark by the main processor. Will an extended LBUS be used for the time critical signals? Or will we send what we want it to do over SPI and then just send an activate signal?