[ECOS] SPI usage

[ECOS] SPI usage

[Julien Stéphane]

[-- Attachment #1: Type: text/plain, Size: 49 bytes --]

sorry, here is my code...
 
Thanks!
Stéphane

[-- Attachment #2: spi1.c --]
[-- Type: text/plain, Size: 5058 bytes --]

#include <stdio.h>
#include <cyg/hal/hal_diag.h>
#include <cyg/io/spi.h>
#include <cyg/io/spi_at91.h>
#include <cyg/io/spi_eb55.h>

#define DEV_NUM 4 //default 0
#define CL_POL 1 //default 1
#define CL_PHA 1 //default 0
#define CL_BRATE 3000000 //default 8192000, 2000000?
#define CS_UP_UDLY 1 //default 1
#define CS_DW_UDLY 1 //default 1
#define TR_BT_UDLY 1 //default 1

static cyg_spi_at91_device_t spi_eb55_device CYG_SPI_DEVICE_ON_BUS(0) = 
{
    .spi_device.spi_bus = &cyg_spi_at91_bus.spi_bus,

    .dev_num     = DEV_NUM,          // Device number
    .cl_pol      = CL_POL,           // Clock polarity (0 or 1)
    .cl_pha      = CL_PHA,           // Clock phase (0 or 1)
    .cl_brate    = CL_BRATE,         // Clock baud rate
    .cs_up_udly  = CS_UP_UDLY,       // Delay in usec between CS up and transfer start
    .cs_dw_udly  = CS_DW_UDLY,       // Delay in usec between transfer end and CS down
    .tr_bt_udly  = TR_BT_UDLY        // Delay in usec between two transfers
};

cyg_spi_device *cyg_spi_eb55_device = &spi_eb55_device.spi_device;

void printAT91_SPI_Configuration(cyg_spi_at91_device_t dev);
void setAT91_SPI_Configuration(cyg_spi_at91_device_t *dev);

void cyg_user_start(void)
{
    cyg_uint8 tx_data0, tx_data1, tx_data2, tx_data3;
    cyg_uint8 rx_data;
    
    printf("Entering application !\n");
    hal_diag_led(0x0);
    
    tx_data0=0x0;
    tx_data1=0x1;
    tx_data2=0x90;
    tx_data3=0x15;
    
    //setAT91_SPI_Configuration(cyg_spi_dataflash_dev0);
    
    cyg_spi_tick(cyg_spi_eb55_device, 0, 10);
    
    printf("Sending data...\n");
    printf("1\n");
    cyg_spi_transaction_begin(cyg_spi_eb55_device);
    printf("2\n");
    cyg_spi_transaction_transfer(cyg_spi_eb55_device, 0, 1, &tx_data0, &rx_data, 0);
    printf("3\n");
    //cyg_spi_transaction_tick(cyg_spi_eb55_device, 0, 1);
    printf("4\n");
    cyg_spi_transaction_end(cyg_spi_eb55_device);
    printf("5\n");
    printf("Datas deceived : %i\n",rx_data);
    
    printf("Sending data...\n");
    printf("1\n");
    cyg_spi_transaction_begin(cyg_spi_eb55_device);
    printf("2\n");
    cyg_spi_transaction_transfer(cyg_spi_eb55_device, 0, 1, &tx_data1, &rx_data, 0);
    printf("3\n");
    //cyg_spi_transaction_tick(cyg_spi_eb55_device, 0, 1);
    printf("4\n");
    cyg_spi_transaction_end(cyg_spi_eb55_device);
    printf("5\n");
    printf("Datas deceived : %i\n",rx_data);
    
    printf("Sending data...\n");
    printf("1\n");
    cyg_spi_transaction_begin(cyg_spi_eb55_device);
    printf("2\n");
    cyg_spi_transaction_transfer(cyg_spi_eb55_device, 0, 1, &tx_data2, &rx_data, 0);
    printf("3\n");
    //cyg_spi_transaction_tick(cyg_spi_eb55_device, 0, 1);
    printf("4\n");
    cyg_spi_transaction_end(cyg_spi_eb55_device);
    printf("5\n");
    printf("Datas deceived : %i\n",rx_data);
    
    printf("Sending data...\n");
    printf("1\n");
    cyg_spi_transaction_begin(cyg_spi_eb55_device);
    printf("2\n");
    cyg_spi_transaction_transfer(cyg_spi_eb55_device, 0, 1, &tx_data3, &rx_data, 0);
    printf("3\n");
    //cyg_spi_transaction_tick(cyg_spi_eb55_device, 0, 1);
    printf("4\n");
    cyg_spi_transaction_end(cyg_spi_eb55_device);
    printf("5\n");
    printf("Datas deceived : %i\n",rx_data);
    
    
    //printAT91_SPI_Configuration(*spi_eb55_device);
    
    /*printf("Sending data...\n");
    cyg_spi_transfer(cyg_spi_eb55_device, 0, 1, &tx_data0, &rx_data);
    cyg_spi_tick(cyg_spi_eb55_device, 0, 1);
    printf("Datas deceived : %i\n",rx_data);
    cyg_spi_transfer(cyg_spi_eb55_device, 0, 1, &tx_data1, &rx_data);
    cyg_spi_tick(cyg_spi_eb55_device, 0, 1);
    printf("Datas deceived : %i\n",rx_data);
    cyg_spi_transfer(cyg_spi_eb55_device, 0, 1, &tx_data2, &rx_data);
    //cyg_spi_tick(cyg_spi_eb55_device, 0, 8);
    printf("Datas deceived : %i\n",rx_data);
    cyg_spi_transfer(cyg_spi_eb55_device, 0, 1, &tx_data3, &rx_data);
    //cyg_spi_tick(cyg_spi_eb55_device, 0, 8);
    printf("Datas deceived : %i\n",rx_data);*/
    
    printf("End of main !\n");
    //cyg_thread_exit();
}

void setAT91_SPI_Configuration(cyg_spi_at91_device_t *dev)
{
    printAT91_SPI_Configuration(*dev);
    
    printf("Setting SPI AT91 devince configuration...\n");
    dev->dev_num = DEV_NUM;
    dev->cl_pol = CL_POL;
    dev->cl_pha = CL_PHA;
    dev->cl_brate = CL_BRATE;
    dev->cs_up_udly = CS_UP_UDLY;
    dev->cs_dw_udly = CS_DW_UDLY;
    dev->tr_bt_udly = TR_BT_UDLY;
    printf("Configuration setted.\n");
    
    printAT91_SPI_Configuration(*dev);
}

void printAT91_SPI_Configuration(cyg_spi_at91_device_t dev)
{
    printf("Printing SPI AT91 device configuration :\n");
    printf("-  -------------\n");
    printf("-  dev_number  = %i\n",dev.dev_num);
    printf("-  cl_polarity = %i\n",dev.cl_pol);
    printf("-  cl_phase    = %i\n",dev.cl_pha);
    printf("-  cl_baudrate = %i\n",dev.cl_brate);
    printf("-  cs_up_udly  = %i\n",dev.cs_up_udly);
    printf("-  cs_dw_udly  = %i\n",dev.cs_dw_udly);
    printf("-  tr_br_udly  = %i\n",dev.tr_bt_udly);
    printf("-  -------------\n");
}

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] SPI usage

[Gary Thomas]

Julien Stéphane wrote:
> sorry, here is my code...

The kernel, more importantly, interrupts are not running when
'cyg_user_start()' is called.  That's why your code hangs.

Try putting these functions into 'main()', which is called
with a proper thread environment and the kernel+interrupts
running.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] RE : [ECOS] SPI usage

