Alright, this is getting out of control. I'm not going to post anything else about this issue. I'm going to talk to Tom (same setup as me), and if I still can't get things working, I'll call Craig. This thread just kinda snowballed. Initally, I expected to make a single change somewhere and have it work. It was not my intention to cause an arguement or bash any equipment. Thanks tons for all your help you guys, I really appreciate it, and without you, I probably would have been too scared to tinker with my truck -er thirdgen in the first place!

 

This thread got jacked.

 

Yes, I looked at this with respect to the bootloader stuff. There was a point in time where I was thinking about how to allow bootloader code updates in the bootloader code itself. It's possible, but tedious. If you want to chat bootloader stuff, encrypted or otherwise, feel free to give me a yell offline as I've had some pretty good luck in this regard.

Lots of folks have asked about the trace functionality. With the CPLD, it gets pretty interesting. I'm shooting for doing a 'snapshot' approach, and then strobe it back to the moderating AVR and back to the user. Maybe even have a CPLD-arbitrated 'series' sort of function, whereby stuff gets stashed in blocks to see where stuff is streaming. While the OBD1 part fo the GM stuff is fairly well documented, there's all kinds of stuff out there like Volvo, Mercedes, you name it.

By the way, many thanks to J for the advice early on in the AutoProm development. It was most helpful, and got me thinking correctly in terms of balancing actual latencies and propagation delays with respect to memory operations. I worked the razor's edge of what was possible for the architecture of the AP, and tried to take further advantage on the Ostrich. Everything comes into play, from pin capacitance to SRAM programming cycle requirements. I think he was the 'only' one I shared the early schematics with.

Final point of clarification, and of some use more than just making the point. For write cycles on both the AP and the Ostrich, I make no decisions with respect to the timing based on the CE/OE state coming from the target device (abandoned that after fruitless efforts!). Rather, I have the data lines buffered out from the RAM to the target device separately. The buffering is exerted based on the target states directly. However, the inputs to the data buffer are latched synchronously with the write cycle as arbitrated from the AVR. In this way, you can squeeze the write cycle into <100nS, and without any exertion of data other than that which is requested by the target device, either on the leading or training timeframe of the write cycle.

It's trick, but it works. Hope this makes sense. Think about it a bit, it really is pretty trick ;^).

 

OK, back on topic. If you bought something from Craig and can't get it to work, call him on it. He'll get you straightened out ASAP.