Hi,

I guess that this is KEIL trying to reduce memory footprint and increase speed, successfully but not quite conforming: The format string expects an int, but the compiler does not automatically convert the byte given into int if does not have to. The compiler does not parse the format string, so it has no clue that expanding the byte is actually required here. Appending zeros could be due to the fact that KEIL uses big endian internally.

A possible solution can be a cast to the type required:

unsigned char b = 53;
printf("%X", (unsigned int)b);

You may also prefix the type in the format string, but this in not quite conforming as well:

unsigned char b = 54;
printf("%bX", b);

See: http://www.keil.com/support/man/docs/c51/c51_printf.htm and http://www.keil.com/support/docs/62.htm

Rene

Thank you very much. That is weird and counterintuitive. I had actually tried casting the bytes as unsigned char but that had no effect. The unsigned int does the trick.

Regards,

Rob

I am using the EFM8SB2 development board with Simplicity Studio and the Keil compiler. I am working with the EFM8SB2_WakeOnUART example.

I am trying to get he UART to output arrays of bytes as hex strings using the RETARGET_PRINTF function. I can get the bytes to be sent as characters correctly, or decimal numbers. However, when I try to encode the bytes as hex, the come out with two trailing zeros. For example, the array [52, 53, 54, 55] will come out as:

With the encoding "%c " it is as you would expect: 4 5 6 7

With hex encoding "%X" it is 3400 3500 3600 3700. Each Hex pair of bytes is followed by a pair of zero characters, which I do not want. the UART is actually outputting the extra bytes.

Even stranger, with "%u " I get back 13312 13568 13824 14080  

All I really want is to be able to send arrays of bytes out the UART as hex characters as I would normally expect using the "%02X" encoding.

Any clues would be greatly appreciated.

Thanks,

Rob

OK. I've worked out how to do it in the Configurator. For the record:

Double-click on the pin assigned to SCL. Then right-click on it. Select "Skip" and the port increments up to the next pair of pins. Repeat until the pins are where you want them.

Rob

OK. I've worked out how to do it in the Configurator. For the record:

Double-click on the pin assigned to SCL. Then right-click on it. Select "Skip" and the port increments up to the next pair of pins. Repeat until the pins are where you want them.

Rob

I don't know what that means. The is no mention of "skip P0-P5" or "P0SKIP SFR" in any documents I have.

It has got more confusing. Some projects have P0.0 and P0.1 as the SMBUS pins and some have P0.6 and P0.7. The board I have, PCB5100 Rev A02, seems to have the Si7021 sensor connected to P0.6 and P0.7.

Is there any way to change the pins to which the SMBUS is assigned? There seems to be no way to do it in the configurator. I have looked in the HWCONF files generated by the configurator and there is no mention of the SMBUS pins in them. There is SMBUS timers and other stuff.

I am trying to order some boards today, which have the SMBUS sensors wired to P0.0 and P0.1. I need to know whether these are usable or if I am wasting my time and money.

Any clues would be much appreciated.

Regards,

Rob

Hi All,

I am trying to get the EFM8SB2 to wake and take a sensor reading at regular intervals, using the EFM8SB2_SleepMode_smaRTClockWake example.

I tried to add the SMBUS port to the project and it has assigned the wrong pins to the SMBUS. The are pins 32 and 32 (0.0 ad 0.1) rather than 26 and 25 (0.6 and 0.7). I have confirmed that the PCB5100 board has the sensor on pins 0.6 and 0.7.

Does anyone have a clue as to how to get the hardware configurator to assign the SMBUS port to the correct pins.

Thanks in advance,

Rob

Hi Robert,

In order to do this I believe you have to modify the value in software. Within your interrupt handler, disable RTC Alarm Events(RTC0AEN = 0), change the value in ALARMn register to the value desired, and enable RTC Alarm Events(RTC0AEN = 1)

Sincerely

Ruibin Ni

OK. I've cracked it now. I worked out how to use the SmaRTClock.c library.

Regards,

Rob

Thank you. I am a newbie to these concepts and finding the learning curve a bit of a challenge. However, it looks like I will be able to do exactly what I need to.

Regards,

Rob