Author Topic: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK  (Read 100342 times)

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #45 on: August 20, 2010, 11:01:37 AM »
I'm posting this partly to share, partly to remind myself if I'm looking for a reminder about what happened on the above broken hex issue. The issue was sourced when I created my own task. The make file didn't include my-first-task.c and was producing a cs-make error, even though the output window reported success while compiling. I noticed the error message failed relative to and undefined my-first-task.

So I changed make_uTaskerV1.4_GNU_LPC23XX to read like this.
Code: [Select]
# All objects (Hardware, application, uTasker, stack)
#
OBJS = Build/my-first-task.o Build/application.o blah blah

# Application files
#
#added by jah
Build/my-first-task.o: ../my-first-task.c $(DEPENDS) ../application_lcd.h ../config.h
$(CC) $(C_FLAGS) $(INC) $(OPTS) ../my-first-task.c -o Build/my-first-task.o
#end added by jah

Build/application.o: ../application.c blah blah
It now again compiles the .hex file, and I'm back to debugging my code. Because it fails, but Visual Studio thinks is passed, you'll have to build clean each time you change the make file to get this to compile.

It might be handy to add a note in section 5 of the users guide about the make file.

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #46 on: August 25, 2010, 03:17:47 AM »
I think I may have found another memory mapping issue. I'm trying to use the UEXT connector on the LPC23478-stk. When I do this code
Code: [Select]
PINMODE0 |= PINMODE_PULLDOWN_6;I get this result in the watch window, also the real hardware doesn't seem strong enough to pull down the bit, so it would appear the pull down is not activated.
Code: [Select]
PINMODE0 0x00000000 unsigned long
PINMODE5 0x00003000 unsigned long
It appears it did those bits to the 5, not the 0 mode.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #47 on: August 25, 2010, 02:59:26 PM »
Hi

Thanks. Yes, there is an error in the following struct in simLPC23XX.h

typedef struct stLPC23XX_PIN_CON
{
unsigned long PINSEL0;
unsigned long PINSEL1;
unsigned long PINSEL2;
unsigned long PINSEL3;
unsigned long PINSEL4;
unsigned long PINSEL5;
unsigned long PINSEL6;
unsigned long PINSEL7;
unsigned long PINSEL8;
unsigned long PINSEL9;
unsigned long PINSEL10;
unsigned long PINSEL11;                                                  // only LPC247X
unsigned long ulRes0[4];

unsigned long PINMODE0;
unsigned long PINMODE1;
unsigned long PINMODE2;
unsigned long PINMODE3;
unsigned long PINMODE4;
unsigned long PINMODE5;
unsigned long PINMODE6;
unsigned long PINMODE7;
unsigned long PINMODE8;
unsigned long PINMODE9;
} LPC23XX_PIN_CON;


Here PINSEL11 and ulRes0[4] have been added so that the PINMODEx registers are at correct locations.

This will mean that the simulator correctly displays the register content. It won't however make any difference on the target since the register addresses are correct - you may need to verify the pull-down strength that you are expecting since internal ones tend to be quite weak (say 25k or so).

Regards

Mark

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #48 on: August 26, 2010, 01:36:49 AM »
Great the simulator is working and now several tests match what I'm seeing on the target and the simulator. Having it working helped me debug my code that simply lists bits to the screen, which allowed me to verify that bits are internally being set correctly.

I'm not seeing what I expect to see on the target pins. I have verified several bits via LCD. However, I can't seem to get P0.6 SSEL1, to go low. It has a 33K external pull up to 3.3v. I've tried enabling/disabling internal pulls, I've tried it as SSEL and GPIO. I don't appear to have enough drive to change the voltage at all. I would say I most likely don't have something configured correctly, so here's some code snippets. From "myfirsttask" which runs 2 seconds after boot, then each second after,

