For the most part of this week, I was working on the project user interface. As we are preparing for an early release, we need to optimize the code, fix the bugs, and do some code cleanup. I started this week by creating the SVG graphics for the board. After that, and until the end of the week I worked mostly on the UI part.
The board graphics
Last week the board design was finally finished. Now that we are finishing the UI, we needed to incorporate the new board design into it. The first thing I did this week, as I just mentioned, was to create the SVG pic for the new board. Speaking of which, the board design has slightly changed as well. The Ethernet jack was moved a bit away from the digital pins and the pins annotations on the silkscreen was changed also to indicate their corresponding FPGA pins.
Each pin on the SVG graphics (the board as well as all the modules) needs to have three XML attributes, two JointJS special attributes (port, and magnet) and one (mode) that we are using for validating the connections. I’ll speak in more details about the last one in the connections validation section below. All these attributes were added to the SVG board graphics inside Inkscape.
Connections Validation
The intention behind validating the connections is to limit the mistakes that the user might make, and to make his experience with the UI easier and more enjoyable. We use the “mode” XML attributes that pins have for connections validation. Previously, mode could be either input, output, inout, or NC. NC (not connected) mode is a special mode that only the FPGA pins can have. All other components pins modes can be one of the other three. Power pins, previously, did not have a mode as their “magnet” attribute was set to “false”, hence, they cannot be connected.
Now we widened the “mode” options, and added modes for different power levels (5v, 3.3v, and 2.5v), and ground. Consequently, power pins “magnet” attribute is set to “true” so they are connectable, however, their connections are validated (power and ground pins can only be connected to pins with the same mode).
This method will have some limitations, such as when the user wants to short 2 inputs together to share a common output, or if the user wants to tie an input pin to Vcc. For these cases, we added a “force connect” feature that allows the user to connect pins together regardless of their modes.
Schematics components
Clearly, we need components to show that our schematic editor works! We are creating libraries for abstract components (GPIO, UART, etc.) and complete modules (Flash memories, sensors, etc.). Components are JoinJS elements that have some additional attributes (such as “mode”). All components are created with Inkscape, although any vector graphic software can be used.
The challenge with this stage of creating components is that any change we make to the algorithm, we’ll most likely need to modify all the existing components. Hence, I tried to delay the process of creating the components until everything is settled first.
Some of the modifications to the components we made is that we added a label on the module to show its ID. Also, now components are wrapped in a “g” tag with “rotatable” class. To rotate a components, we are using a double click; the component will rotate 90 degree.
Witty Docroot
I did some code cleanup and restructured the files and folders. I used witty approot many times in my code and I did not have any problems with it. However, my experience with the docroot was limited to specifying its location “–docroot ./ “ when running the server, but I’ve never used it in the code. The problem I encountered was when I wanted to change its location to a different folder. I understood that docroot is the location that should store the files that are accessible by the user. What I didn’t understand in the beginning and caused me some problems was that the docroot is actually the deployment folder for the server, hence, all paths are relative to this folder. Let’s say you want to create a “docroot” folder, so simply create a folder, and let’s call it docroot. When you run witty server, use
–docroot docroot
and that’s it. If you want to load a css file that resides inside the docroot, you can use a function such as
this->useStyleSheet("style.css");
That’s it for now. Next week there should be some interesting things for you to see, so you don’t want to miss that. Till then, stay safe!
0 Comments