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

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3068
    • View Profile
    • uTasker
Re: MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #15 on: March 07, 2010, 06:33:13 PM »
Hi

There is no generic SPI interface due to the fact that SPI use is generally of quite a low level nature and varies greatly between devices connected.

The best thing to do is the take an SPI FLASH interface (eg. spi_flash_lpc_atmel.h) and use the same HW accesses for your interface. The NXP SPI has an 8 buffer FIFO which enables copying up to 8 data bytes to the output and also reading up to 8 receive bytes. Generally it will be necessary to identify when tx and rx has completed - eg.         while (SSP0SR & SSP_BSY) {};                                    // wait for transfer to complete
and the rest is simply reading and writing the data register SSP0DR.

I don't think that the LPC23xx supports DMA on the SPIs.

Regards

Mark


Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #16 on: May 18, 2010, 03:59:05 AM »
I've got the proto board on hand now and I'm trying to get back into this SPI eval thing. The SPI device  is attached to UEXT connector, and I had the LPC board displaying custom text via application_lcd.h's E_LCD_INITIALISED if statement.

I seem to be having some trouble figuring out this compiler. For example, in application_lcd.h, if I try to make the grey go away by commenting out the #if and matching #endif statements for this LCD section that includes code I know is being compiled, it will format correctly with green and blue, ect. However it won't compile. I get lots of syntax errors, and misc junk.

So I leave the define, statement, and the grey, and chock it to ignorance about why this is happening.

Then I copy most of spi_flash_lpc_atmel.h into applicaton_lcd.h below the if E_LCD_INITIALISED statement. Theory being that I can cut it down to something simple. My first goal is to simply read the status reg out of the AIS226 chip. I believe that's the same as the datasheet's noted STATUS_REG (0x27) which should read 0000. After a bit of chopping, I see SPI_FLASH_Danger which appears to be a first check before trying SPI stuff. I see it's defined in LPC23XX.c, however spi_flash_lpc_atmel.h file doesn't have an #include statement in the code. So I guess there must be some compiler config file that's allowing it to resolve when it's called in spi_flash_lpc_atmel.h. Another indicator that I don't understand how this compiler gets to point B. I tried to add an include file in my code just before it's called, but that really blew up. Again another indicator that I'm ignorant about this compile process.

So I try it another way. I copied spi_flash_lpc_atmel.h to spi_flash_lpc_AIS226.h in the same dir. Then started hacking out #define options I don't need. When I #include spi_flash_lpc_atmel.h in application_lcd.h, it compiles fine, but when I change that #include to spi_flash_lpc_AIS226.h, it produces a large pile of errors. It would appear that when I stripped out the define stuff, I took something important. It also looks like I can't declare things correctly. Line 5 is the first non-comment in the spi_flash_lpc_AIS226.h file, and looks like this.
Code: [Select]
static unsigned char fnCheckAIS226(void);I get this error.
Code: [Select]
c:\utaskerv1.4_lpc\hardware\lpc23xx\spi_flash_lpc_ais226.h(5) : error C2143: syntax error : missing ';' before 'type'It would appear to me that when it was behind the #define statement before, that changed the compile process, such that it could compile. However, I removed the #define's so it's broken.

So I should ask if using an #include statement in application_lcd.h is an appropriate method, or should I be calling fnSPI_command_AIS226 from spi_flash_lpc_AIS226.h a different way? If calling it that way is an OK theory of operation, how do I fix this syntax error?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3068
    • View Profile
    • uTasker
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #17 on: May 18, 2010, 12:57:10 PM »
Hi

I wouldn't recommend working in the header files. It is possible but it is easy to make a mistake. You need to be aware that these files are usually divided into sections and each section is linked in at a certain part of the main code (eg. application.c) - reminder: this technique is used to improved readability at the c file level (when the low level stuff is not of main interest) and avoids a rather large C file with many functions which make it hard to follow.

Some parts of the 'embedded' header files are included as standard code (like sub-routines) but others are 'inserted' into case statements. If you insert new code in the wrong section it may be being inserted into the middle of a case statement in the C-file and so even the simplest lines of code will result in syntax errors.

In your case, I don't see any reason to work in the header files so I would add a new file to the project and do all work there - call any subroutines from application.c if that makes sense - also add event handling etc. there. If you want to make it more modular (best as second step since first steps adding code to an existing task is easier) you can later add a new task of your own to do this dedicated work - handling its own timers and events as required.