[Julien Stéphane]

OK it works!! Thank you very much... It's a big reassurance! 

---------------------------------------------------------------

Julien Stéphane wrote:
> sorry, here is my code...

The kernel, more importantly, interrupts are not running when
'cyg_user_start()' is called.  That's why your code hangs.

Try putting these functions into 'main()', which is called
with a proper thread environment and the kernel+interrupts
running.

--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Proper Thread Environment (was Re: [ECOS] SPI usage)

[Chuck McManis]

At 06:56 AM 2/26/2007, Gary Thomas wrote:
 > Try putting these functions into 'main()', which is called
 > with a proper thread environment and the kernel+interrupts
 > running.

I read this and it reminded me of a question I had, if you have a pointer 
I'd be grateful for it.

Basically when I got the HTTP server to run I did so by loading and running 
the httpd1 test program and noting that it worked fine. Then I tried to run 
a "main" program and the web server simultaneously. Basically I added:

So I had this simple bit of code:

----------------------- bit of lame included code ------------------------

#include <stdio.h>
#include <network.h>

/*
  * Note this is for backward compatibility we don't really
  * think that ECOS will call main, it calls cyg_start and
  * that function will call main.
  */
int
main(int argc, char *argv[]) {
         char buf[2048];

         printf("Welcome to the ECOS world!\n");
         while (1) {
                 printf("Enter some text: ");
                 gets(buf);
                 printf("'%s'\n", buf);
         }
         exit (0);
}
/*
  * This was mostly stolen from the HTTPD test
  */

#define STACK_SIZE (8192 + 0x1000)
static char stack[STACK_SIZE];
static cyg_thread thread_data;
static cyg_handle_t thread_handle;

void
user_thread(cyg_addrword_t p) {

         diag_printf("Startup code for ECOS is running...\n");
         init_all_network_interfaces();
/*
         main(1, aa);
*/
}

void
cyg_user_start(void) {
     cyg_thread_create(10,               // Priority - just a number
                       user_thread,      // entry
                       0,                // entry parameter
                       "simple httpd",   // Name
                       &stack[0],         // Stack
                       STACK_SIZE,        // Size
                       &thread_handle,    // Handle
                       &thread_data       // Thread data structure
             );
     cyg_thread_resume(thread_handle);  // Start it
         cyg_scheduler_start();
}
----------------------- end of lame included code ---------------------------

