Puma board for FreeEMS

[Fred]

Marcos, I've just been looking over this ms v3 board and thinking and I was wondering what you've done for the RPM inputs?

ms has one bufferred digital input and one analog vr input. frequently what is required is two of one or two of the other, though. Do you have two VR inputs and two parallel bufferred digital inputs? If not, what do you have for this pair of inputs?

Fred.

[jharvey]

I'm not sure why I didn't think of this before, but perhaps we should have a heart beat LED. I'll claim I didn't think of it before, because it should be included with the TA card and I was focused on the interface board. I think that's a good story... Just an LED perhaps two that are driven by the MCU such that a blinking LED indicates the MCU is powered and processing code. A second LED could offer enhanced diag information, with out tools. I would say one really should be there, and two might be nice.

About the silk screen, I've had success in shrinking the text such that it fits between the pads. Also the default text thickness varies from component to component. I've had success with a text size x,y of .025 with a thickness of .005. I often can get the text to fit in-between the pads. I would also say the vendor can probably go smaller if required, but would recommend this as the smallest because it's getting a bit hard to read.

[Fred]

I'm dead against any pins being assigned purely to LED use. That is one of my hates about MS. However, I'm very much for putting LEDs on everything and anything else. Fuel pump, injectors, coils, rpm inputs are the obvious ones.

As for TA stuff, TA stuff has a PWM channel attached to an LED. Old code variants did flash this. New ones do also, but by xgate, and only temporarily. It's not hard to add code to flick an output, or configure a programmable output eventually to check that it's alive.

Fred.

[nitrousnrg]

git checkout master
git merge FreeEMS_1.0hardware_AR
It should say "fast forward" and a bunch of stuff should spew down the screen.

Cool, it did exactly that. Apparently nothing has been messed up, so I'll push up something later.

Do you have two VR inputs and two parallel bufferred digital inputs? If not, what do you have for this pair of inputs?

jbelanger said that a max9926 can handle both VR and digital signals for rpm measurement. I have two max9924 which are almost the same thing in a different package.

perhaps we should have a heart beat LED

Right now we have 9 leds. add the 8 injector driver leds I've just realized that aren't in the schematic.
There would be
4 ignition leds
2 GP power outputs w/led
1 fuel pump led
8 injector leds
1 TX (from the FTDI)
1 RX (from the FTDI)
I'm not sure if I want so many things flashing around, but the led would be easy to put in an empty zone.
The 5v switchable regulator could have one too.

I've had success in shrinking the text such that it fits between the pads.

Cool, I'll try it

Yes, weren't you building one?

Yup, I've building a TBDML (look here). I didn't solder anything for a while here, and the post should appear once I confirm it is working.

I'd say bring ALL the PWM pins out, and a few others, perhaps ALL PWM and ALL ADC

All PWM pins are being used: the two GP 12v outputs are pwmable, another 2 are routed to the signal connector, and 4 goes to the stepper driver, just in case someone wants to develop a microstepping application.
Having the 16 ADCs is quite hard, but I'm going to try. Give me some days.

All analog and digital pins can be used as digital inputs

Give some preference for the digital inputs connected to ports that could trigger an interrupt.

I think we should mandate not exposing CPU pins without protection, what do you think?

No, pins cant be used without protection in a real setup. Besides, there has been some much effort to protect so many pins that it should be a must. What I'm going to do is expose vias for hacking, they are smaller than pads and eventually could be covered with soldermask or not. I'll ditch them out from the design once the testing is finished, I'd keep them if they weren't cutting ground planes intended for thermal dissipation. I still have to figure out how to do this complying with the DRC.

[jbelanger]

Do you have two VR inputs and two parallel bufferred digital inputs? If not, what do you have for this pair of inputs?

jbelanger said that a max9926 can handle both VR and digital signals for rpm measurement. I have two max9924 which are almost the same thing in a different package.

That is correct. I don't know if you've planned for it but if using a Hall sensor there might be a need for a 5V or 12V pull up to actually have a signal to the MAX992x. That could be done at the sensor but might be nice to have on the board.

Jean

[nitrousnrg]

Do you have two VR inputs and two parallel bufferred digital inputs? If not, what do you have for this pair of inputs?

jbelanger said that a max9926 can handle both VR and digital signals for rpm measurement. I have two max9924 which are almost the same thing in a different package.

That is correct. I don't know if you've planned for it but if using a Hall sensor there might be a need for a 5V or 12V pull up to actually have a signal to the MAX992x. That could be done at the sensor but might be nice to have on the board.

Thanks for the tip! I'll try different setups I think the pullup depends on the sensor you use. Once I know it works it would be included in the board design. That won't be in this prototype, unless I get some hall sensor to test with.

[Fred]

perhaps we should have a heart beat LED

Right now we have 9 leds. add the 8 injector driver leds I've just realized that aren't in the schematic.
There would be
4 ignition leds
2 GP power outputs w/led
1 fuel pump led
8 injector leds
1 TX (from the FTDI)
1 RX (from the FTDI)
I'm not sure if I want so many things flashing around, but the led would be easy to put in an empty zone.
The 5v switchable regulator could have one too.

With the case cover on, you'll see nothing, and with it off, they'll be invaluable. Don't be shy unless it impacts functionality.

Yes, weren't you building one?

Yup, I've building a TBDML (look here). I didn't solder anything for a while here, and the post should appear once I confirm it is working.

