Thor's Day

Still having trouble getting comfortable & getting to sleep at night.  The back pain is a little better since I started sleeping on the other side of the bed, as well as taking 2 aspirin & 2 Tylenol before bed, but now the breathing machine is bothering me.  Had to sleep without it last night.  Actually felt pretty good in the morning though, and was able to get up earlier than usual.

On tap for today:

1. Test the flyover mode which I implemented last night.  If it works, make it the default mode.
2. Test together:  Darrel's ICDP run/pause, new faster baud rate, flow control, flyover.  If it all works, see how fast a pulse rate I can get through the wireless; if not, debug.

Placed a homemade bridge on jumper J50, which connects the UART_DTR (data terminal ready) output to ground.  This is there to ensure that the Wi-Fi board's autorun script is automatically invoked.  The only other DTE (data terminal equipment, host side) outputs from the DE9 port are TxD and RTS, and those are now controlled by the uart_0 device.

Let's now install the new script with flyover support on the WiFi board.

Starting COSMICi server app (C:\Users\Mike\Documents\My Dropbox\Server Code\COSMICi_server.py).

Starting UWTerminal (C:\EZURiO\UwTerminal.exe) at 115,200 baud, with CTS/RTS handshaking on.

Powering up Wi-Fi board... Trying basic commands...

<ENTER> --> 00
at<ENTER> --> 00
at+dir<ENTER> -->

06 factory.def.pc
06 nodeid.txt
06 strings.txt
06 autorun

That all is as expected.  Now, let's wipe the board and load the new script...

at & f * -->
01 E03C MEDIA_CORRUPT    (this is normal)

Power-cycle board.

at+dir now gives just factory.def.pc

Increase stack sizes:

at+set 42="128"
at+set 40="1000"
at+set 41="1000"

Re-downloaded data files nodeid.txt, strings.txt...  Done; they are now in the dir.

Cross-compile and load autorun.uws... Cross-compile succeeded, now loading...  Hope there's enough memory!  Looks like it.  at+dir now shows autorun.

Unchecking DTR checkbox to enable autorun.  Hitting reset button...

The Main, Auxio, and UART connection windows popped up as expected.  WIFI_READY appears in the UwTerminal.  The help menu in the AUXIO window shows the new flyover command.

Typing "loglevel 1" in AUXIO window to turn on INFO messages, so I can see what's happening in more detail when I run the "flyover" command.  That worked.

Now typing "flyover" command...  It thinks it was successful.  Let's test.  First, output:  Type "hello world" in the UART-bridge window and hit enter.  It appeared in the UWterminal.  Next, input:  Type "cowabunga dude" in the UWTerminal window (with LineMode off) and hit ctrl-j.   It appeared in the UART-bridge window.  Great!

Now, on the WiFi board, I'm going to switch off input from the level-shifter, by tying pin 2 of J10 to pins 1 and 2 of JP2.

Now let's power everything up so we can test the FEDM code at the new faster baud rate, and with CTS/RTS.  Set the power supply to 6V, and turned it on.  Current at 1.928A.

Setting up the chiller; setting 2nd power supply to 5V, connected in parallel to fan & Peltier cooler; current is about 1.2A.

Burning the .sof file for the current project version (New_with_Nios_trim).  That is at 100%; no output on the UART bridge yet.

Running a nios2-terminal to see if there is any buffered output on the JTAG serial port.  Nope.  (I wonder why that stopped working a while back?)

OK, let's run within the IDE.  Refreshing JTAG connection, running.  OK, got FEDM_STARTING and FEDM_READY messages in the UART-bridge server window.  Let's now try sending some pulses.

Turning on function generator, recalling setup 1, which is a 2.6V negative pulse, 1 Hz frequency, 10 us pulse width 20ns leading edge time and 60 ns trailing edge time.  Turning on scope to view input pulses and data being pumped out of ICDP.

Oops, I realized there is not yet code in main to unpause the ICDP.  Added that, re-running.

Typing "HSC_STOP" and "HSC_RESET" commands in the Nios terminal window so I can turn on the pulse generator safely.

Turning on pulse generator.  See pulses on scope.

Typing "HSC_GO".  Now seeing pulses.  I forgot to take away the "+" signs.  Doing that now...  Oops, fixed the leading-edge ones but not the trailing-edge ones!  Correcting...

OK, that's better... Now, let's try increasing the pulse rate.

Tried 1 Hz thru 64 Hz at steps of 2x.  1 Hz through 32 Hz worked fine if jerkily.  Flow control seems to be working; the serial errors are far fewer!  64 Hz resulted in a buffer full warning (not unexpected), and then STDOUT hung and the application stopped.

Oh, I need to fix the pulse buffer module which I figured out the other day is not actually thread-safe.  However, I figured out how to make it thread-safe:  Keep separate n_pulses_written and n_pulses_read variables, each updated only by its respective "thread" (really just execution context), and differentiate between buffer full and empty conditions based on the difference between these.  Let me make that change now.

OK, that change is made.  Trying to run it...  Hm, firmware didn't start up properly... Devices could be hosed... Let's try reloading the gelware...  OK, that helped.

Tried 50 Hz; this eventually led to a bunch of full buffer warnings.  That's more like it...  Changed code to continue draining pulses from datapath even if they have to be discarded.  I'm torn about whether it's better to do that or just reset the datapath.

Had a run that successfully streamed data at 100 Hz (pulses per second).  Tried 150 Hz; this led to a buffer-full event.  This seems to be crashing STDIO; possibly it's that the re-entrant output routines are not really safe to use without MicroC/OS-II.  I should try it again at a higher reporting level to suppress the STDOUT output, and see if at least we get the lost-pulse reports on the wireless link - that's more important anyway.

Late in the day Ray and I did a successful test with a real PMT. Video follows: