Jason/And others on the BBGG,
My name is Chris Grey. I work for an HVAC controls company called, Automated Logic where we use the AM3352 in our product and started our development of that project on the Beaglebone (white at the time). So I'm familiar with the BBs and have always thought they'd be a good platform for a personal side project. After watching your videos about the PRUs, I think that project is within reach of giving some time and researching in earnest now. I'm also a DIY Ford computer tuning enthusiast and admin of a forum hosted at EECTuning.org which is dedicated to people discussing Ford EEC computer tuning for high performance street and racing applications. As I'll detail more below, I think I have a good fit for the BBB and it's PRUs. So I'm in the research phase of learning everything I can about the PRUs and how they interact with the Cortex A8 and the GPIOs. I've watched the videos that were posted up on the beagleboard.org website where you gave a presentation about the PRUs. It was a good start to an intro, but it didn't cover some of the details I was hoping to see. Here are the bullet points of things I thought could be improved in the presentation...and many may have been by now. * Intro to the PRU assembly and the documentation where the Operands are discussed * A bit more in-depth coverage of the C/C++ compiler (don't care whether it's the TI or GCC as long as it compiles to usable code) * Specifics of how to load a C-compiled or Assembled ELF into a PRU. * A bit more about the shared memory between the PRUs (maybe just a slide on the memory map of the PRUs that points to where the 8k PRU memory is and where the 12k shared is (no more than just show that assuming it's that simple) * Quick discussion about GPIO. The memory mapped GPIOs are fairly self-explanatory, but how are non-memory mapped GPIOs accessed by the PRU? * When using the PRUSpeak Linux driver as a starting point, talk about the things most likely to change in a custom application vs the things you recommend that probably shouldn't be changed (if any). The thing I wouldn't expect you to speak on is the details of making Linux drivers. That's well covered in other areas of the Internet...no reason to re-cover what's already been done. * I'm also a little confused between RemoteProc using the stack and messaging and the shared memory technique. Messaging seems more flexible and it also seems like a lot of the memory management details are abstracted away. Is this just the "newer" thing that wasn't available when you made the presentation where BotSpeak was discussed? If so, that's understandable. If you have newer presentations where some of this is covered OR you can link me to where I can get some of these answers, that'd be great. From these videos and the website, I've re-imaged my BBB and actually walked through the BotSpeak exercise you did in those presentations. Being able to pause and replay made watching this way even better than actually being there, so please don't hesitate to post up presentations you do in the future like this. They are valuable...probably more-so to people online than to the people in the class. Anyway, here's the problem I'm hoping to solve. I'm a Ford EEC tuning enthusiast. Right now, the only options for retuning many of the older Ford EECs is to work with the stock tune that came from the factory and change parameters within the tune. The way this has been done is somebody has to disassemble the assembly and Ford did a LOT of things in their assembly that make disassembly not easy. Some claim they were performance enhancement techniques, others just claim it was their attempt to make disassembly hard to do. But like most good hackers, people figured it out and from there, we found the memory offsets of the parameters we care about. Using a spreadsheet we map the parameters, put english descriptions to them, and formula translations so we can convert 16-bit values like 12000 to something meaningful like 5.1v. Then there's software built around those spreadsheets to do the work for you. And finally the hardware part where the modified tune is written to a chip that over-rides the EEC's onboard PROM chip and, instead, feeds the processor the modified tune. That's worked, but it's very limiting in that you can only do what Ford programmed as options to change. If you don't like their actual algorithm, practically speaking, it's just not feasible to change the code. Anyway, what I'm wanting to do is harness the power of the PRUs to speak to the onboard processor, a Ford-specific derivative of the 16-bit Intel 8096, called Intel 8061 (single bank) and 8065 (4-bank capable). They range from 12MHz to 24MHz clock cycles, where the 8-bit memory-bus runs as 1/3rd the processor clock. I want to, on the fly, emulate the PROM by sending the processor opcodes and operands that basically marshal data to/from the Cortex A8 and the EEC's processor's I/O thus relocating all the engine management logic to code running in the Cortex A8 and turning the EEC's processor into a slave co-processor that does nothing more than read the inputs, write to outputs, and inform of events (i.e. interrupts). The details of how that can be done, I think I have a good handle on. >From what I can tell this is similar to the 6502 slave memory project that was >done. The difference is this processor uses only 8 data/address lines, not 8 >instruction lines and 16 data lines. While this complicates the programming, >I'd think this would vastly simplify the board pinout. What I don't have a solid handle on is the Linux Driver, PRU programming/management, and GPIO pin management aspects. I know I want to use the PRU memory-mapped GPIOs so I can read/write 8-bits of data at a time since I only have 8 pins that will require bi-directional data flow with the EEC's processor. There are 4 control lines that will be dedicated inputs and thus the PRU will only read them and so I'm assuming these can be any GPIO, not necessarily memory mapped. At this point, it's just getting the technical pieces all understood so I can plan out the data-flow strategy from Cortex-to-PRUSS-to-8061. It'd be nice to leverag as much already-written open code as possible, but I don't want to force square pegs into round holes. Once I can see I can send the EEC processor lucid opcodes & operands and witness it responding to those opcodes correctly, I can start the fun part, which is actually writing the memory management and datalogging code up in the Cortex. That statement glosses over a LOT of technical things, but for the purposes of this discussion, I'm boiling it down. For those curious to know more about the Intel 8061/5 processors, here's a link that goes into fair detail about their architecture: https://www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiV8Jv19_DZAhVRzFMKHW0sCz4QFggoMAA&url=http%3A%2F%2Fwww.auto-diagnostics.info%2Fpdf%2Fford_eectch98.pdf&usg=AOvVaw2QthMX8WTTp8p51ERHSuFz The EEC Memory Control section will probably be the most relevant to this discussion. Much of the other stuff discussed are more application-specific to the EEC being an engine management device. The absolute end-game is to get an architecture sophisticated enough that in 5-10 years, custom hardware could be made to completely replace the Ford EEC and run a high performance, open sourced engine management control logic that's brand-agnostic so you could adapt the product to control Chevy engines, Toyotas, whatever, and interact with it using modern day conveniences like Bluetooth or Wifi. In the case of my truck, an 89 Ford Ranger that I've transplanted a Ford V8 into, the computer that's in it (an 89 Mustang EEC) dates back to the mid-to-late 80s. The repair companies that reman these EECs have already dropped support for this era controller. So when these EECs go bad, they are bad. The average Joe motorhead generally doesn't have the desire or skill to diagnose and replace components beyond, say, an exploded cap. So having a modern aftermarket solution that's BETTER than the open sourced solutions out there now would be desirable. The best open source project out there now is MegaSquirt, and that technology and project dates back 20 years. It works, but it's antiquated and only marginally less cryptic than dealing with the stock Ford programming. Anyway, that's my project idea. And I'd like to learn more about the PRUs because I think they could be the key to me making this actually possible. I'm scrounging the TI website and any other wikis I can find as well as following any links that look interesting. But any extra reading or videos I can get would be greatly appreciated. And if you know anybody else that'd be interested in participating in a project like this, let me know. I could definitely use help. This is not going to be an easy feat and there's plenty of opportunity for collaboration even if you aren't a motorhead. Chris Grey ALC/Firmware -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1521206886938.46486%40automatedlogic.com. For more options, visit https://groups.google.com/d/optout.
