deterministic manner where you can count on the timing of things happening. with the Raspi I don't think that a linux based solution will provide this.
funny you should mention this. must be psychic or something. oh wait. was thinking about the exact same thing on the way home Simon. the interpolation between maps and then calculations to provide an output to modify an injector 'pulse' time i think would stretch the limits of what something like python or perl atop atop a debian OS would not be able to do quickly enough. the idea of mapping and logging though as a piggyback into the existing sensors however, would not be too much of an ask although some fuckery with A--D conversion might, again stretch the limits. interesting nonetheless. thanks heaps for your input.
C would be the only way to go for the guts of the code but you could use perl or similar for the user interface bits. Would be cool to try it out. Not too sure of the best architecture but dual ported RAM might be the best idea with the Delco doing the hard lifting and the Raspi fine tuning or adding features. 99% of the code is in place with the existing code base but would require some hooks to allow the tweaking. The dual ported RAM idea would also allow the Delco code to be expanded and use more inputs. Lots of potential.
The first question is what features do you want to add? The old 808 does a lot with its 2mhz processor and.. 256 bytes? of ram. Flex tables provide a lot of extra options. Additional features might be better implemented as specific hardware than moving the core logic out of the delco. Not to say you cant, though...
I thought the main downfall/issue with the Rpi's is that they chew through the SDCards slowly, my old PI killed one after about a month. But that was on constantly.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Depends how you set it up. Only if its constantly writing. Disable or reduce logging, disable saving filesystem access times, dont configure swap and dont run out of ram and it should be fine. Case in point gm mdis are linux on sdcard and they're fine (and the os is built for it).
antus wrote:Depends how you set it up. Only if its constantly writing. Disable or reduce logging, disable saving filesystem access times, dont configure swap and dont run out of ram and it should be fine. Case in point gm mdis are linux on sdcard and they're fine (and the os is built for it).
Ahhhhh.. that might be it. Wonder if I pushed it too hard on ram. Had it setup as a media server, although.. it was never turned off. Least the MDI gets a break
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
interesting. good discussion.
so putting stuff direct into memory would be the way to go. so all tables would load from the SD into there and stay there at least until the battery was removed.
was watching a couple of videos last night, one specifically on pulsing injectors ironically from a bit of python and at the time the guy mentioned something along the lines of the inconsistency of timing /massive fluctuations on the pi which you clearly see on the scope.
Cheers,
Greg aka Sir Burnie Tanington
VX1 Berlina V6, VT1 Berlina V6 (Track), VN1 S V6, Hilux RN105 GMV8, Ford XP 170.
Reading is fine, but flash has limited write cycles. Modern SSD is better because flash tech has improved (can handle more write cycles) and the drives have smarts to move data around to spread the wear evenly across the available flash and to work around bad blocks transperent to the PC. Since those SSDs are typically 256G or more these days its no problem for a normal PC. But sdcards are mostly older flash tech with less write cycles and without a lot of the smarts so you cant push them as hard when using them as a PC drive. Add noatime as a mount option in /etc/fstab, remove the swap from there as well and stop the syslogd service and set it not to start at boot. I bet it'll make a world of difference to sdcard life.
While im at it, if it is linux on an SSD also add discard as a mount option. The os will then tell the drive when a file is deleted what blocks can now be considered considered unused, and the drive will erase them in its spare time so when they are next written you dont have to wait for the erase cycle to happen. It improves throughput somewhat and keeps the drive running optimally after you'd put more than max capacity data through it and deleted stuff.
