Serial Killer Returns

Today I need to work on solving my serial input woes.  The problems seem to have to do with my using the "Reduced Device Drivers" option, yet, without that option, I seem to be having problems with stack overflows.  But I've maxed out the FPGA's M4Ks, so I can't make the RAM any bigger.  It is 68KB currently.  The RAM is using 557,056 M4K bits.  However, I have lots of M-RAM and M512 RAM still available.  I think what I need to do is make new RAM units that use those.

The M-RAM is 4Kx144 bits, which is 589,824 bits or 73,238 bytes or 72 KB.

There are 202 M512s, each 32x18=576 bits, for 116,352 bits, 14,544 bytes, or about 14.2 KB.
165 of the M512s are available; i.e., about 11.6 KB.

Then we have the 68KB worth of M4K blocks we are using; I think this is 120 out of the 144 M4K blocks, and the rest of the M4Ks are going to miscellaneous other things.

The M4Ks are faster than the other memory block types, but they are all plenty fast enough (420-550 MHz) considering our system clock is only 50 MHz.

So, what we could do is, say, use the M-RAM as a repository for program code - it is plenty big enough for that, since our program size is only 58 KB.  We could create say a 10 KB working memory.  And then we still have 68KB worth of M4Ks, which could be used to increase the size of the FIFOs, support all 4 input capture datapaths, and so forth.  So, we're good...

Starting work on that now.

Oops, apparently M-RAM blocks cannot be initialized (at FPGA programming time I guess); so, I guess we'll have to use the M-RAM for our working memory, rather than for the program data.  72 KB of working memory sounds just dandy.  :)

So, here is our new selection of memory modules:

• name "program_ROM", type M4K, read-only, size 64KB. (can increase back to 68KB if needed)
• name "working_memory", type M-RAM, writable, size 72KB.  Program heap can go here.
• name "extra_RAM", type M512, writable, size 10KB.  This could be used for the stack.

Since this releases some pressure, let's try upgrading the processor back to the Nios II/f.  This gives us back hardware multiply, and gives us an overall faster architecture.

Clicking "generate."  After that's done, we will have to rebuild/reconfigure the BSP to use the new memories.  Oh, but first we have to recompile in Quartus, to make sure it fits.

Updated project files to add the new SOPC modules, and remove old ones that are no longer used (old memories I experimented with).

Apparently we've got 46 too many M512 blocks to fit, probably due to the cache RAM in the Nios II/f.  Let's see, that's about 3KB+ too much memory usage.  Let's reduce the "extra_RAM" size to 6K.  That's still large enough to serve as a stack region, most likely.

Now, for some reason, it thinks it needs 2 M-RAMs.  Perhaps it can't use the full 144 bits of width, since we set the memory word size at 32 bits (16 bits could maybe have fit better, since 144 = 9x16).  If we use only 128 bits of width, that cuts the M-RAM size to 64KB.  Still plenty.  Let's try that.  Regenerated; recompiling now...  The fitter has made it through placement without errors, which looks promising...

Compilation was successful, and slow model fmax was back up to 481 MHz for some reason!  Don't look a gift horse in the mouth...

I'm getting better at using the BSP Editor; all I had to do in the "Linker Script" tab was hit "Restore Defaults..." in the top (linker regions) and bottom (linker sections) areas, then tweak the linker sections with the pulldown menu, to locate the .rodata section in the program ROM, and put the .stack section in the extra RAM.

Fixed a mangled debug flag option in the BSP settings...

OK, serial input from both sources is working now!  However, I still have an issue where the line buffer module doesn't respond right away to carriage return.  I need to modify it to treat carriage return as end-of-line, and go into a mode where it will ignore a subsequent line feed.

OK, that change is implemented now.  Perhaps it is a good time to try connecting through the Wi-Fi board to the server?

OK, got the Wi-Fi board booting and connecting to the server and opening up all its terminal windows (MAIN, AUXIO, UART).  It wasn't responding to commands properly and then I remembered I forgot the various AT+SET commands that are necessary.  I modified the command parser to recognize all the new FEDM commands (REINT, HSC_{RESTART,RESET,STOP,GO}) and tested that with UwTerminal.

Now, I've realized that the null modem adapter isn't needed when connecting from FEDM<->UwTerminal directly (since the pins can just be flipped in Quartus); but when talking to the Wi-Fi board, it is needed, because (here's the right way to think about it), the level-shifter is designed to go at the DCE end of the cable, but we're using it at the DTE end (because the FPGA board is acting as the host).

Darryl came in and write the NEG_INPUT code.  We're trying to run his changes but seem to be having stack overflows.  I'm thinking that maybe the section assignments aren't having the effect one would expect.  Oh, I think I found the problem - text section in the wrong region.

Got negative input pulses from the pulse generator.