I wish to establish an UDP connection between PC and ARM in cost of minimal resources. I have read manual and FreeRTOS demo. Manual has no example - demo is "all-in-one": is has much more knowledge and much too difficult. I need a VERY simple UDP connection: send and receive single packets from/to the given computer in C++. I have read that ARM has built-in error correction method (CRC). Thanks for any help.
Starter wrote: > I wish to establish an UDP connection between PC and ARM in cost of > minimal resources. Which ARM? > I have read manual and FreeRTOS demo. Manual has no example - demo is > "all-in-one": is has much more knowledge and much too difficult. Which one of the FreeRTOS examples? > I need a VERY simple UDP connection: send and receive single packets > from/to the given computer in C++. I have read that ARM has built-in > error correction method (CRC). Thanks for any help. Maybe some devices offer support for CRC "in hardware" but it depends on the integrated functions of the controller in use.
Martin Thomas wrote: > Starter wrote: >> I wish to establish an UDP connection between PC and ARM in cost of >> minimal resources. > > Which ARM? AT91SAM7S256 > Which one of the FreeRTOS examples? FreeRTOS_4_0_0_armgcc I have develop some programs based on this - but may hardly check it because of limitations (no step mode, no variable check, etc.) >> I need a VERY simple UDP connection: send and receive single packets >> from/to the given computer in C++. I have read that ARM has built-in > Maybe some devices offer support for CRC "in hardware" but it depends on > the integrated functions of the controller in use. First I need transport a packet. Error detection is the next. Which program may use at PC for test?
Maybe I don't get you question right. The AT91SAM7S does not offer any
hardware-support for ethernet. If you need some kind of network
connection addional hardware is also needed.
The network examples from FreeRTOS demonstrate usage of external
ethernet-controllers (i.e. "Wiznet"-modules) or are for devices with
internal ethernet-functions (i.e. AT91SAM7X). Additional software is
needed on the controller for both approaches and depend on the functions
already available in the hardware. In the FreeRTOS examples for
"network" I have seen are based on Adam Dunkel's uIP or lwIP and are
extended with interface-functions to communicate with the "MAC". I have
never used "bare" UDP but TCP/IP so I can not realy help with UDP only.
"FreeRTOS_4_0_0_armgcc" is not an official FreeRTOS distirbution. Maybe
you mean the "stripped" version in the WinARM example-directory. The
latest full version and additional examples are available from
www.freertos.org .
If you'd like to stay with the AT91SAM7S you could connect the
stand-alone ethernet controller from Microchip (ENC*). Should be rather
easy to connect and use and example-applications are available at least
for other controller families.
Examples for AT91SAM7X are already available from freertos.org. While
the AT91SAM7X offeres integrated Ethernet-Functions an additional IC
("PHY") is still needed to connect to the media.
> First I need transport a packet. Error detection is the next.
> Which program may use at PC for test?
I have used netcat for some tests with "TCP/IP over GPRS". Etherreal
might be helpful too.
Martin Thomas wrote: > > > The network examples from FreeRTOS demonstrate usage of external > ethernet-controllers (i.e. "Wiznet"-modules) or are for devices with > internal ethernet-functions (i.e. AT91SAM7X). Additional software is > needed on the controller for both approaches and depend on the functions > already available in the hardware. In the FreeRTOS examples for > "network" I have seen are based on Adam Dunkel's uIP or lwIP and are > extended with interface-functions to communicate with the "MAC". I have > never used "bare" UDP but TCP/IP so I can not realy help with UDP only. > > I have done it with a sam7x from the freertos sample. I have used the UDP and the TCP at the same time without problem. Jonathan
Jonathan Dumaresq wrote: > I have done it with a sam7x from the freertos sample. I have used the > UDP and the TCP at the same time without problem. I have got a solution for this problem but it uses polling technique. I have tried turn it to use interrupt but got some problems: I think ARM EMAC (Ethernet) need acknowledge every interrupt by reading a register at start of interrupt handler: i = AT91C_BASE_AIC->AIC_IVR; and show the end of current interrupt by writing a register: AT91C_BASE_AIC->AIC_EOICR = 0; This is the part of pre-programming interrupt: AT91C_BASE_AIC->AIC_SMR[AT91C_ID_EMAC_B] = AT91C_AIC_PRIOR_HIGHEST | AT91C_AIC_SRCTYPE_POSITIVE_EDGE; // AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL ; // AT91C_AIC_SRCTYPE_INT_POSITIVE_EDGE; I don't know which trigger method to use? I figured method "level" is not good because of permanent call of interrupt (failed handshake, I think). Other methods causes interrupt never run.
Starter wrote: > Jonathan Dumaresq wrote: > >> I have done it with a sam7x from the freertos sample. I have used the >> UDP and the TCP at the same time without problem. > > I have got a solution for this problem but it uses polling technique. > I have tried turn it to use interrupt but got some problems: > > I think ARM EMAC (Ethernet) need acknowledge every interrupt by reading > a register at start of interrupt handler: > i = AT91C_BASE_AIC->AIC_IVR; > > and show the end of current interrupt by writing a register: > AT91C_BASE_AIC->AIC_EOICR = 0; > > This is the part of pre-programming interrupt: > AT91C_BASE_AIC->AIC_SMR[AT91C_ID_EMAC_B] = AT91C_AIC_PRIOR_HIGHEST | > AT91C_AIC_SRCTYPE_POSITIVE_EDGE; > // AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL ; > // AT91C_AIC_SRCTYPE_INT_POSITIVE_EDGE; > I don't know which trigger method to use? I figured method "level" is > not good because of permanent call of interrupt (failed handshake, I > think). > Other methods causes interrupt never run. I don't remember if i use it in interrupt or polling. But the transfer from the MAC to Software is done by DMA. Jonathan
Jonathan Dumaresq wrote: > Starter wrote: >> Jonathan Dumaresq wrote: >> >>> I have done it with a sam7x from the freertos sample. I have used the >>> UDP and the TCP at the same time without problem. I have got a solution for this problem but it has some minor problems. In some cases works correctly. Other cases (exactly same program!) runs but refuses connection. Sometimes it depends on translation (side effects - eg. a new dummy variable exists or not) and program shows true effect only after HW reset (i.e: without reset it works like previous version). So: wrong version is wrong, right version is right after HW reset - all 2 versions work like previous reseted version if it loaded with SW reset. The all difference is the behaviour of MII_BMCR: 2100h and un-writable on false case and works correctly on normal case.
Xx Yy wrote: > Jonathan Dumaresq wrote: >> Starter wrote: >>> Jonathan Dumaresq wrote: >>> >>>> I have done it with a sam7x from the freertos sample. I have used the >>>> UDP and the TCP at the same time without problem. > > I have got a solution for this problem but it has some minor problems. > In some cases works correctly. > Other cases (exactly same program!) runs but refuses connection. > Sometimes it depends on translation (side effects - eg. a new dummy > variable exists or not) and program shows true effect only after HW > reset (i.e: without reset it works like previous version). > So: wrong version is wrong, right version is right after HW reset - > all 2 versions work like previous reseted version if it loaded with SW > reset. > > The all difference is the behaviour of MII_BMCR: 2100h and un-writable > on false case and works correctly on normal case. All your routines are correct? What kind of your physical frontend used? regards
First Second wrote: >> The all difference is the behaviour of MII_BMCR: 2100h and un-writable >> on false case and works correctly on normal case. > > > All your routines are correct? What kind of your physical frontend used? If I use (or not) some dummy variables or change length of a string, program behaviour changes. It is sure variable addressing problem - but how? And how to find it? Very few variables are in this situation... mostly constants. Not stack problem: program runs correctly. Some functions (for PHY setup and connect) called during this process: all work and return correctly - only reg above refuses write and work.
Xx Yy wrote: > First Second wrote: > >>> The all difference is the behaviour of MII_BMCR: 2100h and un-writable >>> on false case and works correctly on normal case. >> >> >> All your routines are correct? What kind of your physical frontend used? > > If I use (or not) some dummy variables or change length of a string, > program behaviour changes. It is sure variable addressing problem - but I located this constant in "lst" file: WRONG version: .ascii ",\011P: \000" 2057 0300 2C09503A 2057 2000 2058 0306 0000 .align 2 2059 .LC46: GOOD version: .ascii ",\011: \000" 2057 0300 2C093A20 2057 00 2058 0305 000000 .align 2 2059 .LC46: All differece is letter "P" - but this is aligned so other parts of program are exactly the same. Final executable file like this. This part of program is at flash area so I don't think overwrite error...
>>>> The all difference is the behaviour of MII_BMCR: 2100h and un-writable >>>> on false case and works correctly on normal case. I have found a possible reason for this behaviour: maybe fiber (optical) mode. At this mode these pins are R/O. I checked pin 24 and 44 which determine this settings at startup: they are correct and NOT fiber settings. Trying SW reset PHY chip - but it seems read these pins only at HW reset.
Xx Yy wrote: >>>>> The all difference is the behaviour of MII_BMCR: 2100h and un-writable >>>>> on false case and works correctly on normal case. > maybe fiber (optical) mode. At this mode these pins are R/O. I have solved this problem: it IS fiber optical mode. It MUST use a weak pull-down resistor to use Ethernet settings. PHY chip reads pin setings ONLY at HW reset. Also maybe SW solution: SW pull-down this pin at start and process later. Ethernet traffic is perfect now at 10Mb/s! Next problem: SAME system is faulty at 100MB/s. All difference is speed settings. Cable is capable this speed. In best case card receives messages correctly and CAN NOT answer. Error message at sending is "Used Bit Read". SAME answer sent correctly at 10Mb/s. There is one sending buffer and interrupt handles this: clear after send immadiately.
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.