CAI_Support
Senior Member
There is a ram copy of ipaddr, but if user alternate IP address, it must stored into eeprom, then restart the tcp stack by reloading from eeprom.
WC32: is there a variable containing IP address obtained by DHCP?
- Thread starter tparvais
- Start date
CAI_Support
Senior Member
@Thomas,
We have implemented IPADDR and IPGATE readable value in the WC32 firmware. If you like to test out this feature, please send us a private email, so that we can send you the firmware to test. They are readable 32 bit number, you can use Ross suggested method to display them.
We have implemented IPADDR and IPGATE readable value in the WC32 firmware. If you like to test out this feature, please send us a private email, so that we can send you the firmware to test. They are readable 32 bit number, you can use Ross suggested method to display them.
CAI_Support
Senior Member
We have implemented this support so that WC32 print1 and print2 can directly print out IPADDR and IPGATE. The firmware is in beta testing. If anyone interested, please let us know.
CAI_Support
Senior Member
Ross, we posted another version has correct endings for them to be displayed. Please let us know if there is any problem with that one. Thanks!
CAI_Support said:
That is now working fine, Wayne.
For anyone else who gets the new firmware and wants to try it - a really simple version is:
START
PRINT1 "IP ADDRESS"
PRINT2 IPADDR
DELAY 2000
PRINT1 "IP GATEWAY"
PRINT2 IPGATE
DELAY 2000
END
Looking forward to a %0F and/or %xD format string, Wayne!
CAI_Support
Senior Member
Okay, Ross. Please try it now to see if SPRINTF could do the formatting you wanted.
I think you could even do "test %d now" format
I think you could even do "test %d now" format
CAI_Support said:
First time after connecting, erase/reflash, "Run Application", Disconnect.... the WC32 was unresponsive over the network, green LED on WC32 flashing fast.
Could not reconnect. Powered-down the board, re-applied power, repeated the process and it worked the second time.
Reloaded GUI and API
sprintf is now broken though.
sprintf printbuf1 "%1F" ramb10, then printing printbuf1, replaces "%1F" with just "F"
%d, %D, %1d, %1D all produce just the letter D on the display without converting the value of the variable.
On the status page, Temperature sensors 17-24 and 25-32 still have no column headings.
CAI_Support
Senior Member
When green LED flashing fast, the is the indication that the board still in firmware update mode. It might be the "run application" click lost somehow over the network.
I saw the temp sensor heading in the main index.htm page. When you say status page, do you mean that page or status.xml?
I saw the temp sensor heading in the main index.htm page. When you say status page, do you mean that page or status.xml?
CAI_Support
Senior Member
Good catch, we will fix it
CAI_Support
Senior Member
We found the formatting problem was caused by stock compiler disabled floating point number handling, since chip does not support that. So our engineer has to code all the floating point number functions in c code.... that means only "%xF" and "%D" would be supported for now.
That's reasonable. The original version was a pseudo-floating-point - artificially moving the decimal point in an integer number - which in this application is perfectly fine.
WE know that we're dealing with a number that's shifted (x) digits, like "655" = "65.5" degrees.
Please let me know when you want me to pull new firmware and re-test.
R.
WE know that we're dealing with a number that's shifted (x) digits, like "655" = "65.5" degrees.
Please let me know when you want me to pull new firmware and re-test.
R.
CAI_Support
Senior Member
Ross, please try download again. This version supports also "%d", there is no zero padding for this format. Please also update GUI and API for the temp sensor header numbers
Similar threads
- Question