[Ovmsdev] V3 size and arrangement

HONDA S-2000 s2000 at audiobanshee.com
Sun Jun 11 10:23:43 HKT 2017

On Jun 8, 2017, at 10:41 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> Really rather cool to watch the logic analyser display SPI bus traffic to/from the MCP2515, then CAN bus output of the message itself.

It's all about the protocol analyzer. They can be expensive for full-sized oscilloscopes. I used a Tektronix with I2S and I8S decoding on a system with 32 audio channels on 4 data lines (8 channels per serial data line), and the 'scope displayed the audio samples as hex values right on the LCD.

Does the Saleae software product actually decode CAN protocol?

On Jun 10, 2017, at 6:21 PM, Tom Parker <tom at carrott.org> wrote:
> We'll have to think very carefully about security for the code upload -- being careful not to implement risky functionality is moot when you can upload new code. The PIC's Harvard architecture and out of heap stack also made it pretty safe in the face of memory corruption bugs. Is the esp32 a von Neumann architecture? Is the stack in the same address space as the rest of system ram? Can pages be marked read only or no execute?

I'm not sure that I understand you perfectly, but I thought it might be interesting to point out that the older Microchip compiler did not use the hardware (15-level) stack. Instead, the old C compiler implemented a software virtual stack using one of the three pseudo address pointer registers in the PIC18. The old way meant that C code operated pretty much the same as it would on "normal" processors, albeit a few cycles slower per push/pop operation.

When Microchip purchased the High Tech C compiler (at least I think that's the one they bought), this switched over to using the limited hardware stack for function return addresses only, combined with code analysis to detect call trees that might be too deep for the limited stack as well as placing automatic variables that would be on the stack into fixed RAM addresses. They even go so far as to treat interrupt call trees separately from the main, allocating two versions of automatic variables to simulate the way they would be separate if they'd been allocated on the stack. This is a great optimization, but I ran into serious issues porting old C source written and tested on the Microchip compiler to the High Tech C compiler. I also believe that I found some serious bugs in the analyzer, but those all seem to be gone, now.

As you might guess, I have a love/hate relationship with the PIC architecture.

Brian Willoughby

More information about the OvmsDev mailing list