I’ve created new documents that may be of interest to C-Block component developers:
C-Block Basics #4 — Revisits the Trunc() function, the QSpice simulation cycle, and more. Implements a simple comparator component example.
C-Block Basics #5 — Revisits the MaxExtStepSize() function, a QSpice “peculiarity,” and more. Implements a basic component with an internally generated clock.
I hope that you’ll find them useful. As always, please let me know if you find issues or have suggestions for improving the explanations or examples.
–robert
My GitHub QSpice repository is here.
The new documents are in the CBlock_Doc folder.
I’ve posted a couple of new documents in this unplanned C-Block component series:
C-Block Basics #6 – Connecting schematic bus wires to C-Block components with a focus on implementing “bit vectors” in non-Verilog code.
C-Block Basics #7 – Recent QSpice changes (new Display() function & Trunc() simplification). While mostly backwards compatible, there are “edge cases.”
I’ve added a new document in the unplanned C-Block component series: C-Block Basics #10 – “A ‘Berkeley Sockets API’ Reference.” It covers: The new API calls, data message contents, and limitations of the template-generated code.
A future document will demonstrate how to extend the client/server code to work around limitations.
Have you got a detailed description of how to use your QMdbSim_Project with QSPICE. I’ve not used the actual silicon PIC16F15213 device but I’m willing to try it if I can simulate it QSPICE. How would I for instance turn an LED on and off? Do assume use of XC8 in your setup? Thanks.
It appears from the notes that the device specific demonstration code required is in .hex or .elf format. I’m assuming that the compiler can be any that works with MPLABX? I mainly use the CCS PCM compiler with the PIC16F819/PIC16F1827/PIC16F1847. I will first try the PIC16F15213. Thanks.
PS Is a very simple R2R DAC possible with this framework?
You can create the *.hex/*.elf with whatever tool can produce it.
As for creating a DAC with the PIC16F15213, I don’t see support for DAC in the datasheet. Maybe I missed it.
Things to keep in mind: The project uses the Microchip software simulator, the tool that is used by the MPLabX software simulator in the IDE. The project simply tells the simulator to load the *.hex/*.elf and passes pin states between QSpice and the software simulator. If the Microchip simulator doesn’t support a given peripheral function on a given device, then that functionality isn’t supported in the project either.
See the “Simulator Peripheral Support By Device” link in the Resources section of the project PDF.
As a general observation based very limited data points, I don’t think that Microchip tries to support analog voltage peripherals (e.g., ADC, DAC) in their software simulator. But, again, check the above link for specific devices – I could be very wrong about that.
I’ve added a new document in the unplanned C-Block component series: C-Block Basics #11 – “Extending The ‘Berkeley Sockets API’.” It demonstrates techniques to work around the client/server limitations identified in the prior paper. C++ and Python code examples are included.
I’ve added a new document in the unplanned C-Block component series: C-Block Basics #12 – A “Berkeley Sockets API” Multi-Client Server.
The client/server code generated by QSpice can launch servers on the local machine. Each schematic component instance starts a new single-threaded server on a unique port. While simple for testing, it’s not practical if you want to run the server on a separate host.
The example code implements a server that accepts multiple client connections on a single port. Each client connection runs in a separate server thread.
Update: C-Block Basics #12 now includes a Python version of the multi-client server. In theory, the Python server can be run on non-Windows platforms without modification.