OK, I'll have a read up and see what I can figure out. It looks like it needs CW and winblows, though :-/ It'd be super nice to get some BDM action without all the heavy weight tools. HCS12mem might work with something. Hard to know.

I'd say bring ALL the PWM pins out, and a few others, perhaps ALL PWM and ALL ADC

All PWM pins are being used: the two GP 12v outputs are pwmable, another 2 are routed to the signal connector, and 4 goes to the stepper driver, just in case someone wants to develop a microstepping application.
Having the 16 ADCs is quite hard, but I'm going to try. Give me some days.

Just a suggestion, a handful of ADCs would be sufficient. Interruptable digital pins would be good too. Don't go crazy because of me :-)

As for 12v outputs, why, that's crazy! Why do you want high drivers? Why not feed your device with 12v and ground it through the EMS like anything else? No entiendo, mas informaccion, por favor.

I think we should mandate not exposing CPU pins without protection, what do you think?

No, pins cant be used without protection in a real setup. Besides, there has been some much effort to protect so many pins that it should be a must.

Do you mean yes? I said that we SHOULD specifiy no cpu pins are let out raw. You're right that they are borderline useless unbufferred, but people will still try :-) You seem to contradict yourself. The double negative might have confused you?

Fred.

[jharvey]

I'm not sure if I want so many things flashing around, but the led would be easy to put in an empty zone.

If you were to use a clear case, or a case with a clear lid, and you use either the white PDB material, or translucent FR4, you can make those LED's put on quite a show. It would really be for pointless ascetics, but it could be a way to show a bit of flare. Any how it's your version of it, so what ever you decide, I'll toss out ideas for consideration.

[nitrousnrg]

1. Is there an easy way to quote quotes of quotes??

OK, I'll have a read up and see what I can figure out. It looks like it needs CW and winblows, though :-/ It'd be super nice to get some BDM action without all the heavy weight tools. HCS12mem might work with something. Hard to know.

I didn't mind because I'll do that once in a while.. but yes, it'd be super.
This guy was close, but it developed a BDM kernel module for other family of freescale.
http://sourceforge.net/projects/bdm/
Another project that claims "Supports Freescale Codewarrior Software on Windows and Linux."
http://sourceforge.net/projects/usbdm/

As for 12v outputs, why, that's crazy! Why do you want high drivers? Why not feed your device with 12v and ground it through the EMS like anything else? No entiendo, mas informaccion, por favor.

Oh, now I get the misunderstanding, sorry, my bad. Replace "12v outputs" by "0-12v MOSFET driven outputs" :-)

Do you mean yes? I said that we SHOULD specifiy no cpu pins are let out raw. You're right that they are borderline useless unbufferred, but people will still try :-) You seem to contradict yourself. The double negative might have confused you?

Nope, I understood it right, expressed myself wrong. Lets try again:
IMO, unprotected pins shouldn't (can't) be available.
1. In my board there are plenty of available and protected pins to use in the connector board, no hacking needed in the cpu board. The vias available for testing are an exception, that will happen only in the prototypes.
2. There is the chance to have many hardware configurations. Mine has 33+ I/O, jharvey has more I/O and more configurable, hamster could make a smaller board. We don't need to hack our board like a MS, the user should choose the right board from the beginning and we must embrace that important decision. If he wants to hack it, is free to do it, but we must let him know that the easier way is to choose the right board.
3. From the point of view of the FreeEMS brand, an available cpu pin give means to unqualified people to hack it and make stupid mistakes. If a stupid mistake leads to a failure during a competition, or a normal user suffer a failure because of the guy who installed his EMS, then the racer/user/people watching could blame FreeEMS. That happens a lot, and for us it would involve wasting time in the forum (looking for solutions to an avoidable problem), losing some reputation, and maybe some users.
With the adapt board it is harder to avoid a hack, though. It is MADE to be hacked! (in a nice way, of course ;-)

Maybe this is a way to say it:
In a FreeEMS-compatible board, every pin used must be protected from the environment, every pin not used should be left unrouted.
Its a bit tough to be a free hardware, isn't it? Maybe we should allow mocking to users/tuners who doesn't respect a minimal setup quality/protection :P

A thought: If everything works fine, as we expect, my boards will be identified by an ID number. I want stats. If a failure happens, I want to know why it happened. If no failure happens, then cool, we'll put somewhere a gaussian plot showing how reliable our boards are :-)
So, the guy having something wrong can post the problem here or by mail referencing her/his "puma-v1.02#147" for example. Its just a way to track problems. Maybe a group of boards went crappy because of the solder paste, or atmospheric conditions, or a bad reflow pattern, who knows.

[nitrousnrg]

I'm not sure if I want so many things flashing around, but the led would be easy to put in an empty zone.

If you were to use a clear case, or a case with a clear lid, and you use either the white PDB material, or translucent FR4, you can make those LED's put on quite a show. It would really be for pointless ascetics, but it could be a way to show a bit of flare. Any how it's your version of it, so what ever you decide, I'll toss out ideas for consideration.

The case must be metallic, a tradeoff between aesthetics and functionality must fall in favor of the latter. The clear lid could be implemented, though. Leds will be populated, though I need to see them flashing to have a more accurate impression.
Do you have a translucent FR4 image? That sounds cool and google didn't show me anything...