Puma board for FreeEMS

[TonyS]

330 ain't good enough unless its some logic level input (which I thought these ignitors are, but they aren't...).

but they deliver max of 35mA and max of 70mA for VCC or GND

For now, in lieu of a functional 12v solution, i'm running with two 2n5401 transistors (on the ms2, 4 on the puma soon) and 2 10ohm 1/4 current limit resistors, this should give close to 35mA continuous from both channels without risking damage.

Jared has a good solution, or one that appears to be.
Fred.

Fred, please restate as I am not clear on what you are trying to do - What ignitors are out there (most likely to be used to least likely to be used) and what are there "triggering" requirements. I am seeing a bunch of "solutions" without the problem being clearly defined. What voltage / current requirement is not being met?

Whats wrong with this one?:

This circuit appears to be a Darlington configuration in which Vce-sat will be > 0.8V. EDIT - Ding Dong, I'm wrong - never mind
Again, what are the requirements of the ignitors?
Thanks,
- Huff

[KW1252]

A quick request about a subject aside; put the MISO/MOSI/SCLK//SS signals and GND/+5V into a header, please. Those will be needed for SPI applications.

[jharvey]

This circuit appears to be a Darlington configuration in which Vce-sat will be > 0.8V.
Again, what are the requirements of the ignitors?

The problem is based on a physical device that Fred was wiring for a FreeEMS install. The igniter is an OEM and is likely a Darlington device itself. A schematic or part number hasn't been mentioned. With empirical data collected by Fred, it will not change state with 5V and appears to work with a +12 current limited signal.

Design specs include, when the MCU is off AKA no pin drive, the igniter is off. No melt down. Ability to drive +12v at something around 20mA min and more mA is preferred. Ability to drive a +12V signal to the igniter with the maximum reasonable current possible. I believe signal delays can be induced to warp the signals as they come from the MCU, so a consistent switch time is more important than a fast switch time. Fast switch times will tend to lead to lower heat at the MCU, so it's still handy for a fast switching time.

[nitrousnrg]

put the MISO/MOSI/SCLK//SS signals and GND/+5V into a header, please

Done.

I have nothing to say right now about the ign pre-driver, I need to search in the forum about this subject. If Fred comments about the posted circuit, some further testing could be done, so far I only did simulations.

[Fred]

It's a bad idea to spend time and effort modifying the bootloader because if you do, it might be incompatible with the TA card which would require thorough end-to-end testing to prove to me that it was in fact safe and compatible with the hardware that it's intended for, and you're struggling to find time for the basics as it is, without increasing your required workload well over and above what is possible

Bullshit.

Fixed. Thanks.

The Puma board doesn't use the TA card and the bootloader has no impact on the code.

Bullshit.

The "bootloader", correctly known as Serial Monitor, has absolute impact on the code in terms of the way it is configured, the way it passes interrupt calls around, how much space it takes up, how quickly it executes its startup procedure, the pin state that it leaves the device in whilst running, etc. Wrong or even intentionally different configuration of the freescale code, or totally custom code, could EASILY fuck up the firmware operation in various ways. Hence it would require thorough testing which is outside of the scope of the current Puma design team's intent and time resource capacity.

So if changing the bootloader and specifying some wiring that allows you not to have oodles of useless components then that's a much better choice. The new bootloader can be 100% compatible with the PC side of the loader and still initialize some pins to a safe state. And the transition during the reset can be handled by some control pin that does have the hardware protection.

True. See fixed version of original statement above.

If (open) designs are hoping to be labeled "FreeEMS compliant" then they will have to provide design parameters, test results and test units to me with the modified bootloader in both code and binary format such that they can be verified as working, documented and distributed. Standardisation of GP designs that are to be distributed in quantity is SUPER important, so I will treat it as such.

Fred putting such unnecessary limitations on this is not only shortsighted it can also prevent some people from using FreeEMS as a basis for their own project.

This isn't the thread for politics, but the intent was always to have a unified solution that works so well that no one wants to fork it software wise. See above for revisions of that statement, which was misleading, to something that more closely resembles what needs to be true of such modified setups. I don't require glasses.

I know it would in my case. For example, I'd want to be able to have a bootloader that uses CAN instead of RS232 or USB.

Do you really think you could achieve that inside the 2k allowance and remain compatible with vanilla firmware builds? If not, that's not really in line with the projects unified solution goal. If so, cool! This is all OT though, start a new thread on modified serial monitor code variants if you wish.