Code: [Select]
fnConfigSPI_jah();
#define WHO_AM_I 0x0F //memory location 0x0F should read as 0x3A
CS_CLR_PORT = CS0_LINE;  //ulChipSelectLine; // assert SS low before starting
SSPDR_X = WHO_AM_I; //request this reg
while (SSPSR_X & (SSP_BSY | SSP_RNE)) { // wait for transfer to complete and clear rx buffer
     volatile unsigned long ulDummy = SSPDR_X;
}
//CS_SET_PORT = CS0_LINE;//ulChipSelectLine;
And from the included header file.
Code: [Select]
static void fnConfigSPI_jah(void)//unsigned char ucSpeed)
{
//power
    POWER_UP(PCSPI);                                                   // {10} power up the SSP used
//clock  PCLK_SEL0 select PCLK_SPI
//currently it's got a clock rate, I'll deal with specifics later.
//pin sel / mode
    CONFIGURE_SPI_PINS();//sel
    CONFIGURE_CS_LINES();//FIO0SET and FIO0DIR
//PINMODE0 |= PINMODE_NO_PULLS_6;//PINMODE_PULLDOWN_6;
//irq's

    SSPCR1_X = 0;                                                        // ensure disabled (master mode)
    SSPCPSR_X = 8;                                                       // set clock prescaler (even prescale 2..254)

//    switch (ucSpeed) {
//    case MAX_SPI:                                                        // set maximum possible SPI speed
        SSPCR0_X = (FRS_FREESCALE_SPI | DSS_8_BIT | (0 << SSP_SCR_SHIFT)); // set exact frequency and mode
//     break;

//    case SPI_2MEG:
//        SSPCR0_X = (FRS_FREESCALE_SPI | DSS_8_BIT | ((((SSP_CLOCK/2 + 2000000/2)/2000000) - 1) << SSP_SCR_SHIFT)); // set exact frequency and mode
//     break;

//    case SPI_SLAVE:
//     return;
//    }
    SSPCR1_X = SSP_SSE;                                                  // enable
}
Also from app_hw_lpc23xx.h I added to this command, such that PO_6 is SSEL. This command comes and goes with my testing/debugging.
Code: [Select]
#define CONFIGURE_SPI_PINS()        PINSEL0 |= (PINSEL0_P0_8_MISO1 | PINSEL0_P0_9_MOSI1 | PINSEL0_P0_7_SCK1 | PINSEL0_P0_6_SSEL1); // MOSI, MISO and SCK pins enabled - on SSP1

Because I've commented out //CS_SET_PORT, I expect it to pull PO.6 low and keep it there. The simulator currently shows this a lower case p, and if I comment out the SSEL thing, it shows as a O, or 1 based which CS_SET_PORT I comment out. However, it just stays there at 3.3v, doesn't budge a bit, I don't see any bumps on the scope.

Are there any suggestions or pointers? When configured for SSEL, I might guess this is automatic, such that I can't drive it high or low manually. This would make since why I can't git it to go high or low. When configured as GPIO, I believe the direction is set correctly, but no dice.

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #49 on: August 26, 2010, 11:22:05 AM »
I noticed FIOSET and FIOCLR are both set. Perhaps this is where things get buggered... Here's a snap shot of my watch window, just after it ran the CS_CLR_PORT = CS0_LINE command.
Code: [Select]
- [0x0] {FIODIR=0x00600040 res1=0x00539f6c FIOMASK=0x00000000 ...} stLPC23XX_FAST_GPIO
FIODIR 0x00600040 unsigned long
+ res1 0x00539f6c unsigned long [3]
FIOMASK 0x00000000 unsigned long
FIOPIN 0xffdfffff unsigned long
FIOSET 0x00400042 unsigned long
FIOCLR 0x00000040 unsigned long
I notice FIOPIN is a 1. I also read that "Writing 0s has no effect" on FIOSET. Perhaps I have to write a 0 to this such that FIOCLR can drive it low? I'm a bit baffled about why this isn't working.

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #50 on: August 29, 2010, 01:48:24 AM »
So it would appear that under FIOSET when the datasheet notes, "Writing 0s has no effect." What they really mean is that writing a 1, will cause the port to be pulled high, and writing a 0 will cause the port to not be driven by the high side drive. Disconnecting the high side drive is a lot different than no effect. Once I cleared both the FIOSET and FIOCLR, I was free to control the port via FIO0PIN. Now it's off to debugging SPI clocking.

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #51 on: August 29, 2010, 04:34:50 AM »
The datasheet wants me to look at S0SPCCR for the SPI clock settings. The example code I'm looking at uses SSPCPSR_X to set the clock, but appears to be using SSP not SPI registers. It appears that SSP can be used for SPI and I'm not sure if this type of SSP/SPI can be used with my device or not. Is there a way to get the simulator and device to work with the dedicated SPI hardware?

