DIYEFI.org Forum

Spudmn wrote:What I might do is start with the Puma board and change the code to be a data logger.

It already does this, unless you mean writing to the memory, in which case, can't we just add that to the main code using git? It's free software, so do as you like, but it'd be good if we could keep the efforts unified for the time being :-)

Jared: There is a can port exposed in the direction of the fuel pump fet from the cpu.

Fred.

Fred wrote:Jared: There is a can port exposed in the direction of the fuel pump fet from the cpu.

What? I get can is CAN, are you saying that one of the CAN pins is used as the fuel pump? What about the others, I suspect we want a fuel pump, and I seem to recall it has several CAN ports.

It already does this, unless you mean writing to the memory, in which case, can't we just add that to the main code using git? It's free software, so do as you like, but it'd be good if we could keep the efforts unified for the time being

I was thinking of writing the logs out to an SD card. I was under the impression that you didn't want to tax the CPU with lots of SPI transfers and you preferred capturing the serial stream.

If I can get to all the CPU inputs and the data logging won't tax the EFI code (I wouldn't write it that way) then I would love to cram as much data logging functionality into the board as I can.

Jared read again, and look for connection points labeled "can" in that location.

Spudmn, well, I doubt it would matter much for it to be doing spi transfers, we will have to evaluate everything as we do it and make appropriate compromises at that time, I have no issue with servicing SPI from the CPU in theory, as long as any interrupts are fast running and/or we can schedule it with other tasks from the main loop. Cram away.

Fred wrote:Jared read again, and look for connection points labeled "can" in that location.

Ah I see, P104 one of the misc pins I put in there because we could, is one part of CAN. Unfortunately, pin 91, the other part of CAN isn't as easy to access. What about those general purpose pins, any of them CAN capable?

No, you still don't, they're on P71 at the header end, closest to the fuel pump fet.

I have been thinking about the architecture of the data logging code.

I would like to try to run the File System and SPI for the SD card on the Puma CPU rather than on a separate board.

The key to doing this is making sure that the File System calls don't block and return back to the main line quickly.

Normally a call to FileOpen will block until the lower layers have accessed the SD card a number of times and then it will eventually return with the file handle. This is true for many FS calls

With a system like free-ems we can't block the main line while the File System layers do what they need to.

My idea is to have a state machine based FS that will have a task that is called regularly from the main line. This will do all the back ground FS tasks and avoid any blocking of the main line. It will take care of SPI calls which will be interrupt driven.

Calls that may block will need to be restructured so that there is the normal function call and a poll for completion.

Eg
FileOpen → returns immediately
FileOpen_Complete → will return True when the function is complete and the handle is ready.

This will make the FS calls different from standard but since we will be writing the code that calls it ,I think this will be acceptable.

This may mean that I will need to buffer more data in RAM.

What are your thoughts and suggestion.

It all sounds good except the "buffer more data in RAM" bit, I'd expect you to take data as often as you could, and whatever was current at that time. There is already buffering of data to avoid use of mixed sets for calculations. You're going to need to buffer whatever you want to write, I guess, but that is likely to be just a set, isn't it? Maybe this would be best discussed in person soon, it could be easier to bounce ideas back and forward.

yeha lets take it off line. I will look at my code and try and get a handle on what it's doing. it's been a while.

I look forward to seeing it cleaned up and published in Git under a suitable license! :-)