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.
I’ve added a new document to the unplanned C-Block component series: C-Block Basics #13 – “Sharing Data Between Component DLLs.” In addition to explaining how to share data directly between DLLs, the paper/code explains/demonstrates why you shouldn’t do it.
The paper is available on the dev branch of my QSpice GitHub repository. This is an early preview and likely will change before moving to the main branch.
Hopefully, you’ll find the information useful. Please let me know if you find issues or have suggestions for improvements.
I’ve added a new document to the unplanned C-Block component series: C-Block Basics #14 – “C-Block Component Symbols.” It provides a simple process to create Symbols from DLL components, demonstrates using Programmable Attributes, and discusses some considerations for using and sharing symbols.
The paper is available on the dev branch of my QSpice GitHub repository. This is an early preview and may change before moving to the main branch.
Hopefully, you’ll find the information useful. Please let me know if you find issues or have suggestions for improvements.
I didn’t realize Mike put in “Programmable Attribute” feature for symbols. It will definitely come in handy. In particular, I like that you can “lock in” the attribute type. The easy/old way allowed the user to change the attribute type and name which might cause problems in the DLL or be confusing at a minimum.
Experimenting with the “Programmable Attribute” feature, I noticed some things that should be clarified in the QSpice help docs.
Certain characters are mandatory such as:
the ‘<’ and ‘>’ for defining the programmable attribute.
The ‘int’ or ‘float’ are the only accepted limit-checking for MIN and MAX.
The ‘[’ and ‘]’ and ‘:’ for defining the MIN and MAX values.
The ‘(’ and ‘)’ for defining the default value in a list or MIN and MAX definition.
You can ONLY use int or float with the [MIN:MAX] values. char, double, bool … are not recognized.
If you use [MIN:MAX] or lists, you cannot use parameterized variables. In these cases, QSpice warns and may substitute with the defaulted or max value when you try to place a string variable referring to a parameter found elsewhere in the schematic. Therefore, if you’re going to use parameter substitutions in the attribute, avoid using [MIN:MAX] or lists in the symbol. Maybe, Mike can allow parameters without auto-substituting. A warning can be useful but allow the parameter name.
An example of this issue with your attribute Enable: bool Enable=<0,(1)>Enable/disable component
Placing a schematic parameter “.param en=1” and then trying to add “en” to the Enable attribute won’t let you change the “1” with “en”.