Under LPC23XX.h I see this.

  #define RTC_BLOCK                      0xe0024000
  #define LEGACY_GPIO_BLOCK              0xe0028000
  #define PIN_CONNECT_BLOCK              0xe002c000

I would guess I can add #define S0SPCCR 0xE002000C, but I don't think I'd get it in the simulator. Can I add this to the simulator?

Or even better what about adding 0xE002 0000, then the +000C thing more like the normal practice in other parts of this code.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #52 on: August 29, 2010, 04:13:47 PM »
Hi

The SPI registers are not included since only the SSP have been used to date.

To add these do the following:

1) In LPC23XX.h

  #define SPI_BLOCK_0                    ((unsigned char *)(&ucLPC23xx.ucSPI0)) (for simulator)
  #define SPI_BLOCK_0                    0xe0020000 (for target)


// SPI
//
#define S0SPCR                           *(unsigned long*)(SPI_BLOCK_0 + 0x00)              // SPI Control Register
#define S0SPSR                           *(volatile unsigned long*)(SPI_BLOCK_0 + 0x04)     // SPI Status Register (read-only)
#define S0SPDR                           *(volatile unsigned long*)(SPI_BLOCK_0 + 0x08)     // SPI Data Register
#define S0SPCCR                          *(unsigned long*)(SPI_BLOCK_0 + 0x0c)              // SPI Clock Counter Register
#define S0SPINT                          *(volatile unsigned long*)(SPI_BLOCK_0 + 0x1c)     // SPI Interrupt Flag Register


Here the register bits are not yet defined but at least their locations are.

2) In simLPC23XX.h

In the struct LPC23XX_PERIPH add
    LPC23XX_SPI         ucSPI0;

Add a new struct:

typedef struct stLPC23XX_SPI
{
unsigned long SPISPCR;
unsigned long SPISPSR;
unsigned long SPISPDR;
unsigned long SPISPCCR;
unsigned long ulRes0[3];
unsigned long SPISPINT;
} LPC23XX_SPI;



Now you should be able to use the registers for the target and also check their content in the simulator.

Regards

Mark

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #53 on: September 06, 2010, 01:10:49 PM »
The SPI registers are not included since only the SSP have been used to date.
It turns out that MOSI1 is on the SSP interface, not the SPI interface. So I ended up using the original SSP stuff. I did add the SPI stuff as you noted, and it appears to have been working OK, with the exception of being on the wrong pins for my application. Thanks for sending that along.

Right now, I see the clock and MOSI pins wiggle as expected. The slave device even wiggles the MISO lines as expected. However I'm having trouble getting the proto board to display those wiggled bits on the LCD correctly. Here are some snippets of my current code.

From app_hw_lpc23xx.h
Code: [Select]
#define CONFIGURE_SPI_PINS()        PINSEL0 |= (PINSEL0_P0_8_MISO1 | PINSEL0_P0_9_MOSI1 | PINSEL0_P0_7_SCK1);// | PINSEL0_P0_6_SSEL1); // MOSI, MISO and SCK pins enabled - on SSP1

blah blah

#define CONFIGURE_CS_LINES()        FIO0DIR |= CS0_LINE; _SIM_PORTS

blah blah

#define CS0_LINE            PORT0_BIT6//PORT0_BIT14                                  // CS0 line used when SPI FLASH is enabled