Regards

Mark

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #18 on: May 19, 2010, 02:08:59 AM »
I was working in the header, because I know I can get the LCD to update based on what is put in that section of code. I'm familiar with why headers are use, that's not the area where I'm ignorant about the compiler. I also understand #include or #define statements can be used to make pieces of code viewable or not viewable when compiling.

I'm more than willing to move my code to application.c, but I don't know how to write something there that will update the LCD from that location. Hmmm, perhaps fnDoLCD_text in application_lcd.h can be called from application.c to display text on the screen from the SPI device? So I create an infinite loop at the end of application.c to make my main loop?  I tried this at the end of application.c.
Code: [Select]
#define _CAN_INIT_CODE
    #include "can_tests.h"                                               // CAN initialiation code and transmission routine
#undef _CAN_INIT_CODE

if (1) {
// text_pos.usY = 45;
// text_pos.ucFont = (FONT_FIVE_DOT);
// text_pos.ucMode = (REDRAW | GIVE_ACK);                   // an ack is requested when this has been completely displayed
// fnDoLCD_text(&text_pos, "application");
}
Ug, why does that produce a syntax error? If I comment out the if and the }, it compiles just fine.

I also tried it with our the loop attempt, and with only the four lines to update the LCD. That also produced several syntax errors.

Offline mark

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

By placing the code at this location (I think at the end of the file) it is not within a function (or the task) so will result in a syntax error.

Note also that a while(1) {} should not be used in a task. Instead the task can be set to polling mode [uTaskerStateChange(OWN_TASK, UTASKER_GO);] and will be continuously called to achieve the same effect.

You can call the LCD interface routines from any code since they are global functions.

Regards

Mark



Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #20 on: May 21, 2010, 03:20:37 AM »
I'm learning a bit more.

utasker.c appears to indicate that a task table is setup, and that fnApplication from application.c is one of these tasks that is run often. I think I can call an application_LCD.h function(s) from with in the fnApplication function. However my attempt is currently flopping. Here's my attempt to make this function call.
Code: [Select]
#define _PORT_NMI_CHECK                                                  // {53}
    #include "Port_Interrupts.h"                                         // port interrupt timer interrupt event handling - ranges
#undef _PORT_NMI_CHECK

fnDoLCD_com_text(TASK_LCD, "test", 4);
And here's the flop error.
Code: [Select]
Compiling...
application.c
c:\utaskerv1.4_lpc\applications\utaskerv1.4\application.c(799) : warning C4013: 'fnDoLCD_com_text' undefined; assuming extern returning int
I suspect that TASK_LCD is incorrect in this location, I was trying different things to see if it would compile. I think it's trying to declare itself at this line, and assumes it's something that it's not. I called it similar to how it's called a couple lines lower in application.c. I don't see any extra #includes or anything like that for those function calls. So I'm a bit confused about what I'm doing wrong.

Also am I on the right trail about calling this function from this area in application.c, and expecting to get some text to display on the screen?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3068
    • View Profile
    • uTasker
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #21 on: May 21, 2010, 01:28:24 PM »
Hi

The position of this code is basically correct (it will in fact cause the execution of your function each time that the application task is executed - you many not want it on every execution but this can be controlled using a state variable for its use - for example).

I think that your problem is however that you are using an LCD command rather than a GLCD command. fnDoLCD_com_text() is not for use with the GLCD (as on your board) and so its library is missing (and corresponding defines). fnDoLCD_text(&text_pos, "Starting..."); is an example of the GLCD text writing code.

Note also that sending a command to the GLCD as soon as the application task starts will also not work correctly because the application task first schedules the LCD task (note that the actual task is called LCD for both LCD and GLCD) and the GLCD task then configures the physical GLCD, which can take a few tens or hundreds if ms. When the initialisation is complete it send the event E_LCD_INITIALISED (the event handling code is then in 'hidden'  application_lcd.h), after which use is possible.

