Ok, so the HPWM only works on pins 10, 11, and 12. So the only known issues are with DTMFOUT and possibly SHIFTOUT. Sorry for the thread jack. I’m starting a new Pro 8.0.1.3 Beta thread.
thanks for the confirmation on the sound Robot Dude
As for SHIFTOUT got the cro today and had a look at the signal. as far as i can tell the micro is outputting the correct signal. i can’t tell if the timing is correct because the cro i scored is one of the old ones uni was giving away. anyway, my understanding is that even if the timing is not correct the LCD should still read something at the CLK time, even if its 0x00 or 0xF5. correct?
anyway here is the code i used and analysed the signal.
i know its a big ask, but can someone look over this source code written in C? forum.modtronix.com/index.php?topic=399.0 its been a few years since i have touched C…
as i understand it IDE supports C, right?
Here is a quick build of some of this code. You start off in the ide and do a create new project. Make sure to select C and C++ project type. In my case I called the project SPI. Please note, I simply made it compile, I have not tried running it on my machine. Your milage may very…
This function writes a byte out onto the SPI OUT port, and reads a byte from
the SPI IN port.
@param c Gives the byte to write out onto the SPI port
@return Returns the byte read from the SPI IN port
*/
void Nop()
{
int i;
for (i=0; i<100; i++)
{
;
}
}
char spiPutGetByte(char c) {
char ret;
unsigned char mask;
//SPI Mode 0. CS active low. Clock idle 0. Clock rising edge.
SPI_CLK = 0;
//Enable SPI communication. The SPI Enable signal must be pulsed low for each byte sent!
SPI_CS = 0;
//Ensure a minimum delay of 500ns between falling edge of SPI Enable signal
//and rising edge of SPI Clock!
Nop();
mask = 0x80; //Initialize to write and read bit 7
ret = 0; //Initialize read byte with 0
do {
SPI_OUT = 0; //Clock out current bit onto SPI Out line
if (c & mask) SPI_OUT = 1;
SPI_CLK = 1; //Set SPI Clock line
if (SPI_IN) ret |= mask; //Read current bit fromSPI In line
Nop(); //Ensure minimum delay of 500nS between SPI Clock high and SPI Clock Low
SPI_CLK = 0; //Set SPI Clock line
mask = mask >> 1; //Shift mask so that next bit is written and read from SPI lines
Nop(); //Ensure minimum delay of 1000ns between bits
} while (mask != 0);
//Ensure a minimum delay of 750ns between falling edge of SPI Clock signal
//and rising edge of SPI Enable!
Nop();Nop();
//Disable SPI communication. The SPI Enable signal must be pulsed low for each byte sent!
SPI_CS = 1;
return ret;
}
int main(void)
{
spiPutGetByte(0xf5); //Sync byte - each SPI command has to start with this byte!
spiPutGetByte(0x80); //“Write parsed string command”
spiPutGetByte(0x0c); //Clear display and go to beginning of first line.
//Write "Hello" in line one, and "World" in line two
spiPutGetByte('H');
spiPutGetByte('e');
spiPutGetByte('l');
spiPutGetByte('l');
spiPutGetByte('o');
spiPutGetByte(0x0a); //Go to beginning of next line
spiPutGetByte('W');
spiPutGetByte('o');
spiPutGetByte('r');
spiPutGetByte('l');
spiPutGetByte('d');
}[/code]
Now through an earlier time when I was playing with the C++ had a version of the include file I show above that made it easier to deal with the hardware registers. I include it here in case anyone wishes to use it…
I’ve got to assume a cro is some sort of oscilloscope?
in the code clip you posted you set P0 low before P1 but called P0 CS in the comment. This is incorrect, you need to make certain CLK is low before you set CS low. You also need to release and re-assert CS between bytes. Lastly, unless I am looking at the wrong data sheet the sync byte = 0xF5 = 245, and backlight off = 0x20 = 32. modtronix.com/products/lcd2s/lcd2sr1_v120.pdf
the c code at the link you supply does the same basic thing as the basic code I provided. he implements shifting the data out a little differently. instead of shifting the output data byte and always using the MSB to set SP_OUT he uses a mask byte to select the bit to send and sets SP_OUT accordingly, then shifts the mask byte. it’s the same effect, MSB goes first. The only significant difference is how he reads the incomming byte (his is correct and reads the bit after the CLK goes L->H) but you are not using that so it is a wash.
this is a dumb question and you have probably already answered it, but are you certain both switches of the DIP switch are in the ON position? the SPI input will get ignored if they are not set.
thanks dude. not a dumb question at all. yes as far as i can tell everything is setup correctly. i always check to see if it will work in both positions.
i figured out the 0xF5 command after i had already made that post. silly me. it still doesn’t work though.
Starting Compiler…
c:\program files\basicmicro\basicatom-pro ide\lcd c style\spi.c
h8300-coff-gcc.exe: installation problem, cannot exec `cc1’: No such file or directory
Linking…
h8300-coff-gcc.exe: c:\program files\basicmicro\basicatom-pro ide\lcd c style\spi.o: No such file or directory
Errors Detected
would i right in assuming i need to install GCC? why is nothing easy with programming…
klims, did you try the code I posted above and verify the correct waveforms on your scope? There is no obvious reason the BASIC code should not work, and changing compilers brings a ton of extraneous variables into play that will just make debugging the problem even more difficult. the code is straight forward enough that basic micro should be able to test it with whatever the current IDE flavor is and verify their shiftout command works or does not.
Actually the GCC compiler was installed. I think I had a thread about this (or may have been a set of private messages), but the problem with 8.0.1.0 was that it did not set the path environment variable to locate the necessary programs. I don’t have the exact paths right now as I am on a portable that does not have any of this installed on it. It is in a sub-directory that is part of the BAP installation point. You can either manually try adding this to your path environment variable or you can try installing his latest beta as I think he fixed this for about 8.0.1.2.
As for the C code, the only thing I did was to make it work with the structured register definitions and put a dummy Nop() function in. If I were doing it for myself I would probably put in a real timer function based off one of the system timers.
Also looking at the code I posted, there may need to be some more initialization code added. For example to make sure the correct ports are either input or output.
Looking at the Basic code that Eddie posted I think this should probably work as well. If I get a chance I may try to use my very limited parallax USB ossciloscope to see if it at least outputs something. This has a very very limited buffer so I may not see much, but…
I read a little bit about this last night in the Atom manual and it mentioned the pins remain in same state at the end of the command high or low, which ever state it was in at the time. I don’t have the manual in front of me so I can’t say for sure.
I thought that something like that may be the case, but I did not see anything in the current electronic manual. That is why for the fun of it I put the LOW commands in at the start. They did not appear to make any difference in the levels. I wonder if he simply leaves the output pin at the last bits value. I may experiment tomorrow to see if this might be the case…
So is an Atom SPI program or a ‘C’ SPI program wanted? I missed something in the thread I guess. I have some C code working; (although it could work better) if that’s what’s wanted.
kurke - thanks for the help. looks a lot like what i am getting. is it possible to shorten the time scale of your little device to get a better reading? i see the same thing but my cro(cathode ray oscilloscope) can’t do it.
KM6VV - i’d love to try some C code, because the Mr Modtronix tells me that the C code posted definitely works. i will need to get me a beta version of the IDE though.
EddieB - the only thing i can verify on my S&*T c.r.o is that the waveform looks correct, but i cannot get it accurate enough to check the timing. from what i can see it looks like the output is ok.
at this point the waveforms have been verified and the SHIFTOUT command does work. the only thing i put the LCD not working down to is timing.
any suggestions anyone? anything at all?
I think I had the little thing running as fast as I could. I brought over the latest version of the software to the machine, but have not had a chance to try it yet.
As for C code, I did post a version of it that compiles. You might try the beta version of the IDE or you can simply search for the exe files that fail and add those manually to your path environment variable. I believe may need to add two paths to it. Sorry but it is not on this machine or I would tell you the exact strings.
Have you tried the Basic code to see if it worked? My guess is that you can be almost as slow as you want in the output routines as long as there is enough delay when the clock changes state for the LCD to sample the value.
i’ve tried all versions of basic code and nothing works. i even tried a few of my own with no luck.
as for the C code, i just installed the 8.0.1.2 and i’m still having the same problem. it comes up with the same error. was it maybe a different version that works with C?
yeah i was thinking it might be a timing thing to do with the LCD, but Modtronix claims the LCD is capable of up to 1MB/s. i even tried putting in massive delays everywhere but still no luck. i think my only hope at this stage is to get the IDE to run C.
So there’s a C compiler for the IDE you’re using? is that for the H8/3664 and not the Atom 28 pro? I got confused somewhere in the thread. Are you talking to a PS2 controller, or some other part?
Anyway, you should be able to do some continuous calls to the send routine, and see it on a scope. When I worked with my routines, I used a 4 channel scope. It can also be done with just 2 channels, but it’s a little harder to see the data alignment with the clocks.
You might try the C code below. IF-THEN-ELSE constructs are used to attempt to balance the instruction time and reduce the jitter. PIC18 uP, Hightec compiler. a delay routine is used instead of the nop() your sample had.
the mask could probably used for the iteration variable, and the variable i eliminated. It also appears to shift bits out in the opposite direction then your sample routine.
/*
* Routine to send commands and receive data from PS2 via SPI
* Shift out (LSB first) a byte to SPI
* and simultaneously shift in (LSB first) a byte
*
* Call with byte to send.
* Returns byte read.
*
* 09/02/07 data changes *BEFORE* negative going clock edges
*
* Observed 312K clock rate, 1 uS clock pulse width
*/
unsigned char ShiftInOut(unsigned char SendChr)
{
unsigned char i, mask;
unsigned char RcvChr;
RcvChr = 0;
SPI_CMD = 1;
for(i = 0, mask = 1; i < 8; i++, mask <<= 1)
{
if(SendChr & mask) /* output a data bit */
SPI_CMD = 1;
else
SPI_CMD = 0;
SPI_CLK = 0; /* generate 1 uS clock pulse */
DelayMicrosec(DELAY);
SPI_CLK = 1; /* Clock the Bit */
if(SPI_DAT) /* input a data bit */
RcvChr |= mask;
else
RcvChr &= ~mask; /* for balance of inst time */
DelayMicrosec(DELAY);
}
SPI_CMD = 1;
return(RcvChr);
}
Might give you some ideas. I could actually see the data starting to come back after I got some of the timing right.
On another front, I’ve got a new sonar board to play with. I2C instead of SPI which I’m more familiar with, but I found some sample I2C code to try it out. It’s supposed to be similar to talking to a 24LC256P EEPROM chip.
I wonder if your LCD is working properly if neither the basic code nor the shiftout worked.
If you have installed the beta 8.0.1.3 and the C compiler still does not run at all, then you might need to hack the path environment variable. On the machine that I tried compiling the C code this morning the compiler ran just fine, but earlier I did have a problem on another machine. I am not sure but it might have been the machine I run Vista on. I was able to get it to work on that machine by adding stuff to path environment variable. You might try it to see if it works for you.
What you basically have to do is to open up the System control panel (open control panel and double click on system or click on start menu, right click on system and choose properties).
Go to the advanced page and click on the environment variables button.
in either the system or user area, modify or create a variable “PATH”
Assuming a default install that matches mine, you would add something like: