The program jumps to the error routine, for both the WaitforShutup routine and the “hello world” output. Without the error handler, the program seems to hang on that statement.
Any suggestions?
Very frustrating as an easy and reliable I2C interface in key to using many new sensors.
I have that board, it’s great. If you haven’t already, you do need to solder on two 10k (or two 4.8k if you want fast 400kb+ data rates) pullup resistors, though, otherwise it won’t work.
The I2C commands require ACKs from the device it is trying to talk to. If no timeout is specified it will wait indefinitely for it. First I’d try setting bit0 of the your lcdaddr(bit0 is used to determine if the address data is 8bits or 16bits). I don’t remember off the top of my head which is 8bits and which is 16bits. Once you’ve got it set to output 8bits for the address, if your device doesn’t have an address part to it’s command syntax then your need to put the first command in the i2c commands address argument.
Detailed explanation:
The i2c commands send the command byte(eg your lcdaddr arg) with the correct bit0 setting depending on whether you are using i2cin or out(eg your lcdaddr bit0 is overwritten before being sent out as the correct read or write bit). Then the address data is sent(8bits or 16bits depending on bit 0 of your command byte), and then either trys to receive or send data bytes(again depending on which command you are using).
So it goes like so(assuming 8bit addressing mode)
cmdbyte,addressbyte,databytes…
If your i2c device doesn’t have an address argument it is expecting:
cmdbyte,databytes…
So to produce this kind of output you have to put the first databyte in the address argument of the i2c command(only in those cases where the device isn’t expecting any address data).
the routine still jumps to the error label. I don’t have a 'scope but a logic probe (with a pulse indicator) never see the clock line go low. The data line does go low for a brief moment.
PS- I do have a 3.8k resistor pulling the clock and data lines high.
Good stuff. It caught me the first time I used it…
The docs aren’t all that clear on the display and the sample code just sends single characters at a time. To me it looks like FEh puts it into a command mode, otherwise everything is considered data.
Perhaps try a non-null control byte? Something like:
i2cout sdapin, sclpin, i2cerror, lcdaddr, ‘h’, “ello world”]
(I can’t recall if single characters use ’ or " as delimiters)
I’ve used this display with an SPI interface and it’s as simple as sending a string of data to display. The 0xFE + cmd is used to send command like clear screen, home, etc.
Has anyone had success using ICOUT with another device (devantech speech board, e.g.)
interesting contradiction between the mindsensors user manual and their i2c example code on the device address; the manual says default 0xe0 and the sample IIC.nqc puts IIC_ADD at 0xa0. can you access the address setting via setup and make certain it is really set to 0xe0?
Yes. 0xE0 is the control byte(with bit0 set to 0 for an 8bit address argument, note the manual may be wrong on this so you may want to try a bit0 = 1 setting as well).
3.8k is possibly too hard a pullup. I would recommend a 10k. Also what I/O lines are you using? If it’s P6 or P7 on the AtomPro those only swing 0 to 3.3v which may cause problems.
You can also try leaving ou tthe address argument in the i2c commands. This should cause it to not send any eeprom style address after the control byte and go straight to sending the data bytes.
Yes, I had the SP03 working with the AtomPro. This is cropped from a larger program - the only issue I had was the i2cin on waitforshutup (stat should have been 0, but the MSB got set):
[code]
SD Con P8 ’ Define Clk pin
SCL Con P9 ’ Define Clk pin
SP03 Con 0xC4 ’ SP03 I2C Address
CmdReg Con 0 ’ SP03 Command register
VerReg Con 1 ’ SP03 Version register
LDBUF Con 0x00 ’ NOP command is Load buffer
SPKBUF Con 0x40 ’ Speak buffer Command
Stat Var byte ’ Status byte from SP03
Main
i2cout SDA, SCL, SP03, CmdReg, [21]
GoSub Wait4Shutup
Forever:
i2cout SDA, SCL, SP03, CmdReg, [LDBUF, 0, 5, 3, “Speech test - mark one”, 0]
i2cout SDA, SCL, SP03, CmdReg, [SPKBUF]
GoSub Wait4Shutup
pause 10000
goto forever
End
Wait4Shutup:
i2cin SDA, SCL, SP03, CmdReg, [Stat]
serout S_OUT,i57600,[HEX Stat," "]
if Stat < 128 then
serout S_OUT,i57600,[13]
endif
ummm…yeah… moving the pins to P0 and P1 works. I tried a few other pins since ultimately I don’t want to tie up the A/D pins. 4-5 also seem to work. I originally went with 6 & 7 since those seem to be tied to the H8’s hardware sda, scl. who knew?
There are still some issues. Here are some things I can say for sure:
Omitting the “optional” Address value causes a jump to the i2cerror lable.
A pause of about 4ms (2ms didn’t work) is required between commands or the command will jump to the i2cerror lable.
It’s not clear how strings are handled. Setting a byte array equal to a string constant and then putting the variable in the output only sends the first byte (e.g., “H” ) If the length of a string is not stored in the first byte (a la old style BASIC) and there is no terminating byte (a la C) how does the compiler know how long my string is? How can I use I2COUT to send an arbitrary length string?
There is no such thing as a “string” in MBasic so thats why it acts the way it does. The setting of the values in an array is simply a hold over from the ability to do this( temp = 1,2,3,4,5,6,7). Setting the values of an array with a “string” basically works the same way. Internally its the same as temp = “s”,“t”,“r”,“i”,“n”,“g”. No where else will a “string” be handled unless you tell it to(via the str modifiers). To process an array automatically in a command you would do somthing like so:
temp var byte(10)
temp = 1,2,3,4,5,6,7,8,9,0
i2cout blah,blah,[str temp\10] ;send all 10 bytes of temp array out
or
i2cout blah,blah,[str temp\10\4] ; send upto 10 bytes of temp array out stopping when value = 4
It is worth taking some time to delve into the Renesas hardware manual for Atom PRO chip. It will help understanding the hardware functions it has. I believe it’s the manual for the 3664F or 3687 you want to look at. The hardware manuals will fill in a lot of details that are not documented (and shouldn’t need to be) in the Atom programming manuals. There is a lot of good info in the hardware manuals, even if it can take a bit of time to dig it out and understand it.
AtomPro24 and 28 modules are H8-3664(also 3694s which are replacing the 3664s but have the same capabilities)
AtomPro40+ is based on the H8-3687 but isn’t released yet(I have one but we are working on ramping production on these).
Most commands in MBasic for AtomPro are software based(eg bit banged) so which pin you use is not really relevant(except in the cases of P6 and P7 since they are 3.3v)output) only pins though they are 5v(intput) tolerant). Only the hardware specific commands and special features (like interrupts) require specific pins and/or deep knowledge of the chips. The 3664 ahd 3687 manuals are included in the IDE and are available in the Help menu(you will need Acrobat reader to view them).
I’ve listed the relevant H8 to AtomPro pinouts before but here they are again. Note pin names in ( ) are the hitachi pins. <-> indicates more than one hitachi pin is attached to the same AtomPro pin. For example P0 is connected to P50 and PB0 on the hitachi chip. This allows output via P0 but also allows support for A/D conversion. I did not list the S_IN/S_OUT pins. On the Pro24 and 28 they are attached to P14 on the hitachi via a halfduplex diode circuit. On the Pro40+ they are attached to RXD_1 and TXD_1 respectively.
ummm…yeah… moving the pins to P0 and P1 works. I tried a few other pins since ultimately I don’t want to tie up the A/D pins. 4-5 also seem to work. I originally went with 6 & 7 since those seem to be tied to the H8’s hardware sda, scl. who knew?