Jared, re ign drive, it's not as simple as "works/doesn't", I never said 5v wouldn't switch it. I said 12v switches it BETTER, and that 5v is not enough.

Marcos, do NOT put a reset button on the board... both the SM and firmware can be hard reset over the wire, plus the BDM pins are there if a physical reset is required. As for your dislike of constant current drain when not driving the ignitor, I agree, and if your schem works to avoid that, GREAT, let's roll with it? I'd like to see some bench testing of these designs before they are integrated, though, and it sounds like you're planning that, fantastic.

Fred.

[nitrousnrg]

Marcos, do NOT put a reset button on the board... both the SM and firmware can be hard reset over the wire, plus the BDM pins are there if a physical reset is required.

I won't put a reset button, so resets are going to be brief. So brief that the only high impedance moment of the outputs would be during the SM execution. Is not a crazy idea to search through the SM binary and change a couple of instructions to set up the ports as we want. Not that we have the time to do that... but it seems doable.

As for your dislike of constant current drain when not driving the ignitor, I agree, and if your schem works to avoid that, GREAT, let's roll with it? I'd like to see some bench testing of these designs before they are integrated, though, and it sounds like you're planning that, fantastic.

Ok, adding some transistors to the order. If some decision is made about the depletion mode mosfet, I'm ordering a couple of those too.
I need to get some IBGT and darlington igniters, or something similar enough)

[jbelanger]

Fred,

Please move this and other posts in a more appropriate section if you think there is a need for it. I would start a new thread but there might be a need to move other posts to it which I can't do.

It's a bad idea to spend time and effort modifying the bootloader because if you do, it might be incompatible with the TA card which would require thorough end-to-end testing to prove to me that it was in fact safe and compatible with the hardware that it's intended for, and you're struggling to find time for the basics as it is, without increasing your required workload well over and above what is possible

Bullshit.

Fixed. Thanks.

The Puma board doesn't use the TA card and the bootloader has no impact on the code.

Bullshit.

The "bootloader", correctly known as Serial Monitor, has absolute impact on the code in terms of the way it is configured, the way it passes interrupt calls around, how much space it takes up, how quickly it executes its startup procedure, the pin state that it leaves the device in whilst running, etc. Wrong or even intentionally different configuration of the freescale code, or totally custom code, could EASILY fuck up the firmware operation in various ways. Hence it would require thorough testing which is outside of the scope of the current Puma design team's intent and time resource capacity.

But the bootloader doesn't have to be a monitor. It can be used strictly for loading code and the code should be totally independent of what this does be it loading or monitoring. Monitoring and debugging can be done through other means and if you can upload a bootloader to a new chip, you should be able to monitor the code with the same device instead of using the serial port (and monitor).

Having firmware depend on this piece of code (monitor or bootloader) for anything is totally wrong. The firmware has to act as if the CPU just got out of an unknown state and initialize everything. If changing the initial state in the bootloader has an impact on the firmware then the issue is on the firmware side not the bootloader side and should be corrected there.

On the other side, the hardware implementation has to take into consideration what is done in the bootloader since whatever state it leaves the pins in while running can have disastrous effects if not considered and understood.

So if changing the bootloader and specifying some wiring that allows you not to have oodles of useless components then that's a much better choice. The new bootloader can be 100% compatible with the PC side of the loader and still initialize some pins to a safe state. And the transition during the reset can be handled by some control pin that does have the hardware protection.

True. See fixed version of original statement above.

If (open) designs are hoping to be labeled "FreeEMS compliant" then they will have to provide design parameters, test results and test units to me with the modified bootloader in both code and binary format such that they can be verified as working, documented and distributed. Standardisation of GP designs that are to be distributed in quantity is SUPER important, so I will treat it as such.

While I do agree that testing has to be done, changing the initial state on some pins is trivial in terms of the code needed. So the only testing needed should be to read the data sheet and select the wanted state and test that it actually does it on the target hardware while making sure there is no unwanted side effects at power up.

Not allowing a change in the bootloader or making it difficult to change it will create more work and a less reliable one in some circumstances. And I think that the Puma is one such example. Keeping some of the hardware as it is now and changing the bootloader initialization code is easy to do and can be tested in minutes. Changing the board layout and routing and testing these changes is at least an order of magnitude more and is also more risky due to the amount of change required.

Fred putting such unnecessary limitations on this is not only shortsighted it can also prevent some people from using FreeEMS as a basis for their own project.

