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.
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: