ESP8266 Community Forum

I use the RTOS SDK and note that the system sends debug data to the serial port. Is there any way to turn this off?
I want to hook a gsm serial modem to the port so I can see that the debug info is going to interfere.

I am using v1.0 and tried to upgrade to v1.1 but no luck there... The app is real heavy on resources (8k stack single task) and crashes with the new features added in v1.1 Not a huge issue as I can keep using v1.0

I have DHT22, 5 DS18B20. tilt switches and a microphone capturing 4k of a to d data. I few fet switches to save battery/parasite power for DS sensors (strong pullup) and a bi coloured led (The unit goes to sleep and the led is only on while active, 11 seconds). This is unit type one. Unit type two has gsm modem hooked to esp-12/07 acting as an access point (To be built next) that takes info from multiple unit ones. I cant say what the application is as it is commercially sensitive.

Man it is real hard to develop with the chip with so little information available. Has anyone actually had any response to queries to the maker?

TIA Peter Bennett Bencom Ltd

Howdy Peter,
Have a look at the SDK documentation for the ESP8266. There is a function called system_set_os_print(). Apparently if you call it with 0 ... as in:

system_set_os_print(0)

That will disable debugging. You can also switch debugging to UART1 if you still need debugging while using UART0.

There is actually quite a bit of docs but it is scattered around and buried in many of the excellent forum posts.

Neil

kolban wrote:Howdy Peter,
Have a look at the SDK documentation for the ESP8266. There is a function called system_set_os_print(). Apparently if you call it with 0 ... as in:

system_set_os_print(0)

That will disable debugging. You can also switch debugging to UART1 if you still need debugging while using UART0.

There is actually quite a bit of docs but it is scattered around and buried in many of the excellent forum posts.

Neil

No such function in the rtos sdk v1.0 or v1.1. Swapping the port stops all output as one would expect but still prints lots of garbage when you wake the chip from deep sleep or power on reset. Although I probably will not be sending the chip into deep sleep for the type two unit which will stay on to provide the access point to the type one units which do go to sleep for up to 72 minutes. The type one units do not use the serial port (Debug while developing only). This garbage output may be set in stone as it is probably an artefact of the processor init. I guess the major issue can only be answered by the makers engineers. This system must be run on batteries and solar power hence all sensors are switched off when inactive (Both n & p fets) N fets for power to DHT sensor & mic and p fet for parasite power to the ds sensors. Unit type two has not actually been built yet but I can see a problem arising as generally sending garbage to a gsm serial modem is most likely going to cause undesired effects. I have sent an email to the maker but not hopeful for a reply as the last email I sent did not get a reply.

In all my years and I have been programming for 35 years I have never seen a serial device that outputs garbage as a default on startup. The maker needs to address these issues before moving forward otherwise competitors will get my dollar. I am hoping to take the system to a global vertical market.

By the way the rtos sdk has no documentation that I know of... I work be greping the header files to find functions I need. I use rtos due to the fact I also use it on STM32V arm boards. I have ported the sensor drivers from other software for the sensors and modified it as I am sure some hobby enthusiasts really do not understand data sheets. Both DHT and DS drivers that I started with failed on a regular basis. My drivers do not fail pretty much and do full crc checking. Any errors are sent to a web server and recorded in a db (For the day one does go faulty). The DHT sensor fails crc every once in a while but one retry gets it. I also use the same sensors on the MC9S08 chip where I wrote my own drivers from data sheet info. The sensors on the MC9S08 weather station (nRF24 coms) never fail.

Anyway we are getting off topic. Thanks for your response Neil.

At worst I am sure I can make a hardware solution to cut off the serial data until the start up garbage is finished.
The garbage appears on startup and the debug info when starting up the access point/connecting to an access point.
Once those routines run the issue disappears. NRZ serial ports can be disabled by holding them at VCC (3.3v).

At about $22NZD all up for the components I guess a few cents for two p chan fets does not add much to the overall cost and one gpio to drive them which I still have a couple spare is a small price to pay.

But it would be nice if the chip had a clean serial interface.