[En-Nut-Discussion] SPI master mode Ethernut 5
Sergej Schmidt
schser at hs-pforzheim.de
Fri Dec 12 11:00:39 CET 2014
Hi,
my goal is to connect universal SPI slave devices, so the example you posted Harald doesn't help, unfortunately. Actually i'm using no specific device driver, so if i call:
NutRegisterSpiDevice(NULL, &spiBus1At91, 0);
the OS suspends infinitely.
The code snipping I am actually using is:
NUTSPINODE my_node = { &spiBus1At91, /* Pointer to the bus controller driver. */
NULL, /* Optional pointer to device specific settings. */
500000, /* SPI clock rate. */
3, /* SPI mode. */
8, /* SPI data bits. */
0 /* Chip select index. */
};
int MyInit(void) {
int rc;
rc = (*spiBus1At91.bus_initnode)(&my_node);
if (rc == 0) {
NutEventPost(&spiBus1At91.bus_mutex);
}
return rc;
}
int MyTransfer(uint8_t *buf, int len) {
int rc;
rc = (*spiBus1At91.bus_alloc)(&my_node, 1000);
if (rc == 0) {
rc = (*spiBus1At91.bus_transfer)(&my_node, buf, buf, len);
}
(*spiBus1At91.bus_release)(&my_node);
return rc;
}
int main(void) {
uint32_t baud = 115200; //baudrate for UART interface
uint8_t transfer = 0x55; //example message
int result = -1;
/*
* Register the UART device, open it, assign stdout to it and set
* the baudrate.
*/
NutRegisterDevice(&DEV_CONSOLE, 0, 0);
freopen(DEV_CONSOLE.dev_name, "w", stdout);
_ioctl(_fileno(stdout), UART_SETSPEED, &baud);
NutRegisterSpiDevice(NULL, &spiBus1At91, 0);
result = At91SpiSetup(&my_node);
printf("\nSPI setup result: %i", result);
result = At91Spi1ChipSelect(0, 1);
printf("\nSPI cs result: %i", result);
result = At91SpiBusNodeInit(&my_node);
printf("\nSPI init result: %i", result);
result = At91SpiBusTransfer(&my_node, &transfer, NULL, 1);
printf("\nSPI Transfer result: %i", result);
return 0;
}
My ChipSelect configuration is Pin 39,41,43,45 for CS0-CS3.
When the line:
NutRegisterSpiDevice(NULL, &spiBus1At91, 0);
is commented, the OS is running but theres no signal at i/o Pins.
Regards,
Sergej
-----Ursprüngliche Nachricht-----
Von: en-nut-discussion-bounces at egnite.de im Auftrag von en-nut-discussion-request at egnite.de
Gesendet: Di 09.12.2014 12:00
An: en-nut-discussion at egnite.de
Betreff: En-Nut-Discussion Digest, Vol 134, Issue 5
Send En-Nut-Discussion mailing list submissions to
en-nut-discussion at egnite.de
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
or, via email, send a message with subject or body 'help' to
en-nut-discussion-request at egnite.de
You can reach the person managing the list at
en-nut-discussion-owner at egnite.de
When replying, please edit your Subject line so it is more specific
than "Re: Contents of En-Nut-Discussion digest..."
Today's Topics:
1. Re: Extra packet in ethernet packet (Harald Kipp)
2. Re: SPI master mode Ethernut 5 (Harald Kipp)
----------------------------------------------------------------------
Message: 1
Date: Mon, 08 Dec 2014 20:05:18 +0100
From: Harald Kipp <harald.kipp at egnite.de>
To: "Ethernut User Chat (English)" <en-nut-discussion at egnite.de>
Subject: Re: [En-Nut-Discussion] Extra packet in ethernet packet
Message-ID: <5485F66E.2040908 at egnite.de>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
On 05.12.2014 20:51, Philipp Burch wrote:
> On 05.12.2014 20:42, Mingshu Wang wrote:
>> I found an issue in one of our products that is using Nut/OS 4.8.7 and AT91SAM7X256. If I send a packet with odd number of characters to my computer, an extra byte is padded at the end. Wireshark interprets it as "VSS-Monitoring Ethernet trailer". If the packet size is an even number, everything is fine. Most applications can handle this packet correctly. But some applications don't read the length in the header. They just process all characters in the packet and think this is a wrong message.
>
> In the EmacPutPacket() function in nut/arch/arm/dev/atmel/at91_emac.c,
> there is this code:
>
> sz += nb->nb_dl.sz;
> if (sz & 1) {
> sz++;
> }
Applications must always honor the lengths provided in the headers. The
minimum size of an Ethernet payload is 46 octets
http://wiki.wireshark.org/Ethernet
http://tools.ietf.org/html/rfc894
So, padding may always occur. Most Ethernet controllers add padding
bytes automatically.
Some Ethernet controllers cannot transmit odd number of bytes. As far as
I can see, the AT91 EMAC doesn't have this limitation. I guess, that the
code snippet above had been inherited from another driver.
Regards,
Harald
------------------------------
Message: 2
Date: Mon, 08 Dec 2014 20:27:16 +0100
From: Harald Kipp <harald.kipp at egnite.de>
To: "Ethernut User Chat (English)" <en-nut-discussion at egnite.de>
Subject: Re: [En-Nut-Discussion] SPI master mode Ethernut 5
Message-ID: <5485FB94.2070307 at egnite.de>
Content-Type: text/plain; charset=ISO-8859-1
Hi Sergej,
On 04.12.2014 12:36, Sergej Schmidt wrote:
> did anyone tested SPI transfer on ethernut 5 yet?
Without SPI, Ethernut 5 wouldn't be able to access its Dataflash and
even SD-Card access may be based on the SPI driver. So, in general I'm
quite sure, that is works.
Are you sure you are on the right bus, Ethernut 5 has 2 of them.
> The official ethernut spi support example described in http://www.ethernut.de/en/documents/ntn-6_spi.html
> is a bit old or i've made an error by using this example (low level mode). Nevertheless i've got no signal
> on my MOSI and SPCK line. A code example would be very useful.
Although a bit old, it is still the way to go. For Ethernut 5 and EIR use
NutRegisterSpiDevice(&devSpiBlkAt45d0, &spiBus0At91, 0);
for the first SPI0 or
NutRegisterSpiDevice(&devSpiBlkAt45d0, &spiBus1At91, 0);
for the second SPI1. Only the latter is available at the expansion port.
Btw. the app/ediconf sample will print some useful information about
your SPI configuration. It's done for SPI0, but can be modified for SPI1
in order to see, what's actually configured.
I'm a bit short in time right now. If the above doesn't help, I can
create a simple example tomorrow.
Regards,
Harald
------------------------------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
End of En-Nut-Discussion Digest, Vol 134, Issue 5
*************************************************
More information about the En-Nut-Discussion
mailing list