And it has a really weird way of working. Basically what happens is that 
somehow, main() gets called anyway and runs. And frankly I can't figure out 
how it gets called, but even stranger, its interaction with the console 
blocks the networking stack's attempt to print the result of running DHCP 
which keeps the web server from running. (it nicely demonstrates the Rhine 
"feature" of resetting CR0 however if you don't service received packets ;-)

So what I was looking for, and could not find, was sort of a crt0 type file 
which would provide "the proper thread environment + kernel and interrupts 
running" which would include starting a thread by calling 'main()'. That 
way I could keep eCos code fairly segregated from my "application" which 
normally would run as a process on a UNIX or Linux machine.

Thoughts? Should I just create two threads? Will they still interfere with 
each other's use of the console?

--Chuck



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Proper Thread Environment (was Re: [ECOS] SPI usage)

[Gary Thomas]

Chuck McManis wrote:
> At 06:56 AM 2/26/2007, Gary Thomas wrote:
>  > Try putting these functions into 'main()', which is called
>  > with a proper thread environment and the kernel+interrupts
>  > running.
> 
> I read this and it reminded me of a question I had, if you have a 
> pointer I'd be grateful for it.
> 
> Basically when I got the HTTP server to run I did so by loading and 
> running the httpd1 test program and noting that it worked fine. Then I 
> tried to run a "main" program and the web server simultaneously. 
> Basically I added:
> 
> So I had this simple bit of code:
> 
> ----------------------- bit of lame included code ------------------------
> 
> #include <stdio.h>
> #include <network.h>
> 
> /*
>  * Note this is for backward compatibility we don't really
>  * think that ECOS will call main, it calls cyg_start and
>  * that function will call main.
>  */
> int
> main(int argc, char *argv[]) {
>         char buf[2048];
> 
>         printf("Welcome to the ECOS world!\n");
>         while (1) {
>                 printf("Enter some text: ");
>                 gets(buf);
>                 printf("'%s'\n", buf);
>         }
>         exit (0);
> }
> /*
>  * This was mostly stolen from the HTTPD test
>  */
> 
> #define STACK_SIZE (8192 + 0x1000)
> static char stack[STACK_SIZE];
> static cyg_thread thread_data;
> static cyg_handle_t thread_handle;
> 
> void
> user_thread(cyg_addrword_t p) {
> 
>         diag_printf("Startup code for ECOS is running...\n");
>         init_all_network_interfaces();
> /*
>         main(1, aa);
> */
> }
> 
> void
> cyg_user_start(void) {
>     cyg_thread_create(10,               // Priority - just a number
>                       user_thread,      // entry
>                       0,                // entry parameter
>                       "simple httpd",   // Name
>                       &stack[0],         // Stack
>                       STACK_SIZE,        // Size
>                       &thread_handle,    // Handle
>                       &thread_data       // Thread data structure
>             );
>     cyg_thread_resume(thread_handle);  // Start it
>         cyg_scheduler_start();
> }
> ----------------------- end of lame included code 
> ---------------------------
> 
> And it has a really weird way of working. Basically what happens is that 
> somehow, main() gets called anyway and runs. And frankly I can't figure 
> out how it gets called, but even stranger, its interaction with the 
> console blocks the networking stack's attempt to print the result of 
> running DHCP which keeps the web server from running. (it nicely 
> demonstrates the Rhine "feature" of resetting CR0 however if you don't 
> service received packets ;-)
> 
> So what I was looking for, and could not find, was sort of a crt0 type 
> file which would provide "the proper thread environment + kernel and 
> interrupts running" which would include starting a thread by calling 
> 'main()'. That way I could keep eCos code fairly segregated from my 
> "application" which normally would run as a process on a UNIX or Linux 
> machine.
> 
> Thoughts? Should I just create two threads? Will they still interfere 
> with each other's use of the console?

Your problem is not with the form of your code; it's fine.
The problem has to do with the console device.  The default console
device is the debug device, normally provided by RedBoot via the
virtual vector interface.  This interface is not interrupt driven,
thus when you ask to read from it, everything comes to a grinding
halt.  To avoid this, you need to set up your console stream to
an interrupt driven device, which will require enabling the appropriate
serial driver.



-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Proper Thread Environment (was Re: [ECOS] SPI usage)

[Chuck McManis]

Hmm, I'm getting closer, kind of.


At 04:06 AM 2/27/2007, Gary Thomas wrote:
 > Your problem is not with the form of your code; it's fine.
>The problem has to do with the console device.  The default console
>device is the debug device, normally provided by RedBoot via the
>virtual vector interface.  This interface is not interrupt driven,
>thus when you ask to read from it, everything comes to a grinding
>halt.  To avoid this, you need to set up your console stream to
>an interrupt driven device, which will require enabling the appropriate
>serial driver.

So after much trial and tribulation (why would ANYONE layout a 10 pin IDC 
connector for a 9 pin serial port with pin 1 - 1, 2-2, 3-3, etc. It makes 
using off the shelf IDC connectors impossible!) I've got a second serial 
port on my box that I can talk to.

So how do I make *that* stdin/stdout (or their equivalent) for my 
application? I'd like to maintain the flexibility of having the Redboot 
serial port which I can connect to and run GDB on.

The documentation for the serial driver is not much help, I'm looking in 
the C-library documentation at the moment but if someone knows off the top 
of their head, please let me know...

--Chuck



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss