Using JSON and Internal Modules

One issue that I worked on this week was to change the objectList file format. The objectList file contains the list of the object the user has defined. Previously, we used a very simple file structure for the objectList file. Basically, evey component was written in one line and we simply then reads the file line by line. Although it works, it is better to use one of the existing file formats instead of creating our own.

The issue was to change the objectList file to use JSON format. Hence, instead of reading the file line by line and extracting the variables ourselves, we can use Witty parser which will be more reliable. The first task was Sumia’s part as she is the one who creates it. Once she finished this task, it was my time to change my function. The function that I needed to modify is generateJSON. By far, this is the most complicated function in my whole code. The complexity of this function is due to that it actually operates on 3 JSON files at once. It then basically loops through arrays to determines which components should be added and which should be removed. It took quite a while to successfully change the function to use Witty parser and complete the rest of the function. Once that finished, I sensed the need for detailed documentation for this function, so that whoever will take over this project, will have a clue on what’s going on. I added documentation to the code explaining the algorithm, and modified it slightly.

One more thing I worked on is creating the JointJS modules for the SDCard, ADC, and Ethernet. These components differ than the rest of the component in that they are internal in the board. Therefor, they can only be instantiated once, and the user doesn’t need to connect them to create the UCF file. Here however I had many choices. Since the user does not connect these components to create the UCF file, then I could ignore them when instantiating new components. Hence, I will need to check evey component when creating it so that if it is internal, it will be ignored. I don’t like this way however as it needs hard coding the names of the components into the code to perform this check. Another option is to instantiate a component with and empty markup property. Hence, the component will be created, however the user will not be able to see it on the board.

A third option to deal with these component is to instantiate them, and their markup property is not empty (so it will appear on the editor), however, I wanted them to be “stuck” on the board. Hence, when the board moves, they will move as well, and they cannot move without the board. This can be implemented so that when the user defines an SD card in the code, an SD card would appear on the board. Although this looks like a simple feature, I spent a lot of time trying to figure out how to do something like this. I had some success but it did not work as expected.

For now, there are JointJS modules with an empty markup for the internal components.

Last thing I worked on this week is to change the wires colors dynamically. This will be needed when integrating the schematic editor with the simulator. After a bit of research, it appeared that changing the wires colors is very easy (as it should be). Now the colors of the wires can be changed, however, I stoped working on this feature until the simulator is ready for integration.

That’s it for this week. Till next time.

You may also like...

Leave a Reply