Getting it Right!
Sadly I’ve just realized that my internship is getting closer to the end. Cannot really describe how I feel… Just mixed feelings. But what I really know is that this period has really enriched my life in all aspects.
lol, Stop being so dramatic and get back to the work girl 3:) !
This week I continued working on the integration of the project. Last week if you still remember I was stuck in the driver and I/O addresses. My blog was really good enough to describe the confusion that I had in my mind therefore, I got a long message from Dr. Shawn B-) . Apparently a considerable change is needed to the current drivers classes in order to be able to receive the addresses and then process them. Any way… In the following two paragraphs I’ll try to describe the two methods I was experimenting in the last week regarding passing the I/O addresses to driver classes.
Method 1: Passing the addresses as macros
In this method a set of defined macros that contained dummy addresses will be set first and then the user will choose from these macros and pass them as IDs. Later this macros will be replaced by the true addresses values based on the location of the I/O in the Verilog top module.
This methods will work fine unless the following:
– The ID is not the address: In the algorithm I followed to generate the Verilog top module the addresses of the I/O keep changing based on the total number of the I/Os declared in the user code. Having a constant ID is very important for the schematic editor. Since the schematic editor only knows if a new object is defined or an old one is deleted based on the provided ID list . Meaning that it only recognizes the objects based on their IDs.
One way to work around this problem is by maybe providing the schematic editor with both the old and new addresses every time and if they are not the same replace the old ID with the new one.
The advantage of this method as described by Dr.Shawn is that it’s more user friendly as the user will pass a whole word (eg: GPIO0) as ID instead of number which would make it easier for him/her to remember if he has used the same address before or not.
Method 2: Look-up table
The second proposed method was to generate a two dimensional array that contains both the IDs (as number) and the addresses. This global matrix will be then access by the driver functions in order to read the address that is equivalent to the I/O ID. In each I/O class constructor a function (eg: getAddress) that takes an ID and returns the address will be called. This method seems to be working quite nice but the problem of unfriendliness of passing the ID as a number is still there.
Finally we agreed to somehow mix between the two methods , we will still continue with the latest method but instead of giving the user the ultimate freedom to choose any number he wants . a set of pre-defined macros that contain the ID (number) will be included and the user will choose from these macros to pass the ID.
This method will guarantee that the user will pass a positive ID every time plus it will maintain the user friendliness of passing a word instead of number.
C++ binary file:
After getting the driver and I/O addresses issue solved, the C++ file is now ready to be compiled. The file was sent to other machine for compilation. Everything so far was going great but the problem occurs when the file -executable file – got back on the http response. When I tried to run or simply perform any operation on the file like dumping it to text file . I got a segmentation error. Seems like my ELF file was corrupted!!! ..hhh and as every time I got the blame on the http. Since the file worked so fine before it got sent. I thought that something might happen in the middle that caused my ELF file to get corrupted. Any way eventually I found the stupid bug. It was on my way of receiving and storing the binary data in the file. Apparently, the binary file should be treated differently from normal text file.
Like when you open the file you have to open it with flag ios::binary
In order for it to open for the binary mode. Moreover the normal extraction and insertion operation (<< or >>) use is not efficient here . The binary mode has its own function (read and write ) to do these tasks. Check this link for more information
Setting the breakpoint:
As a subtask I had to add a breakpoint functionality to my editor. This feature is needed for my colleague KY to continue his work with the simulator. This task was pretty easy since the codemirror library is rich with so many helpful functions. I managed to get it done and worked yet I left with small bug that has to be solved. The breakpoint cannot be put if the line has another marker on it such as (a gutter marker). ..Hmmm will try to figure it out this week.
Well, Yeah that is all for this week. 😀 stay safe