From my task.h
Code: [Select]
static void fnConfigSPI_jah(void)//unsigned char ucSpeed)
{
//pg 436 setup
    POWER_UP(PCSSP1); // power up the SPI on SSP port
//clock note, PCLK_SEL0 select PCLK_SPI default is cclk/4, set bits 16:17 (11) for cclk/8
PCLKSEL0 |= PCLK_SSP1_CCLK_8;// set for /8
    CONFIGURE_SPI_PINS(); //SET PINSEL0 BITS to make pins SPI
    CONFIGURE_CS_LINES(); //FIO0SET and FIO0DIR for software driven CS line
//PINMODE0 |= PINMODE_NO_PULLS_6;//PINMODE_PULLDOWN_6;
//PINMODE0 |= PINMODE_NO_PULLS_7;//PINMODE_PULLDOWN_7;
//PINMODE0 |= PINMODE_NO_PULLS_8;// P0.8 is driven by the slave, so don't drive it here
//PINMODE0 |= PINMODE_NO_PULLS_9;//PINMODE_PULLDOWN_9;
//irq's
//NA verified as off

//other setup
    SSPCPSR_X = 16; // set clock prescaler (even prescale 2..254)
    SSPCR0_X = DSS_8_BIT; // set 8 bit words
    SSPCR1_X = SSP_SSE;         // enable
}

from my task set to run 2 seconds after boot and every .1 seconds after that.
Code: [Select]
unsigned long temp;
unsigned long temp2;
volatile unsigned long ulDummy;
volatile unsigned long ulDummy2;
volatile unsigned long ulDummy3;
volatile unsigned long ulDummy4;
volatile unsigned long ulDummy5;


// read mfg from spi chip and display on screen
fnConfigSPI_jah();

//TIMER_US_DELAY(TIMER_FREQUENCY_VALUE(10000))
    //jah_delay();

#define WHO_AM_I 0x0F //memory location 0x0F should read as 0x3A

temp = SSP0CR0; //appears something else uses this SPI reg, so lets save it and restore it when done with this process
SSP0CR0 = (SSP0CR0 & 0xfff0) | 0x07;//clear the lower 4 bits, and set an 8 bit word
FIO0PIN &= 0xffffffbf; // assert SS low before starting

SSPDR_X = WHO_AM_I | 0x80; // send command
SSPDR_X = 0x00; // send blank bits to allow clocks for return command
//while (SSPSR_X & SSP_TFE) {}
//temp2 = SSPSR_X;
while (SSPSR_X & (SSP_BSY | SSP_RNE)) {// wait for transfer to complete and clear rx buffer
    ulDummy5 = ulDummy4;//save it to ulDummy
    ulDummy4 = ulDummy3;//save it to ulDummy
    ulDummy3 = ulDummy2;//save it to ulDummy
    ulDummy2 = ulDummy;//save it to ulDummy
    ulDummy = SSPDR_X;//save it to ulDummy
    }

FIO0PIN |= 0x00000040; // assert SS high after done transmission
SSP0CR0 = temp; //return to the normally scheduled program.

fnLCD_display_bits(95,50,"ul4",ulDummy4); //>> 24);

//fnLCD_display_bits(95,60,"S0SPCR",S0SPCR);
//fnLCD_display_bits(95,50,"PCLKSEL0",*(unsigned long *)0xE01FC1A8 >> 4);// >> 0&0xE0020000);
//fnLCD_display_bits(95,70,"S0SPSR",S0SPSR);
//fnLCD_display_bits(95,80,"S0SPSR8",S0SPSR >> 8);
//fnLCD_display_bits(95,90,"S0SPCCR",S0SPCCR);
//fnLCD_display_bits(95,100,"S0SPCCR8",S0SPCCR >> 8);

There is certainly some back magic going on when it comes to the ulDummy thing. Or at least it's black magic to me. I don't know exactly how to know when it should stop reading bytes of data.

I see the MISO line holds low for a while after the clk has stopped. It would appear the slave is holding it low until the CS line is again asserted high by my code. My assertion varies by about 1 byte for an unknown reason. This variation in the CS line makes the received 0x3A data most of the time show up in ulDummy4, and some times ulDummy3/5.

