AXE033 with I2C input, can't accept ASCII variables?

fernando_g

Senior Member
I have had an AXE033 for several years to debug my projects, but I have been out of practice related to operating it with I2C that somehow I can't make it work.

For instance, if I use the serial input to display 8 bytes separated by a space, It compiles and works just dandy:
Serout B.5,N2400, (254,128, #b0," ",#b1," ",#b2," ",#b3, 254,192, #b4," ",#b5," ",#b6," ",#b7)

However if I do the same but with the I2C input, I will get a compile error:
hi2csetup i2cmaster,$C6,i2cslow,i2cbyte
hi2cout 0,(254,128, #b0," ",#b1," ",#b2," ",#b3, 254,192, #b4," ",#b5," ",#b6," ",#b7,255)

To remove the compile error, I have to remove the ASCII symbol # prior to each variable.
hi2cout 0,(254,128,b0," ",b1," ",b2," ",b3,254,192,b4," ",b5," ",b6," ",b7,255)

Why would this happen?
 

AllyCat

Senior Member
Hi,

I don't think it's anything to do with the display, it's that the "#" formatting operator is specifically associated with SEROUT (and similar) commands. But HI2COUT is a "general purpose" data transfer function, it's not a specific "Serial" command. Similarly, you can't write DATA (#b1 , #b2 ) etc., probably because the number of bytes is not known to the compiler at the time of programming.

Also, I think the AXE033 I2C facilities are quite limited, mainly for communicating with the RTC ? To quote from page 2 of the AXE033 User Manual :

"Which Mode? (serial or i2c)

Most users will use the module in the default serial mode.

The only main reason to use it in i2c mode is if you wish to read the time/data from the DS1307 clock upgrade directly into the PICAXE chip.

In all other cases the serial mode should be used."


Cheers, Alan.
 

fernando_g

Senior Member
Thanks Alan, you are absolutely correct.

I remembered (finally!) the name of the project where I had used I2C for the display, and found that I did have to perform a BINTOASCII conversion before sending to the display.
 

fernando_g

Senior Member
Let me explain my conundrum:
I have a project with a very tight loop.

The 140 msecs that takes to send the 8 bytes separated by spaces at 2400 baud to the display, causes the display to skip or corrupt some values.

I was hoping that I2C would shorten the transmission time.

But I have seen vendors which sell faster serial displays. A 9600 baud one will shorten the transmission time.
 

AllyCat

Senior Member
Hi,

8 bytes formatted by the # could expand the string to 8 x 4 = 32 characters (i.e. 3 ASCII digits and a space for each byte) which could take more than 140ms at 2400 baud. Somewhere on my "todo" list is an upgrade for the AXE133/4 firmware, ideally using HSERIN and a circular buffer to be far more tolerant of high data rates. I did start a thread some years ago, but at the moment can't suggest more than reprogramming the (18M2) chip for 4800 baud using SETFREQ M32. However, AFAIK the AXE033 uses a pre-programmed (custom) chip, so can't be changed, but I would have expected its Assembler (?) code to be fast enough. Have you tried using HSEROUT, perhaps chopping the "main" program into ~4ms blocks, then reading the "HSEROUT Buffer Empty" SFR flag and waiting (say) 1 ms before sending the next byte? I've suggested much the same in another current thread. Note that BINTOASCII is only a (PICaxe Basic) Macro, so could be re-written, partitioned and maybe optimised to send the bytes in a suitable (spaced) format.

Alternatively, the AXE033 does appear to support I2C to a limited extent (Page 6 in the manual above). It's not clear if you must separate control and character codes , but clearly it's limited by its buffer to a maximum burst of 20 characters (including the terminator 255?) and then requires a pause of 10 ms. However, that should make it possible to send (approximately) 40 codes/characters easily within 140 ms. Post some code (or hardware details such as the PICaxe type) if you want me to cast an eye over the potential speed/timing possibilities.

Cheers, Alan.
 

fernando_g

Senior Member
Thanks for the offer, Alan.
I am using a 14M2, but might, just might be able to use some older 14M that I have lying around.

But you have given me an excellent hint: chopping the message.
The simplest implementation would be to update the top row first, go back to the main routine and then come back and update the second row.

That should do it, in case I want to stick with 2400 baud. But I have also ordered some 9600 baud serial OLED displays.
 

inglewoodpete

Senior Member
Some years ago, I found the speed limitations of of the AXE033 backpack board did not meet my requirements.

I developed 20X2-based backpack that could handle high speed serial and/or i2c. This allows an entire 16x2 LCD to be updated in under 20mS (Ie 1669 characters per second!) from a separate (PICAXE) chip. The project is documented here.
 

fernando_g

Senior Member
Pete; thanks for your contribution!
I’ll study it in detail.
Indeed OLED based displays are fantastic!
In comparison the LCD supertwist displays are so…..1990s.
 

fernando_g

Senior Member
FWIW
I also found a SALEAE Logic capture I had made on the AXE033 being driven by I2C, and a full row update transmission, including the I2C address, the initial character position and all 16 individual ASCII characters would take 15 msecs.
 

AllyCat

Senior Member
Hi,

First, on the original topic, it's interesting that the "#" serial formatting character adds absolutely NOTHING to the size of the PICaxe program (bytes reported by the Syntax Check). So there must be some dedicated Token(s) allocated, with the conversion executed entirely by the Interpreter code within the PICaxe itself, which confirms/explains why it is limited to only Serial Data transmission commands. In comparison, the BINTOASCII instruction can add more than 40 bytes to the Program size (because it uses a Macro created by the Program Editor); quite a good reason to use {H}SEROUT instead of HI2COUT. ;)

a full row update transmission, including the I2C address, the initial character position and all 16 individual ASCII characters would take 15 msecs.
That actually seems quite slow; are there any indications that the AXE033 is "Clock Stretching", or is the Host just introducing significant Pauses between each transmitted byte? I've now devised program code to receive continuous Serial Data bytes at up to at least 19200 baud (with a 32 MHz clock) using the "HSERIN" Hardware (UART) of any PICaxe M2. Currently, the most recent details are in posts #29 - 30 of this thread.

As said before, I have some (long term) plans to "Improve" the AXE133/4 concept, to give more facilities and higher speed. Most of the code/ideas have been developed and reported in various threads, which all need pulling together with a suitable "specification". However, I'm still "moving the goalposts" a little, to accommodate new(er) displays (such as the SSD1306) and perhaps include some features from the AXE033. But it will definitely need an I2C Host (Output) capability to drive various displays, so can NOT easily incorporate an I2C Slave (Input) capability, only (H)SERIN.

Cheers, Alan.
 
Top