[Ovmsdev] V3 size and arrangement

[Mark Webb-Johnson]

The Saleae software is pretty cool. It supports SPI, CAN, etc. Full list of protocols is:

SPI, I2C, serial, 1-Wire, CAN, UNI/O, I2S/PCM, MP Mode, Manchester, Modbus, DMX-512, Parallel, JTAG, LIN, Atmel SWI, MDIO, SWD, LCD HD44780, BiSS C, HDLC, HDMI CEC, PS/2, USB 1.1, Midi

Triggering is the only let-down - it is pretty basic and just on level transitions.

I use a US$10 clone with 8 channels and sampling up to 24million samples /sec. I really should buy something better, but that works great for me on the relatively low-speed embedded protocols. 1MHz stuff like CAN is no problem.

I’ve also messed around with Sigrok <https://sigrok.org/>, which is pretty cool and supports the Saleae analyser clones.

Regards, Mark.

> On 11 Jun 2017, at 10:23 AM, HONDA S-2000 <s2000 at audiobanshee.com> wrote:
> 
> 
> 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
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20170612/fca39959/attachment.html>