Why it keeps reading bits after the clock has stopped is some black magic to me. I don't know how my code can better identify when it finished sending bits. In this case, I know I will send one byte, then receive one byte. I'd like to force it to stop after those bytes have been sent, but I don't know how my software can know when it's finished sending a byte. I tried some stuff with the buffer cleared bit SSP_TFE, but that locked things up, stopped blinking the heartbeat LED kind of lockup. 

I've also tried to use SSEL instead of GPIO. This didn't work because after each SSPDR_X it brought CS high which prevented the slave from replying. Perhaps I can get a string into SSPDR_X, such that it sends multiple bytes and doesn't assert CS high. Not sure. I'm a bit baffled by the black magic at the moment.


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #54 on: September 06, 2010, 03:11:12 PM »
Hi

The SSP has a FIFO depth of 8. When writing, up to 8 bytes can be simply written as fast as possible and then the complete transmission must be waited for. For each transmitted byte you also get a reception byte, which is dummy and so needs to be discarded. When there is something in teh FIFO input each read of the data register removes one of the received bytes.

It is important which flags are to be waited on. These examples may help:

while (SSPSR_X & SSP_BSY) {};                                    // wait for transfer to complete
while (!(SSPSR_X & SSP_RNE)) {}                          // wait only if no reception ready
while (SSPSR_X & (SSP_BSY | SSP_RNE)) {                      // wait for transfer to complete and clear rx buffer


- Only read a reception byte when you known that it is available otherwise it will return nothing of interest and the expected byte will arrive later.
- Make sure that you read the correct number of bytes - one for each complete transmission - and discard the ones that of not of interest.

Also, don't forget the port macros (see LPC23XX.h: Eg. _CLEARBITS(ref, mask) and _SETBITS(ref, mask)) which can make code easier and more portable.

In your while loop the reception data is being read many times while the complete transmission takes place. This will result in a large amount of 'empty' reads since there is no data ready, and occasionally a real reception byte in between. Once all transmission has taken place and all reception is ready you don't read again (this may miss the final byte). Instead you could loop on the complete transmission/receptions flags and then simply read the number of bytes from the data register (as long as less than 8 ).

Regards

Mark
« Last Edit: September 06, 2010, 09:23:20 PM by mark »

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #55 on: September 06, 2010, 08:43:08 PM »
Also, don't forget the port macros (see LPC23XX.h: Eg. _CLEARBITS(ref, mask) and _SETBITS(ref, mask)) which can make code easier and more portable.

Thanks, I'll keep that in mind. For now it works, so I'll likely do that later down the road.

Per your notes I got it reading a reliable 3A, yeah, it now does the extreme basics. Here the code that got it displaying.
Code: [Select]
// read mfg from spi chip and display on screen
fnConfigSPI_jah();

#define WHO_AM_I 0x0F //memory location 0x0F should read as 0x3A

temp = SSP0CR0; //appears something else uses this SPI reg, so lets save it and restore it when done with this process
SSP0CR0 = (SSP0CR0 & 0xfff0) | 0x07;//clear the lower 4 bits, and set an 8 bit word
FIO0PIN &= 0xffffffbf; // assert SS low before starting

SSPDR_X = WHO_AM_I | 0x80; // send command the 0x80 sets the read vs write bit.
SSPDR_X = 0x00; // send blank bits to allow clocks for return command
while (!(SSPSR_X & SSP_RNE)){};//first byte is blank
ulDummy = SSPDR_X;
while (!(SSPSR_X & SSP_RNE)){};//second byte is the address
ulDummy2 = SSPDR_X;
while (SSPSR_X & (SSP_BSY | SSP_RNE)) {// wait for all transfers to complete and clear rx buffer
    ulDummy = SSPDR_X;//save it to ulDummy
    }

FIO0PIN |= 0x00000040; // assert SS high after done transmission
SSP0CR0 = temp; //return to the normally scheduled program.

fnLCD_display_bits(95,50,"ul 2",ulDummy2); //>> 24);

//fnLCD_display_bits(95,60,"S0SPCR",S0SPCR);
//fnLCD_display_bits(95,50,"PCLKSEL0",*(unsigned long *)0xE01FC1A8 >> 4);// >> 0&0xE0020000);
//fnLCD_display_bits(95,70,"S0SPSR",S0SPSR);
//fnLCD_display_bits(95,80,"S0SPSR8",S0SPSR >> 8);
//fnLCD_display_bits(95,90,"S0SPCCR",S0SPCCR);
//fnLCD_display_bits(95,100,"S0SPCCR8",S0SPCCR >> 8);

}