It may be easiest to copy the code segments from application_lcd.h to application.c so that you have a better overview (?).
Tip - probably the best place to start is in this code:

             if (E_LCD_INITIALISED == ucInputMessage[0]) {

This is the code that handles the event informing that the GLCD is ready. If you comment out the content and insert your own there instead it will allow you to start writing to the display without the demo application starting.


Regards

Mark

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #22 on: May 22, 2010, 03:00:01 AM »
Thanks for pointing out the GLCD thing. I think I'm much closer to getting this to work.

A while back I modified if (E_LCD_INITIALISED == ucInputMessage[0]) { to show a custom splash screen, I also modified else if (E_LCD_READY == ucInputMessage[0]) { to include another small chunk of text, which I believe indicates it's initialized and working normal. Right now my key problem is that I'm not able to correctly initialize the struct in application.c Closest I've been able to get this struct setup is at the top of fnApplication, I've tried it closer to my code lower down the page, but it failed to compile.

Code: [Select]
extern void fnApplication(TTASKTABLE *ptrTaskTable)
{
//#include "config.h"
//#include "application_lcd.h"                                             // {46} LCD tests
typedef struct stGLCD_TEXT_POSITION {
unsigned char  ucMode;
unsigned short usX;
unsigned short usY;
unsigned char  ucFont;
//} GLCD_TEXT_POSITION;
} text_pos;

Lower in that function, this is how I have it drafted.
Code: [Select]
#define _PORT_NMI_CHECK                                                  // {53}
    #include "Port_Interrupts.h"                                         // port interrupt timer interrupt event handling - ranges
#undef _PORT_NMI_CHECK

//8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888
//8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888
//8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888
//8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888
//8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888

//    GLCD_TEXT_POSITION text_pos;// = {PAINT_LIGHT, 2, 0, FONT_NINE_DOT};
if (E_LCD_READY == ucInputMessage[0]) {
//typedef struct stGLCD_TEXT_POSITION {
// unsigned char  ucMode;
// unsigned short usX;
// unsigned short usY;
// unsigned char  ucFont;
//} text_pos;

text_pos.ucMode = PAINT_LIGHT;
text_pos.usX = 2;
text_pos.usY = 45;
text_pos.ucFont = (FONT_FIVE_DOT);
//text_pos.ucMode = (REDRAW | GIVE_ACK);                   // an ack is requested when this has been completely displayed
    fnDoLCD_text(&text_pos, "Starting...");
}
}

extern void fnSetDefaultNetwork(NETWORK_PARAMETERS *ptrNetPars)
You can see the declaration of text_pos is currently commented out in this location, I've tried putting it at the beginning of this file, at the beginning of the function, and some other places. Where it currently resides, is the only place I can get it to compile without generating syntax errors. However I get these lines, so it appears I'm not declaring it correctly.
Code: [Select]
c:\utaskerv1.4_lpc\applications\utaskerv1.4\application.c(816) : error C2143: syntax error : missing ';' before '.'
c:\utaskerv1.4_lpc\applications\utaskerv1.4\application.c(817) : error C2275: 'text_pos' : illegal use of this type as an expression
        c:\utaskerv1.4_lpc\applications\utaskerv1.4\application.c(517) : see declaration of 'text_pos'
I've also tried GLCD_TEXT_POSITION like how it was done in application_lcd.h. However, these attempts flopped. Right now and the most common way it flops is with a message very similar to those syntax messages.

There's apparently something I don't understand about the syntax formating. I think it's getting closer, but I'm still snagged on something.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3068
    • View Profile
    • uTasker
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #23 on: May 24, 2010, 08:32:27 PM »
Hi

GLCD_TEXT_POSITION is defined in glcd.h.

As long as this is linked, which should always be the case via config.h, you shouldn't need to add an equivalent such typedef in any of the files. Just make sure that any new code is not before the include of config.h.

Regards

Mark


Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #24 on: May 25, 2010, 12:23:30 PM »
I had done several tests that I felt I had correctly removed. Basically learning curve attempts that I then commented out. So I copied that old dir to a new name, and started over. At this point, I've changed some defines in config.h, change the splash screen and initialized screen in application_lcd.h and added this new code to applicaiton.c. I also made a backup copy of the basic config for my board and activated the LCD, so I can get back to a copy I haven't beat to bloody heck.

I found the same error message, but then I moved GLCD_TEXT_POSITION line into the if statement, and all is happy now. I don't know why that might have been the case, I don't see why it wouldn't be able to be stated one line higher in the code, but I guess it can't be done that way. I then found what appears to be some kind of conflict with fnDoLCD_text in both the initialized application_LCD.h code and my application.c code. So I commented out the initialized code in application_LCD.h.

Now that I'm running the LCD from applicaiton.c instead of the .h files, I should be good to try SPI com's. 
So the next step is to copy spi_flash_lpc_atmel.h, get it included while working in application.c then modify it for access to my proto board.

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #25 on: May 26, 2010, 12:34:35 AM »
I'm getting more syntax errors that I don't understand. Here's the current compile problem.
Code: [Select]
Compiling...
application.c
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(57) : error C2143: syntax error : missing ';' before 'type'
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(63) : error C2065: 'SPI_FLASH_Danger' : undeclared identifier
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(63) : error C2109: subscript requires array or pointer type
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(65) : error C2065: 'SPI_FLASH_Danger' : undeclared identifier
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(65) : error C2109: subscript requires array or pointer type
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(67) : warning C4013: 'fnSPI_command' undefined; assuming extern returning int
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(74) : error C2065: 'ucCommand' : undeclared identifier
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(91) : error C2065: 'SPI_FLASH_Danger' : undeclared identifier
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(91) : error C2109: subscript requires array or pointer type
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(94) : error C2065: 'READ_MANUFACTURER_ID' : undeclared identifier
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(94) : error C2051: case expression not constant
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(98) : error C2065: 'ucTxCount' : undeclared identifier
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(101) : error C2065: 'ucCommand' : undeclared identifier
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(102) : error C2065: 'ucTxCount' : undeclared identifier
c:\utaskerv1.4_lpc\applications\utaskerv1.4\spi_acc_lpc_ais226.h(105) : error C2065: 'ucTxCount' : undeclared identifier
c:\utaskerv1.4_lpc\applications\utaskerv1.4\application.c(797) : error C2143: syntax error : missing ')' before 'constant'
c:\utaskerv1.4_lpc\applications\utaskerv1.4\application.c(797) : error C2143: syntax error : missing '{' before 'constant'
c:\utaskerv1.4_lpc\applications\utaskerv1.4\application.c(797) : error C2059: syntax error : '<Unknown>'
c:\utaskerv1.4_lpc\applications\utaskerv1.4\application.c(797) : error C2059: syntax error : ')'
c:\utaskerv1.4_lpc\applications\utaskerv1.4\application.c(800) : error C2059: syntax error : 'if'
c:\utaskerv1.4_lpc\applications\utaskerv1.4\application.c(810) : error C2059: syntax error : '}'
Creating browse information file...
I copied C:\uTaskerV1.4_LPC\Hardware\LPC23XX\spi_flash_lpc_atmel.h and put it under C:\uTaskerV1.4_LPC\Applications\uTaskerV1.4\spi_acc_lpc_AIS226.h such that it was in the include path, and I could get it to actually include. By leaving it in the original directory, the compiler complained it didn't exist.

I added this to the config.h file
Code: [Select]
#define SPI_AIS226and this is the part I have added to application.c under the fnApplication function.
Code: [Select]
#define _PORT_NMI_CHECK                                                  // {53}
    #include "Port_Interrupts.h"                                         // port interrupt timer interrupt event handling - ranges
#undef _PORT_NMI_CHECK
//8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888
//8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888
//#if defined SPI_INTERFACE
#if defined  SPI_AIS226
#include "spi_acc_lpc_AIS226.h"                                         // port interrupt timer interrupt event handling - ranges
#endif
fnSPI_AIS226_command(READ_STATUS_REGISTER); // read busy status register
    fnSPI_AIS226_command(READ_MANUFACTURER_ID); // read MFG register
    //while (SSP0SR & SSP_BSY) {};                                    // wait for transfer to complete
if (E_LCD_READY == ucInputMessage[0]) {
GLCD_TEXT_POSITION text_pos;// = {PAINT_LIGHT, 2, 0, FONT_NINE_DOT};
text_pos.ucMode = PAINT_LIGHT;
text_pos.usX = 2;
text_pos.usY = 40;
text_pos.ucFont = (FONT_FIVE_DOT);
text_pos.ucMode = (REDRAW | GIVE_ACK);                   // an ack is requested when this has been completely displayed
    fnDoLCD_text(&text_pos, "application.c sais hellow");
}
}

extern void fnSetDefaultNetwork(NETWORK_PARAMETERS *ptrNetPars)
Here's a snippet from spi_acc_lpc_ais226.h starting at line 51.
Code: [Select]
#define CONTINUOUS_ARRAY_READ    0xe8


// SPI AIS226 hardware interface
//
//#ifdef SPI_AIS226
static void fnSPI_AIS226_command(unsigned char ucCommand)
{
    #define ulChipSelectLine CS0_LINE  //po6 moso / mosi?
    #define iChipSelect 0
    unsigned char ucTxCount = 3;

    if (SPI_FLASH_Danger[iChipSelect] != 0) {                            // check whether the chip is ready to work, if not wait
        volatile unsigned char ucStatus;
        SPI_FLASH_Danger[iChipSelect] = 0;                               // device will no longer be busy after continuing
        do {
            fnSPI_command(READ_STATUS_REGISTER); // read busy status register
        } while (!(ucStatus & STATUS_READY));                            // until no longer busy
    }
I then hit F7 and get the errors noted on the top of this post. I've tried build clean, just in case, but no dice. I'm baffled about what the syntax issue is. I renamed the functions to make them unique because I found that the compiler "go to declaration" option was bringing me to a different piece of code than what I expected. Getting SPI_FLASH_Danger to include is something I can worry about after this basically compiles.

When in spi_acc_lpc_ais226.h and I right click the fnSPI_AIS226_command function, then "go to definition", I get an error message that notes it's not defined. So I believe there must be a syntax error relative to including this file. However the compiler found it, and produced error messages. It appears that application.c worked OK relative to the include, it also complained about the syntax, not that it couldn't find the fnSPI_AIS226_command function. So I believe that's being found OK. Line 798 in application.c is this line.
Code: [Select]
fnSPI_AIS226_command(READ_STATUS_REGISTER); // read busy status registerI'm not sure what the syntax issues is, or how to get this to compile correctly.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3068
    • View Profile
    • uTasker
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #26 on: May 26, 2010, 01:00:28 AM »
Hi

The file \Hardware\LPC23XX\spi_flash_lpc_atmel.h is the SPI driver to the uFileSystem. This file acts as the Hardware Abstraction Layer between the standard part of the SPI FLASH part and the physical chip.
It is also included in the main HW driver LPC23XX.c because it shares some variables and its subroutines are called from there.

This means that it not possible to put thus code within application.c.

Since the driver that you are adding is for something else there is no advantage of using one of the SPI FLASH drivers directly. What you need to do is add your own code, which can be bases on the same commands.
For example:

..
    CS_CLR_PORT = ulChipSelectLine;                        // assert SS low before starting
    SSPDR_X = ucCommand;                                                 // send command
...
    case CONTINUOUS_ARRAY_READ:                                          // this is a legacy command for compatibility between B and D-devices
        SSPDR_X = (unsigned char)(ulPageNumberOffset >> 16);
        SSPDR_X = (unsigned char)(ulPageNumberOffset >> 8);
        SSPDR_X = (unsigned char)(ulPageNumberOffset);
        SSPDR_X = 0xff;                                                  // 4 dummy bytes needed before the device returns data
        SSPDR_X = 0xff;
        SSPDR_X = 0xff;
        SSPDR_X = 0xff;
...
        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 = ulChipSelectLine;
...


This extract is first sending a single byte (command) to the device that has been selected by the asserted CS line. Then some additional parameters are sent. It shows the use of the 8 byte deep FIFO in the LPC23XX since it is only waiting for the SPI transmission to complete at the end of the sequence, after which it negates the CS line once the transfer has completed.

In your new driver you can use the same commands and techniques to send commands and sequences to your chip and to read data back from your chip. There is probably no advantage in inserting the SPI FLASH driver code as it is.

I suggest first choosing a simple task like writing and reading a byte (or simple sequence) as appropriate for your SPI based device. Then simply add new code to do this in application.c (within the initialisation part so that it is executed only once). Once it is behaving correctly you can add additional sequences as required and possibly add a new *.c file containing such sub-routines to be used by general application code.

Note also that the SPI interface has to be initialised - This is done in static void fnConfigSPIFileSystem(unsigned char ucSpeed) in LPC23XX.c but is conditional on the SPI based uFileSystem. You can simply copy this routine locally for your own use.

Regards

Mark

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #27 on: May 26, 2010, 11:36:11 AM »
Things are moving along nicely now. I have code that I think is almost working and it compiles. I'm doing things a bit more low level than I was doing it before. I'm currently testing it piece by piece. The first piece is to make sure I can assert PO.6 SSEL1 low and high. I see the simulation noted it's was an input. I also found fnConfigSPIFileSystem in LPC23xx.C. It appears I needed to change the CSO line to PO.6 so I modified this line in app_hw_lpc23xx.h.
Code: [Select]
#define CS0_LINE            PORT0_BIT6                                  // CS0 line used when SPI FLASH is enabled
I then copied and modified the apparent setup script like this.
Code: [Select]
POWER_UP(PCSSP_X);                                                   // {10} power up the SSP used
CONFIGURE_SPI_PINS();
CONFIGURE_CS_LINES();
SSPCR1_X = 0;                                                        // ensure disabled (master mode)
SSPCPSR_X = 2;                                                       // set clock prescaler (even prescale 2..254)
SSPCR0_X = (FRS_FREESCALE_SPI | DSS_8_BIT | (0 << SSP_SCR_SHIFT)); // set exact frequency and mode
SSPCR1_X = SSP_SSE;                                                  // enable
Now the simulation notes P0.6 is an output, and it's typically high. Also when I run this command
Code: [Select]
CS_CLR_PORT = PORT0_BIT6;// assert CS low before startingIt changes to low instead of high. So things appear to be moving along nicely. Then I had to go to work.

While I'm posting, is there a way to dim the LCD display? I'm using the 5V supply from my Olimex ARM-USB_OCD programming device. It appears to work fairly good, but it also appears my PC's USB port keeps blinking power. After a while it will reset. I suspect the PC is having trouble providing enough power and backs it down from time to time. Perhaps letting a chip cool down somewhere. If I can decrease the power draw from the LCD, I think that will make this work more reliably. If I can't decrease the power by dimming the display, I can connect it to an external supply, but that's kind of big and clunky, and it would be nice and compact if I can keep using the OCD device.

Thanks for the help mark, you've been a great help.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3068
    • View Profile
    • uTasker
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #28 on: May 26, 2010, 12:26:03 PM »
Hi

When powering via USB the limit is 100mA before the device is enumerated and afterward (depending on mode) up to 500mA can be drawn.
If the 500mA limit is being reached the USB supply will start limiting the current.

To reduce LCD back-light consumption PWM can be used. However there is no PWM driver for the LPC23XX - there is one for the LPC2101..LPC2103 but this is not compatible with the LPC23XX as far as I know. Also adding a serial resistor in the LCD back-light 5V path will reduce its brightness.

Regards

Mark

Offline kb1gtt

  • Jr. Member
  • **
  • Posts: 64
    • View Profile
Re: AIS226DS / MOD-SMB380 I2C evaluation on LPC2378-STK
« Reply #29 on: May 27, 2010, 11:44:01 AM »
The problem is that the ARM-USB-OCD device produces 5V/200mA, my meter claims it's using 204mA. So I've got a noisy supply for sure, and the fact that it works at all shows that the programmer MFG didn't push the spec to the absolute min.

Right now, I can assert the SPI pin high and low after doing the above noted setup. So that's looking good. I can also get the below code to compile.
Code: [Select]
CS_CLR_PORT = CS0_LINE;// assert CS low before starting 0001111 containing 00111010
SSPDR_X = 0x8f;//AIS226 PDF pg 18 SPI read bit 8 = 1, pg 21 "who am I" read only at 0001111 containing 00111010
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;//CS0_LINE;//ulChipSelectLine; // assert CS high end of trans
I believe that code should send 0x8f via SPI, then receive one byte which should contain 0x3A However, I don't know how to get that unsigned long to display on the LCD and I'm not sure I have this buffers and such correct. So what I receive in the unsigned long might be buggered in some manner. Perhaps it might say 8F3A, I'm not exactly sure. Is there a hex2bin until or similar that will let me see raw hex or raw binary?

So I changed gears for a minute and tried the LED PWM thing. I can make that LED PWM pin go low with this line.
Code: [Select]
PINSEL3 |=  1<<21;The simulation window claims that pin is set for PWM. I suspect the screen went blank because the PWM is 0% duty for some reason. So I first wanted to look at PCONP to see if PWM was turned on. I set a break point and tried to figure out how to poke registers to see what's going on inside, but I couldn't figure out how to see whats going on on PCONP or any other register for that matter. Can I see the internal registers in the simulation after a break point?