net server lcd display

geoff07

Senior Member
#1
I'm working on a project that uses a net server to provide the web interface, talking to a PIC18F45K22 using native C in an AXE022 board (in fact it is a 40x2 that I have overwritten). I'm only doing it this way because I need floating-point in such volumes (celestial mechanics calculations) that a 40X2 with the FPU or software emulation aren't really options (at least at my skill level). I wouldn't encourage anyone else to do this unless you really really have to! Although I am learning a lot I now really appreciate the work that Picaxe Basic does behind the scenes to drive the PIC. The 496-page PIC datasheet has become almost bed-time reading, sadly.

However, I have a problem and some information would be very helpful, if anyone has it:

- what controls the two right-most characters on the bottom line of the net server lcd? Normally they display "1_" (_=space). I can't find any reference in the net server documentation.

- what would cause these character positions to display a black rectangle? This would be an FF character. Whatever it is, causes the net server to need a reboot.

I'm assuming that somehow I am overwriting something, but it seems to be a random occurrence and my code does protect against out-of-range writes.

Alternatively, it might perhaps be an i2c issue that I haven't allowed for. However, writing to the lcd from the PIC, and updating the data that can be accessed via the server web page all seems to work fine, until the problem occurs, and the RTS/CTS handshake should prevent clashes. My test program writes and rewrites the lcd once a second and can plod along for ages until the PNS halts after an indeterminate interval.

I couldn't get the MSSP module to work in i2c mode so for speed and simplicity I coded the dialogue directly using TRIS to control SDA and SCL as I don't need the full multi-master monty that the MSSP module provides. This might be part of the problem but the signals work and look good on the 'scope so I don't really believe that it is.

It is a bit tricky to diagnose given that the PNS is a black-box but any help gratefully received.

[edit] I should add that I have put pull-ups on the PNS pins P6, P5, P3, P2, P1, P0, and J1 is on, thus providing a pull-up to P7. P4 is the led output so does not require a pull-up. The PIC itself may not have pull-ups on every input (the hardware is still in development) but interrupts are not enabled and there is no reason I am aware of that the state of unused inputs on that chip should cause the PNS to lock up, given that the only link is via RTS/CTS and i2c which, even if they were misbehaving (which I doubt) would not lock up the PNS.
 
Last edited:

geoff07

Senior Member
#2
Hmm, no replies. Well I know the PNS is a minority interest, but I had hopes!

However, after a lot of delving, including into Microchip software, I may have found the answer, so this is for the record and anyone else that does something like this.

First, to answer my own question, what are the two character positions for, well according to my analysis of the Microchip software that accompanies AN833 they show the number of IP address lease renewals since the last reboot. Not exactly useful to me but perhaps to someone. More relevant, there was no clue as to why these positions should appear as FF characters. I am assuming that the PNS is a modified clone of the Microchip picdem.net board and that the TCP/IP stack source code that they provide is the basis for the PNS firmware. However, this was not much help in solving the problem.

So to work. I exhaustively eliminated all effects due to floating inputs, cabling and induced voltages. This by ensuring that all the PNS inputs had pull-ups, that all other connections were low impedance and any extraneous cables (scope probes, programming cable, etc) were removed. The problems continued. Running the system with a null program in the PIC "while(1);" and also with the ribbon cable disconnected did not exhibit the problem. So it had to be my software. So I then constructed the original executable step by step (just the RTS/CTS and i2c transaction). Get and release of RTS/CTS alone in a loop did not cause failure. The i2c transactions themselves worked, looked good on the scope and seemed to be fine. Eventually, the fix seems to have been to insert a small delay between release of CTS and the next get CTS. This delay was only 100uS and it may well be effective even if much shorter.

So too-close release CTS and assert RTS is not handled by the PNS very well. The underlying problem may be the time between the i2c_stop and i2c_start steps. With a Picaxe chip that isn't a concern because of the instruction timing that likely inserts delays without them needing to be explicit. When using C natively on the same chip (16MHz resonator), timings are much faster and the problem arises. I have coded the software so that each byte to and from the PNS is a complete transaction (get CTS/start/writes and acks/stop/release/extra delay). This is simple to use and does not hog the bus. As I'm not using the built-in MSSP i2c peripheral I don't get the full 100kHz speed, but I do get about a 40kHz clock so that works for me.

I will say again that I'm only doing this because we don't have floating point variables. In fact the core celestial mechanics calcs I am using were originally written, in Basic with floating-point, for the outstanding BBC micro some 22 years ago! However it has so far been most educational. If anyone feels moved to complain about the Picaxe instruction times, they should see what has to happen behind the scenes to do even simple things. If Basic will do the job for you, use it!
 
Top