Tue., Feb. 14th

Happy Valentine's Day!

I just submitted a low-priority work order to the EIT TMS (task number TMS-24697) to see if they will open up off-campus access to our license server ports on COSMICi (IP 168.223.31.9:1800 & :27000) so that students can use Quartus and PADS from off-campus.  Since the EIT folks were so efficient at helping us yesterday, I thought this might be worth a try...

Darryl is here reading some more about LogicLock.  Also, Aarmondas is here with his laptop and I helped him get connected to the wireless access point (& to the Internet through it), to our local license server, and our shared Q:\ drive.  So they might be able to work together using Q:\, or maybe just in a new folder on Dropbox.

Today's to-do list:

• [/] Test new HOST command for passing arbitrary command lines thru Wi-Fi script to the FPGA board. Add some error-checking to check for the case where the STDOUT->UART bridge lane is not connected (or where the connection is in binary mode).

Let's see; looking at stdiomodes.uwi to see how to handle the different modes.

• In UNSET_MODE, we should assume that text output to UART is OK.
• In TEXT_MODE, it is definitely OK.
• In BIN_MODE, it is not OK because in this mode, the FPGA board is expecting to receive binary-format messages only (and we have not implemented these anywhere yet).  So text command lines aren't kosher.
• In MIXED_MODE, mixed text and binary commands are OK, so it is OK.
• In DISC_MODE, the UART is disconnected and so we should not try to send anything to STDOUT (or else the script may hang).
• In TREF_MODE (the usual mode for us), our output goes to the UART and we can send stuff to it. (No distinction made yet between text & binary output in this mode.)
• In BOOT_MODE (the mode we boot up in), we can send formal command lines for the host (but not arbitrary text) to STDOUT.

So basically, we can send text command lines out to STDOUT as long as we're not in BIN_MODE or DISC_MODE.

OK, that error-check is implemented.  However, I then commented it back out because we are having problems fitting the script within the 64K limit.  Moved some string literals out to strings.txt to make room.  Now testing...

After turning debugging on, I realized that I accidentally registered the HOST command in the wrong category - it is strictly a script command, not a command for the host to interpret directly.  Recompiling/reburning script...

OK, that's fixed; now turning debugging off and putting that error check back in.  Tested the error check by switching into UART mode (using the bridge-uart command) before sending the HOST command, but oops, the WiFi script lost track of the Stdio mode.  Fix that.  Recompiling/reburning script again...  OK, that issue is fixed now.

Updated the script version number & added the HOST command to the "help" menu.  Tested that as well.  (Every time I make a change now, re-testing the script is essential, because each time I add new lines of code, I have to move more string literals out to strings.txt to make room for them, and if I do that wrong, it could screw up other things.)