Thursday September 6, 2007
Once again, I have to make another post for a large sum of days. I have been making a lot of progress lately which is one of the reasons I haven’t been posting. Days 30 through 35 I managed to finally write successfully to the flash. Until the end of the week I didn’t actually have evidence that I was writing because the verify portion wasn’t working fully. Part of this problem was I grabbed the code for reading from my writing code, failing to realize that the operations are so different that it was better to just write the code for reading from scratch. By writing the code based off of other code there was a lot of errors in it present that it took me a while to remove. The second part of the problem was regarding the inability to perform a continuous array read.
The second week I wrote code on the PC to work around the limitation of only being able to read a page at a time. I plan on writing code within PSoC itself to do this, as it will speed up read times, but for now the current setup is fine. I also began testing my code under various inputs and conditions, including differing file size, differing beginning write address, and other various tests. One of the tests I performed was writing a 8MB file to the data flash, which is a really slow process. To figure out where my time was being consumed at I spent some time writing a timer into my code in PSoC and timing how long each process took. The results of my timings indicated the biggest consumer of time in reading and writing was communication between the PC and the board. After talking with Chris I began work on trying to find a new way to get information to the board in a faster way. Searching the internet I found a most helpful site that became the hub of my research into USB endpoints and communication in general: (http://www.beyondlogic.org/usbnutshell/usb4.htm)
Hardware limitations prevented us from using high speed communications, so we are limited to full speed. Using this information and the site above, I found that the current endpoint type we were using (Interrupt) has limited a limited packet size of 64 bytes. The only way it seemed we could increase this was to start using the Isochronous endpoint type.
The rest of my week was then spent researching isochronous transfers. I learned that it was a very fast means of transmitting information, typically used to streaming video and audio. This sounded perfect for what we wanted, so I began searching for example code. During my search for example code I came across a blog for someone who had similar problems as myself, and they indicated that Isochronous transfers are fast, but they have a drawback. Isochronous transfers don’t have error checking, making them vulnerable to more errors than other transfers. This flaw makes isochronous transfers more desirable for streaming of audio and video but in the software we are using being one or two bits off can ruin the whole program. Using Isochronous transfers also ended up being a lot or work for what we were planning on doing with it, so in the end it we decided to scratch using isochronous endpoints.
Last week I have been optimizing my code and commenting it so as to make it more readable. With some of Chris’s help I managed to cut the write time by 25% and the verify time by 50%. I also fixed the problem with the continuous read.
The beginning of this week I began testing my code to make sure it works, and fixing errors, and yesterday I began work on the FPGA board quick start guide. I have the outline of the guide started, I am currently in the process of testing my steps, and getting ready to make screen shots and begin writing.
