Trinity Core and Net

The first peripheral to send characters to the LCD from an area in memory has been completed. It's not in the complex yet but that will be the next step.

Once the LCD Char Sender is kicked off it gives a 50 ms wait then sets the Display up. It then reads in the display memory a character at a time.
Then it puts the cursor at the start of the top line and reads out the first 16 bytes.

it then sends the cursor to the start of the next line and proceeds to send the next 16 bytes.

Then if the 'go' signal is still active it waits for 50 ms and then reads the memory again in case there has been an update and displays it.

If the 'go' signal has been dropped then it waits for it to go again.

Along with other delays it cycles 19.something times a second which seems a reasonable refresh rate.

The next task is to integrate into the Dual Complex run some tests and then synth it.

Assuming this goes ok I will look at getting the graphics screen up. This will be slightly more challenging but hey.

After that must on back to the RS232 !

I have decided to add two new peripherals to the Trinity Complexes.
The first is one that will drive a 2x16 LCD. It will do the initial set up of the display and then on a timer update the display continuously. This will be possible as the 'fabric' is designed to do this as a non block matrix. It will do the carriage return for the second line. I just need to work out how to manipulate the cursor on the display. This will take up 32 bytes of memory.
The second will read out memory and display on a 128x64 matrix LCD. This will mean that a 1kB memory will need to be used. Again this will be a timed update. I will be interesting to see how it goes.
In the meantime I shall continue to investigate the Uart and see if I can get it to work as expected.

I put some debug into the Interrupt Service Routine for the UART Tx to see it would work in the FPGA. While I shouldn't be surprised I still am and have a bit of a smile on my face.

While the Uart wasn't written by me (just made to work properly and debugged !), the rest of the chain was put together by me :).

Mr. Borodin was asked for just one ping. I asked for just one bit. As can be seen this bit is about 8.64 us which gives up approx 115.7 kHz which is roughly in the ball park for 115.2 kBaud. As can be seen we are swinging the full 12v which may be an issue these days as everyone expects to see 5V so I am going to have to work on that little problem before connecting to a laptop. If anyone has some suggestions than I am open to ideas, possible some Opto Isolation or the like.

Now I have cracked the LCD driving issue, one of the Data pins was assigned to the wrong pin in the FPGA by one character.
So I now have the ability to send text to the LCD under my control. I need to work on the organisation of the display but it's an important step since I got something VERY rudimentary a long time ago.

Now to get the Serial to work as expected !!

Well it looks like I didn't fix the interrupt handling as well as I thought I had. The test code worked fine when a simple count was short, unfortunately I when I extended this count I appear to have encountered an interrupt. This meant that everything went wild as wrong return vector was being used.

This, as far as I can tell, has now been corrected.

I will now respin the design and see if it will fit. Note that this is at 97% so it's going to be tight.

in other news my FPGA board that I bought several years ago has had some kind of failure. It no longer connects to the network and allows the ability to upload a new image.

Also the USB link has also gone down, whether there is a link to both of these symptoms I haven't been able to work out.

However I have been able to get a Bit blaster to connect and load up images. Not too sure how to get them into the flash but this is a start.

I've updated the Assembler, the Vectors can now take on labels. This then means that Exceptions and Interrupts be written as blocks as normal and the assembler can construct the vector table automatically.

I've now updated the Nested Interrupt Controller and ensured that the Processor Level is updated correctly.

The Processor Level now takes the Priority Level of the Interrupt plus 1. Also the Processor Level is now 5 bits rather than 4 bits so that the overflow stops any further Interrupts one a 0xF priority level interrupt has been hit.

Exceptions can still happen how but once the Processor Level hits 15 no more interrupts can be processed, the software has to deal with them to get the level down so it can accept more. The interrupts aren't lost just not acted upon.

Next to put the design back onto the server and see if it can be built again.

One thing I need to do is to update the Assembler so that the Vector table can take the labels as well. It will make things a lot easier.

The Uart I had found has now been tested in simulation to see if it can transmit at 115200 Baud. It looks like it can so the fixes I put in appear to have worked.

As the testbench connects the tx to the rx a loopback is formed.
On checking the data coming back it appears that the same value is received back.

It's looking like its the correct speed as well, a 4.67% error over the entire 10 bits. Also the count is reset again at the start of the transmission so it should be good.

This shows the result

Open Source is excellent stuff, I would highly recommend looking at the FOSSI organisation which is dedicated to Open Source Hardware.
Unfortunately some Open Source shall we say leaves something to be desired.
Like a standard reset scheme, synchronous or asynchronous. It's best NOT to mix the two schemes unless you REALLY HAVE TO.

I am in the middle of debugging the Uart I got hold of. So far I've seen a mix of resets and registers not reset.
I sincerely hope that there are no latches in there !!