Well spent most of last Friday evening and this evening working on the firmware for the moisture sensor. By the end of Friday night (around 3am) was ready to pull all my hair out. Was seeing what I thought was my code getting stuck in some sort of reset loop. During the Google hangout session today I found out that others where seeing similar issues with the serial port. During the call I had the issue recreate again. So while I had them on the spot I did some quick debugging. What I found was if I disconnected both the TX and RX lines the messages still keep coming. Also restarted the terminal software I was using (Putty on windows 7) and the messages still kept scrolling. Only way I found to get out of this loop was to unplug the kit and let it discharge then plug it back in. In the discussions it sounds like there may well be some sort of bug in the PsoC 5 USB to serial bridge code on the kit. From my testing it looks like sometimes it get's a block of data and keeps sending it over and over (almost like some "sent" bit is not getting set). So the moral of the story is much of my code from Friday night may have been good and the looping was just due to this PsoC 5 bug. One thing I noted in my original code was I was sending a constant stream of nulls (0x00) due to a code bug. Maybe those nulls is what is messing up the PsoC5 code. Have not seen a lock up since I changed that but need to test more with streaming data before I call that one squashed.

 

So today I decided to start the day at the other end of the stack and code up a quick function to take a uint32 value and send it out the serial port in human readable text. I want to get the data logger up and running before I leave for Xmas so I can get a weeks worth of data to play with. Plan A was to use a serial port hooked to raspberry PI to log data every 15 min or so with time stamps. But with these serial port issues that may not be a real good choice. Plan B would be to just add a external USB to serial bridge cable and avoid the PsoC 5 like the plague. During the call it was mentioned there is some sample code to write to a SD card in examples 35 or 36. If I have time I may try and get that working instead as the logging target. (Long term that would be preferred anyway) On the hardware side I have plenty of SD cards but no sockets laying around at the moment. I do have some micro SD to norm SD converter I may hack into a makeshift micro SD socket.

 

On the frequency counter front I now have a pure hardware solution. The hardware once armed will capture and hold the count until rearmed. This allows firmware to go off and do variable length operations without interrupts from the frequency counter or loosing the count. Here is the block diagram of the engine:

hardware_freq_cnt.png

Basic operation starts on the left.

The controlreg is set up in pulse mode so when I write a 0x01 it pulses the arm net.

The first flip flop gets set

The second flip flop gets reset clearing the done bit

the done bit gets inverted which enables the 4 bit basiccounter1 and it starts counting pulses coming in the freq_in pin

The count from that counter feeds 3 comparators

     The first one is takes care of resets and is done at a count of 1.

          It reloads the counter (sets the count to 0).

          And it resets the first flip flop to remove the reset signal from the second.

     The second one pulses the capture pin to hold the count at count 14.

          Due to this setting being greater than 2 I count over a number of pulses which results in averaging several pulses in hardware.

     The third takes care of the stop at count 15.

          This is done by setting the second flip flop.

When the second flip flop is set the done bit gets set and the enable to the basiccounter1 is cleared so it stops.

 

At this point the counter on the right is holding the number of 24MHz pulses from time_clk that went by while freq_in pulsed 13 times.

 

Since my application does not need real world values I just left the counts raw.

In dry dirt I saw ~0x3E00 while in wet dirt I saw ~0x5200 counts.

Those reading match up to the trends I saw using a scope in a earlier post.

 

My basic program is attached. To try it connect to the USB to serial bridge at 57600 8n1 no flow control. Then press "a" to arm the counter and it will automatically return the status and count in 0x[status]  0x[count] format. Note the count is not valid until the done bit is set (bit 7 of the status) Note pin P1.0 is the freq_in pin.

 

Looks like the people's choice award poll is open here:

Vote for Your Favourite Smarter Life Project!

Wish I had more to show at this point but life tends to send you curve balls from time to time.