This isn't the thread for politics, but the intent was always to have a unified solution that works so well that no one wants to fork it software wise. See above for revisions of that statement, which was misleading, to something that more closely resembles what needs to be true of such modified setups. I don't require glasses.

I know it would in my case. For example, I'd want to be able to have a bootloader that uses CAN instead of RS232 or USB.

Do you really think you could achieve that inside the 2k allowance and remain compatible with vanilla firmware builds? If not, that's not really in line with the projects unified solution goal. If so, cool! This is all OT though, start a new thread on modified serial monitor code variants if you wish.

From your statements here, I'm not so sure that you don't need some glasses. It may not be for shortsightedness but maybe astigmatism. In any case there is definitely some bias or maybe even some misunderstanding...

I already have a CAN bootloader that fits in about that space and it can certainly be trimmed. It would require a different PC loader for the code but again this is not (or should not) be an issue since it is completely independent from the firmware. And even if it needed more, the interrupt vector relocation can handle different bootloader sizes so unless the firmware fill up the entire base 64k page it would be totally transparent. But that's not the best option since it would create loading issues if the memory gets filled at some point.

On the other hand, having a "big bootloader" branch would be almost trivial and would simply require reserving an additional 2k in the base page. Relocating some functions should not be a big deal up until the point that memory starts to be really full. But what may not be so trivial is managing this non-unified solution and I understand being reluctant to go this way.

Jean

[Fred]

But what may not be so trivial is managing this non-unified solution and I understand being reluctant to go this way.

I wanted to beat your head on a concrete wall repeatedly up until I read this sentence. I'm glad you understand...

When all of the people that want to order parts for and construct their puma's from the documentation that is yet to be finished have, I'll endorse any decision to fuck around with Serial Monitor changes OR (different thing!!) replacement bootloaders. Until then, no, it does not have my support or blessing.

Carry on.

Fred.

[nitrousnrg]

People curious about spin2 can check the fist post of the thread.

Its messy, but keep in mind I'm not doing any layout until I'm sure about the circuits. TO220 stuff was mostly removed, I kept the ign ones in case someone wants to drive his coils directly from the board, but that kind of optional stuff won't be visible in the 3D view (like those big capacitors laying around)

Inj circuits are in standby, you can see TO220 were replaced by D²PAK, and DIP8s went to the bottom side. I did the pre-layout for only 2 of 8, just in case I'm not satisfied with the testing.

Communications connector has:
* SPI (MISO, MOSI, CLK, /SS)
* CAN/UART (2 pins:+,- or tx, rx)
* I²C (SDA, SCLK)
* GND and switched 5v

I have a bad feeling about putting a 5v source that can be shut down at any time. I'm afraid it could screw up SD cards, memories, GPS, etc.

The SMPS is in there too, at the left. The big D²PAK is the diode, there is a shielded inductor and a cap without 3D model (just noticed that). The tiny SO8 is the controller. Less demanding applications can leave the SMPS unpopulated and carry on with the LDOs (note: the big one should be changed since its max input voltage is 6v or so, but fear not! there are similar regulators with the same footprint that work). Also, the big LDO has an enable pin.

Between the comms header and the MCU there is now a super tiny temperature sensor, I really wish to know the board temperature, but I have no problem in flag it as optional. It sends info through I²C, so the layout is trivial, its only a matter of hang it in the bus.

There are lots to do, like:
* use a tiny programming header (after all, its used once in the board life)
* flip pressure sensors
* 5.00v reference voltage for the ADC
* redesign connections layout for connector boards
* choose a default for thermistor circuits
* define igniters pre-driver circuits
* solve EGT isues
* create an exposed pad somehow under the MCU as a heatsink. The same for the stepper driver
* etc

Its been quite a lot of work, the TODO for spin2 had almost 50 items, and now it is getting closer to completion

Following the topic, I prefer to change 6 lines of assembler rather than add 21 resistors to the board.

Having firmware depend on this piece of code (monitor or bootloader) for anything is totally wrong. The firmware has to act as if the CPU just got out of an unknown state and initialize everything. If changing the initial state in the bootloader has an impact on the firmware then the issue is on the firmware side not the bootloader side and should be corrected there.

The guy has a good point here.

[jbelanger]

Inj circuits are in standby, you can see TO220 were replaced by D²PAK, and DIP8s went to the bottom side. I did the pre-layout for only 2 of 8, just in case I'm not satisfied with the testing.

For p&h drivers with the LM1949 controlling the transistors in linear mode? With up to 10W per driver?