Bugs, bugs, and more bugs! I think that summarizes the past week! We haven’t introduced much features to the project, but rather we spent the week improving the code, and solving the problems that arise. I basically worked on creating the components for the schematic editor, moving the schematic files from Wt’s app root to the server temporary directory, and doing some enhancements here and there.
Schematic components
If you remember my post from last week, it had a section with the same name. I continued creating the components SVG graphics for the schematics components. Those include a generic master two wire interface Mtwi, 9 degree of freedom sensor stick, Bluetooth mate module, SPI flash memory, and finally GPIO. It was fairly easy creating the components, except for the GPIO!
Let me explain first how components appear on the schematic editor from the C++ code. When the user creates an object in the code, an “objectList” file is generated that contains the list of the objects the user declared. The info in this files is the type of the components, its namespace, and the parameters passed to the class template. The first parameter is always the component ID. Then, in the schematic editor back end, this file is parsed to extract the information. For most components, it is enough to read the type, namespace and ID only, as the rest of the parameters are important for the verilog modules, and they don’t affect the components graphics (such as the memory speed). Then a list containing the components that are to be created is sent to the editor, that will load their JavaScript definition from the server, and instantiate them.
Here’s why the GPIO is different. When created, it requires two parameters, ID, and length. The length, as opposed to other components parameters, DOES change the component SVG. A 2-pin GPIO will have less pins to be connected than an 8-pin one! Hence, the component “markup” property (that contains the SVG of the component) should be generated dynamically when a GPIO is created. This made me modify almost every function that is called in the process of creating components! There are still some minor bugs, however that I’ll be working on next week.
Using the server temporary folder
There are two files that are generated in order for the editor to get updated (when creating new components, and/or removing old ones); that are “objectList”, and “generated.json”. Well, I don’t create the former, but I need to read it, and then create the latter and send it to the browser. These files are overwritten every time components are added or removed, hence, they are not important to stay saved when the user finishes the project. It was one of our tasks this week to move all these intermediate files from Wt’s AppRoot to the server temporary directory.
Other modifications
Whenever some part of the code changes, new problems arise and some other changes will need to be made to other parts (now it sounds like a vicious cycle)! Creating the GPIO introduced some problems when validating the connections, as its pins do not match any of the digital port types we had (input, output, and inout). There are “literally” general purpose input/output pins. Eventually, these pins were assigned the type “NC” (not connected) similar to the board not connected pins, and thus, they can be connected to any digital pin (Now come think of it, the name “NC” does not seem appropriate now. I think I’ll change it to reflect what these pins are actually are, a general digital pins, whether they are GPIO pins or not-connected board pins). Also, validating connections were not working for the analog pins. Now, there are validated.
The wires used to connect components have also been modified slightly. Their color, width, arrowhead markers, and other parameters have been changed. Hopefully, these changes will enhance the user experience.
Oh, it’s Eid, (or Hari Raya as called here) so, happy Eid, and
كل عام وأنتم بألف بخير
(that’s Arabic for Every year and you are all fine a thousand times fold 🙂 )
0 Comments