Now to see if I can get it to give me a reading for the accelerometer. Thanks for the note, again spot on.

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #56 on: September 07, 2010, 02:57:39 AM »
It's working great now, I've got it reading both X and Y axis's, which required me to write to the AIS226 at least once. I'm hitting a small problem, it appears I'm buggering the LCD some how. I've seen this before, but was ignoring it. It appears that if I write too many commands to the LCD it will lock up. For example, the below code displays as expected.
Code: [Select]
//fnLCD_display_hex(95,50,"hex X",fnSPI_AIS226(OUTX_L, READ, 0x00));
//fnLCD_display_hex(85,50,"",fnSPI_AIS226(OUTX_H, READ, 0x00));
fnLCD_display_hex(95,60,"hex Y",fnSPI_AIS226(OUTY_L, READ, 0x00));
fnLCD_display_hex(85,60,"",fnSPI_AIS226(OUTY_H, READ, 0x00));
If I uncomment the X and comment the Y, it also works. However if I uncomment both the X and the Y, the LCD locks up. I still get the heartbeat LED, but the LCD stop reacting. I set a small blinking box on the LCD, which functions as a LCD heartbeat indicator. When the LCD locks up, this blinking box stops blinking. I'm curious what causes the LCD to stop reacting. Perhaps I shouldn't be constantly refreshing nearly the entire screen every .2 seconds. I might guess I'm exceeding a buffer limit or something. Perhaps I should check a buffer before I write an LCD command.

Another thing I'd like to iron out if possible, is how to fix the mild watch dog issues. I seem to recall a note that if you reboot while in the middle of a watch dog event, it won't boot up. This is simply resolved on this board via reset switch. That seems to bring it back out of this issue. Is there a way to make it always work?

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #57 on: September 07, 2010, 11:23:45 AM »
I just did that _CLEARBITS(ref, mask) and _SETBITS(ref, mask) thing, that was easy. I see another feature I should learn more about. It appears utasker has a nice feature to identify the initial run of a task as noted in the task table ucTaskState. I'm thumbing through the PDF's to see if I can find some insight into the task state thing. I know I saw something about that in one of those PDF's.

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #58 on: September 09, 2010, 10:02:39 PM »
So my programming stills get better every day. It appears that

static unsigned char ucCounter = 0;

is a lot different than

static unsigned char ucCounter = 0;
ucCounter = 0;

That's a neat trick for handling the initialization / normal operation of my_task. Now that my_task only displays information to the LCD that it needs to display, it still appears I'm having problems when I try to write to much to the display. It appears like I'm exceeding a buffer or something. I'm still a bit baffeled about the LCD thing. The display commands are great, but there's some black magic going on that I'm ignorant about. Are there any tips about how to display text on the LCD? I have read uTaskerLCD.PDF.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #59 on: September 09, 2010, 11:16:55 PM »
Hi

There are 2 possible buffer problems. I am not exactly sure how you are sending text to the display task but, if it is via the input queue just ensure that the input queue is large enough to receive all waiting messages (the queue length is defined for the task in the task configuration table).

The second possibility is that it is a problem with the SSP buffer which is 8 bytes deep. When you write multiple bytes up to 8 then it is simple since you just need to wait for them to be sent. If your want to write longer stings it is necessary to copy up to 8 bytes and after that always wait until a TX FIFO entry becomes free before writing more. If you compare the SPI FLASH driver code when it writes more that 8 bytes in total you will see how it is done.

Regards

Mark