Timer configuration in lm32: Timer is one of the many peripherals of the lm32 cpu core, as seen the block diagram figure. The C firmware can access the timer parameters using CSR, or specifically the csr.h file. CSR ( short for Control and Status Register) is a way for lm32 firmware to connect with the existing hardware. Using this we can use data values generated in hardware directly via the C firmware.
We find that several timer parameters are stored from location 0xe0002000 onwards. There are two timing functions defined in <time.c> (or its corresponding header <time.h>). One is time_init(), used in main.c to initialize the timer. Other is elapsed(), it counts if the timer has elapsed a certain number of ticks.
While exploring the implementation of timing function, it was noted that the timer functions counts down and not up. It basically is a counter which counts down at the trigger of system clock. The timer also has an interrupt which goes off when timer_value is 0.
Timer0 functions in csr.h
|Function Name||Function task||Used in|
|timer0_load||Timer value when not enabled, this is the initial timer value when just started||time_init()|
|timer0_reload||This is the value timer reloads to when it reaches zero.||time_init(), elapsed()|
|timer0_en||Enables the down counting of timer||time_init()|
|timer0_update_value||Updates the timer value from timer block to CSR registers||elapsed()|
|timer0_value||This gives the current value of timer||elapsed()|
Block diagram of lm32 and its peripherals. link
Opsis Board: My Opsis board was supposed to be shipped on 28th May, but the Numato guys were able to ship the board by 25th of May so I received my Opsis board this week itself. Yay!
I figured I didn’t have the relevant cable to initiate the testing, so I brought a bunch of cables (HDMI, USB B type, Adapter) for the Opsis connections. Later found out that power adapter is a bit shaky and sometimes disconnects due to nearby disturbances (Need to replace!). Also arranged for a HDMI monitor through a friend, in exchange for my VGA monitor. I was told that the current firmware might not work with VGA to HDMI converters so this had to be done.
The Opsis was preloaded with color bar pattern on both the HDMI outputs. This was easily tested. Next was to figure out USB connection mode. The first thing was to plug in the USB and figure out what ID the board appears on. Refer to this link for list of USB IDs. Among the several USB modes there are two USB modes relevant here,
|Mode||Vendor ID||Product ID||Device ID||Serial No|
|HDMI2USB.tv||0x2A19||0x5442||See Device ID table||Device MAC|
I was initially getting the Older ixo-usb-jtag USB mode, this was corresponding to the Van Ooijen Technische Informatica in the list of vendor names. The dmesg output for this mode looked like this,
$ dmesg | grep -i USB [68853.645703] usb 1-4: new high-speed USB device number 35 using xhci_hcd [68853.774157] usb 1-4: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 64 [68853.774164] usb 1-4: config 1 interface 0 altsetting 0 bulk endpoint 0x2 has invalid maxpacket 64 [68853.774518] usb 1-4: New USB device found, idVendor=16c0, idProduct=06ad [68853.774523] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [68853.774527] usb 1-4: Product: USB-JTAG-IF [68853.774530] usb 1-4: Manufacturer: ixo.de [68853.774532] usb 1-4: SerialNumber: hw_opsis
I figured this happens when USB is already connected during power cycle. So I disconnected the USB during the next power cycle, waited for about 20 seconds in the OFF mode and then turned ON, followed by connecting the USB. I found the HDMI2USB.tv mode using dmesg. Something like this.
$ dmesg | grep -i USB [68680.927026] usb 1-4: new high-speed USB device number 28 using xhci_hcd [68681.055627] usb 1-4: config 1 interface 2 altsetting 0 endpoint 0x81 has an invalid bInterval 64, changing to 10 [68681.056185] usb 1-4: New USB device found, idVendor=2a19, idProduct=5442 [68681.056191] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [68681.056195] usb 1-4: Product: HDMI2USB.tv - Numato Opsis Board [68681.056198] usb 1-4: Manufacturer: TimVideos.us [68681.056200] usb 1-4: SerialNumber: ffffd88039570494 [68681.056896] uvcvideo: Found UVC 1.00 device HDMI2USB.tv - Numato Opsis Board (2a19:5442) [68681.057778] cdc_acm 1-4:1.2: ttyACM0: USB ACM device
Note the Vendor ID and Product ID as mentioned in the table and found here.
This was the mode I was supposed to be in. I had already built the bit stream for Opsis from the latest github repo, the make load-gateware was showing some errors. Tried the solution suggested by CarlFK. Still the Opsis doesn’t seem to load the bit stream. This will be continued later in the week.
Python PIL Library: One of the other tasks scheduled for this week was to explore RLE encoding for 2D images using python. So the idea is that we can store the mask data in the memory in a run length encoded form. Initially we assume that each of the mask values are binary, ie they take only 1 or 0. I have used the Python PIL library for this. The initial task was to get a black and white (and not greyscale) image which can represent the mask. First the image is converted to a grayscale image, then it is converted to black and white using a suitable threshold. This black and white image is equivalent to a mask. Using PIL library functions, I generate a list of 1’s and 0’s, which correspond to the mask data derived from the images.
This list can now be run length encoded using a suitable function. The actual run length encoding part will be done after this. Now the opposite conversion should also be possible, hence we use the list of 1’s and 0’s to generate the image back. The current code is inverting the color, this was done to verify the working of code. The next task is to figure out optimum run length encoding for the list of numbers. <Github Link>
Plans for next week:
- Get the Opsis board working
- Complete python-pil-mask generator
- Resolve the issues in heartbeat code
- C code to generate mask for wipes
- 16 bit conversion in Migen