ForPortSerialPlus issues

RS_Jim

Hi,
I have a bit of software that runs a wifi-module using full duplex serial 2 k., but when I try to use fourport serial plus, I get nothing on the wifi. I have configured the debug port to run in pst and it works but on the same initialization it does not run on the wifi.
Thanks for any help
Jim
wifi_webserver_090514 - Archive [Date 2014.09.26 Time 10.22].zipwifi_webserver_092214 - Archive [Date 2014.09.26 Time 10.21].zip

Tracy Allen

There is a bug in the dataIO4port object, in the StrInMax method. The bug is that it a 0 where it should be port.

[SIZE=1][FONT=courier new]repeat maxcount  'While maxcount not reached
    if (byte[stringptr++] := uarts.rx([COLOR=#ff0000]port[/COLOR])) == NL ' or until newLine
      quit[/FONT][/SIZE]

I don't see offhand where you have used the dio input methods in your code, but it seems to me they must be in there somewhere. And would cause the problem you described. Try that fix and let me know how it turns out.

RS_Jim

Tracy,
I don't use that routine but will correct it. I lost input in the webchk method which just uses the rxcheck routine.
I wonder what happens if I move web to port 3?
Jim

Tracy Allen

I don't see anything wrong in the web_check method. It is quite straightforward. Maybe try allotting webthread cog more stack space. Are you sure it is sticking in the web_check method, and not somewhere else in webthread?

I see you've increased the size of the port 1 buffer up to 2048 bytes for rx and 1024 for tx. That is fine , but it may be overkill, given that the target stringbuffer is only 64 bytes. Do you expect the web data to arrive in head-to-tail bursts? If so, the rxflush method calls would be flushing useful data.

Duane Degn

Tracy Allen wrote: »

Do you expect the web data to arrive in head-to-tail bursts? If so, the rxflush method calls would be flushing useful data.

I agree Tracy. I'd get rid of the repeated rxflush calls. I think these calls are probably throwing away a lot of your data.

I also agree about the stack size. I try to leave the main loop of my program running in cog#0 since (IIRC) the stack for this initial cog is all the unused memory in the hub.

I don't see a need for using "cognew" to start your "webthread" method. I think you'd be better off changing the end of your main method from:

cognew (webthread,@webstack)
  repeat {
    programDate
    waitcnt(US_001*1000000+cnt)
          }

To:

webthread

If you do need another cog to run some Spin code and this additional Spin code is more complex than the what "webthread" does, then launch "webthread" in the new cog but if your additional Spin code is less complex than "webthread" then launch this less complex code in a new cog. IMO, it's a good idea to keep the most complex Spin code running in cog #0.

I see you have "DataIO4port" listed in your objects. You don't call any methods in this object so it doesn't interfere with the program but if you were to call the start method of "DataIO4port" while still using "FullDuplexSerial4port", you'll likely encounter problems. I'm pretty sure you're only supposed to use "DataIO4port" or "FullDuplexSerial4port", not both.

Edit: It looks like I didn't understand how "DataIO4port" works. It doesn't launch a new PASM cog as I had incorrectly assumed. It looks like you are using it correctly (as far as I can tell).

RS_Jim

Duane,
I started web thread in a seperate cog because I am planning on running several objects in the prop at the same time an RTC, Barometer, web interface, wind direction and velocity, raingage, etc. I felt that running the web thread in its own cog was a good idea. I built the obj around fullduplexserial2K as you can see in my one zip file. That works just fine. The only issue I have with that version is I need to figure out how to write the html code to put the clock on its own line and update it without writing the whole page.

Increasing the stack space for webthread is something that I had not thought about. There is a line in my webcheck method that I use to test for incoming chars (may be commented out) that sends every byte that comes in to the text screen. what comes in after the command line that I parse out and use is all about the source device and the browser etc. I flush the data following the command line because it is unnecessary and I don't wish to be bothered by it. When I set it up to run on fourportserialplus, I lost all incomming data at webcheck method. Now a stack issue is something I never thought about and I certainly can increase the stack and recheck. I also can try running webthread in cog 0.I Don't know if I will be able to get back to this until Thursday, but will try. Some of the objects will probably get moved to another prop and there will be an xbee providing the coms between this unit running the web interface and the outdoor unit which will be running the data sensors. I forsee in the future needing to communicate with PST, the web port an an xbee,, thus the desireability of fourportserialplus. After I repair the bug error i DatIO4, I may use it instead of my webcheck method. I also want to change my RTC code to Toms code that he wrote for the SPI connection to the DS3234 changing it to I2C. I like his user interface and I am getting a lot of read errors from the clock chip using Kye's code for the other clock ship. Ineed to combine the clock and barometer functions onto a single I2C bus and free up some pins. I will try out the PASM version of the driver and see if I can make it work.

Thanks for looking into the code, I will try some things and report back when I have further information.
Jim

Duane Degn

Jim, It's good to know you're already aware of the things I've mentioned.

I usually start with large stacks and reduce them once things are working correctly. I once thought I have way over estimated the stack space at 100 longs only to find the cog was actually using more.

I use a program similar to the one attached to post #13 of this thread to check stack size. (Make sure and fill stack with test pattern before launching cog.)

I like to leave the stack checking method running for a while as I use the code. IMO, it's kind of fun to see the size of the stack change as different branches of a program are executed.

RS_Jim

Ok,
I edited the program and changed stack to 256, and max str length to pick up the port. Still get absolutely nothing! Need to move on and get some other things done. Will revisit 4port obj again at a later date.
Jim

Duane Degn

Jim, do you have a testable version of your program?

I you have a version I could run on my hardware, I'd be willing to try it out. I use the four port serial object everyday and I don't often have a problem with it (I never really have a problem with it, the problem is always something I did wrong).

RS_Jim

Duane,
I have both objects in the first post. I think that all the pins etc. are shown as constants. I currently have it running on a demo board.the archive in the first post doesn't reflect the increased stack size.
I would love to have you test it. The wifi module is one of the serial ones I bought from OBC. Should work with one of the new $5 wifi boards.
You should be able to comment out the rtc code and objects as they don't add anything to the serial problem.
Jim

Tracy Allen

A small thought, but I've fallen into this trap with subsequent forehead slap. Data is missing. It happens when I have a method that returns a value, working fine. Then I add other methods in between that may be in a helper object or may be a conditional methods that are supposed to pass through the original value. But I forget that all intermediate methods have to explicitly return the value.

RS_Jim

Tracy,
Good thought. However, in this case all I did was exchange 4port serial for full duplex serial. They both use the same call, "rxcheck"
This is where the system fails. I can set up a debug port and send and receive to PST from it, but the web port gets nothing using 4portserialplus.
Jim

Tracy Allen

One thing I notice is this. Both the earlier version and the more recent one using fds4p define the pins as follows:

[SIZE=1][FONT=courier new]  W_TX_PIN     = 2          '' Change I/O for connection to W TX Pin.
  W_RX_PIN     = 3          '' Change I/O for connection to W RX Pin.
  W_BAUD       = 57600      '' [/FONT][/SIZE]

The earlier program using FullDuplexSerial_2k_051414 declares the port as follows,

[SIZE=1][FONT=courier new]  web         : "FullDuplexSerial_2k_051414"
  web.start([COLOR=#ff0000]W_TX_PIN,W_RX_PIN[/COLOR],00,W_BAUD)         '' Serial web Module[/FONT][/SIZE]

whereas the new one does it with the TX and RX switched. Is that intentional?

[SIZE=1][FONT=courier new]  fds        :"FullDuplexSerial4port"
  fds.AddPort(webport,[COLOR=#ff0000]W_RX_PIN,W_TX_PIN[/COLOR],-1,-1,0,0000,w_baud)[/FONT][/SIZE]

RS_Jim

Tracy Allen wrote: »

One thing I notice is this. Both the earlier version and the more recent one using fds4p define the pins as follows:

[SIZE=1][FONT=courier new]  W_TX_PIN     = 2          '' Change I/O for connection to W TX Pin.
  W_RX_PIN     = 3          '' Change I/O for connection to W RX Pin.
  W_BAUD       = 57600      '' [/FONT][/SIZE]

The earlier program using FullDuplexSerial_2k_051414 declares the port as follows,

[SIZE=1][FONT=courier new]  web         : "FullDuplexSerial_2k_051414"
  web.start([COLOR=#ff0000]W_TX_PIN,W_RX_PIN[/COLOR],00,W_BAUD)         '' Serial web Module[/FONT][/SIZE]

whereas the new one does it with the TX and RX switched. Is that intentional?

[SIZE=1][FONT=courier new]  fds        :"FullDuplexSerial4port"
  fds.AddPort(webport,[COLOR=#ff0000]W_RX_PIN,W_TX_PIN[/COLOR],-1,-1,0,0000,w_baud)[/FONT][/SIZE]

Tracy,
Boy did that stir up a can of worms! I went back and edited the 4port version and I started getting the receive side to work and it would print out what was comming into web RXCheck. The string parseing was working correctly and the string matching works as the printer power and main power leds go on and off as commanded. BUT, there is no serial output to the web device! What is interesting, I went back and checked the origional usage for that serial connection and all of the definations have rx and tx in reverse order. Now I wonder if the full duplex serial 4 k is somehow corrupted and the start order for rx and tx are somehow reversed? I am using a little program I call VGAWifitester to communicate with the wifi module when I need to use the command mode on it and alter its setting. I use the command mode to find out which port it is on as I have had some recent problems with the wifi needing to reboot and the DHCP keeps moving ports around.
The source for the fullduplexserial4K should be part of the archive, maybe you can see a clue there.
Thanks for looking at the code.
Jim

Tracy Allen

Both serial port drivers are the same in the order that they define rxpin and txpin, from the perspective of the Propeller, receiving and transmitting.

fds2k:
Start([COLOR=#ff0000]rxpin,txpin[/COLOR],00,W_BAUD)         '' Serial web Module
fds4p:
AddPort(webport,[COLOR=#ff0000]rxpin,txpin[/COLOR],-1,-1,0,0000,w_baud)

)

In your program though, transmit and receive are defined from the perspective of the web device, W_TX_PIN to transmit from the device to the propeller, so you end up with the W_TX_PIN constant in the rxpin spot in the fds2k, and W_RX_PIN is in the txpin spot. But it got reversed when moving to the 4-port object.

It seems to me reversing both of them should have fixed it, rather than opening the can of worms(!?). The archive I'm looking at is dated 090514 and uses FullDuplexSerial_2k_051414.spin. Is that the one you mean that had been working before?

RS_Jim

Tracy,
Yes that one works. I guess I need to repair the test lead on my USB scope and measure incoming and outgoing signals.

Jim

Tracy Allen

FullDuplexSerial_2k_051414 is a simple modification of Chip's original fullDuplexSerial. The only change I see is the 2048 byte buffer. Do you have any means to visualize the serial i/o, and oscilloscope or sniffer? Even use a spare Prop pin as a sniffer. An output statement like this,
fds.Str(webport,@Page_header)
should work with either serial port object. The Str methods are virtually identical. The Prop tx pin could be locked high if some other cog (other than the serial psam) sets it high, but that would be true of either version.

RS_Jim

I re-read post 15 and you said something that finally rang a bell. The tx pin and rxpin are from the perspective of web device not the propeller.
Jim

RS_Jim

Now that I have stopped beating my head against the wall for being so.... for loosing track of tx/pin and rx pin from the different perspectives of the wifi module and the propeller, I can concentrate upon the real problem. When I was developing this with the fullduplexserial4K, I could not for some reason get anything sent out to my iPad. I happened one day to put a character send into the code stream after the string_parse routine and subsequent debug statements that printed out to the VGA display and suddenly I was getting everything to ouput to theiPad as I had hoped. After the change to fourportserialplus, I can see the incomming stream from the wifi network exactly as before. However, I have once again lost the outbound stream. The "can of worms" is really directed at my frustration and that part of the code not working AGAIN! The module works as I can load the origional code and display everything, but when I load the fourport code, I lose the output again. If I use the 4port module and set the rxpin to the same pin as the txpin for the wifi module, and create a small buffer then send it out to the debug port and reading it on the PST in a computer won't I see on my computer terminal, what is going to the wifi module. When I run the software built around the fourportserialplus obj, all is working except the transmit of the HTML commands back to the iPad. The leds go on and off as they should and a debug statment put at the end of Command will print on the vga showing it reaches the end of the command string .
Jim

CRST1

Could it be a voltage problem. I had a problem with a bluetooth module serial comm. It would work sometimes. Prop recieved ok but transmit only worked intermittantly. Finally found out the recieving end did not supply any voltage on the rx pin so the prop was trying to pull down the pin from about 2 volts. Added a pullup and comm was perfect. Check the voltage on the prop transmit pin. Just a chance it could help.

RS_Jim

CRST1 wrote: »

Could it be a voltage problem. I had a problem with a bluetooth module serial comm. It would work sometimes. Prop recieved ok but transmit only worked intermittantly. Finally found out the recieving end did not supply any voltage on the rx pin so the prop was trying to pull down the pin from about 2 volts. Added a pullup and comm was perfect. Check the voltage on the prop transmit pin. Just a chance it could help.

Just rechecked data sheet, clearly says no pullup/down on uart ports. I will go check to see if there is any difference between 4portserialplus and fullduplexserial in the state of the transmit pin at eot.
Jim

Tracy Allen

A 'scope or logic analyser could be a good assist here, to see what transpires on the port out to the iPad. I didn't understand post #19. I'm confused by the business about adding a character to make things work, and the bit about setting rx=tx on the wifi module and what that was supposed to prove, and I'm not clear about how the ipad fits into the system. I share your confusion!

In the code that I've seen, the UARTS have been set for driven operation, not open mode. The tx pin is asserted both high and low by the Propeller. So there shouldn't be need for pullups/downs. An oscilloscope can help, because you can verify that output levels are in fact what they are supposed to be and are the same between the one that works and the one that doesn't, and if there is any funny business like noise or spikes. A logic analyzer will show you the stream of data by ascii code, and the timing between characters.

RS_Jim

Tracy,
I finally got a chance to take advantage of an unused port in the fourport obj, and I used Parallax Serial Terminal to look at what the Prop was sending out to the wifi port. It was sending exactly what it was told to send, ie the HTML code that was dependent upon how the string parsed. I finally found out why I was not seeing any response on the iPad when I used fourport serial plus. In the working version, I was sending out a CR,LF pair before I sent any of the HTML code. That was missing in the fourport version. I don't know why the wifi transceiver needs that before it will send any HTML code, but it does. So now that I have wrapped my head around the fact that when the periferial says TX and RX, The TXpin is the RXpin on the prop. and the RXPin is the TXPin on the Prop. Boy I hope I never make that mistake again!

Thanks to all for all of their help and suggestions.
Jim