We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
hello forum im using uvision V4.6.0.0 with MDK-ARM professional Version:4.60.0.0 toolchain. i want to test RL-TCPnet with LPC1768 micro and DP83848C PHY Transiver (i have designed a board myself as the same as your MCB17xx board). i have loaded your LEDSwitch Example into my micro and it works fine and i can send and recive data through UDP socket and i can control LED in my board. i want to know in this example Ethernet controller works in Polling mode or interrupt mode??? my problem is that im using SPI bus in slave mode with interrupt service routin that i recive some datas from other controller(DSP)continuously and it works too but every time that i recive other packet through LAN my SPI peripheral hangs and dont recive other datas. could you let me know how can i solve this problem? im waiting for your answer. best regards. thanks.
thanks for your answer. but i want to know RL-TCPnet works in polling mode or interrupt mode in LEDSwitch Example??? im using SPI peripheral in LPC1768 in slave mode. every time that master(my DSP) send a word my slave(ARM MCU)go to SPI_ISR and read the SPI data register and then reload it with new data without any delay.but some times master recieve wrong data and i think its because of TCPnet function that pending my SPI service routin.may be TCPnet has a higher priority than SPI???!!! but im not sure TCPnet in LEDswitch Example works in interrupt mode or polling mode! please help me. thanks again
Yes - it is a known problem with traditional SPI that the slave have only a half clock period to react and supply next data to send. One phase of the clock latches in one word to the slave, and next phase of clock the master picks up the first bit of the new word the slave wanted to send.
So if running 100kHz clock frequency, then each clock period is 10us and a symmetrical clock would give 5us for receive interrupt to be serviced to pick up the incomming word and write the new word.
So any interrupt routines or even polled code with critical sections can be enough to fail a transfer. Are you sure that the DSP requires you to make a decision what to send within that half clock cycle and can't use the more advanced transfer modes available?
thanks per i solved my problem. i set the SPI interrupt priority higher than the Ethernet controller interrupt priority so the SPI didnt hang and now it works fine.according to your statements my SPI CLK rate is 12.5Mhz. but master sends data with a 400ns delay(there is 400ns delay between every data) so in slave controller i have enough time to get data and relod it with new data. thanks again.
Do you have nested interrupts? If interrupts aren't nested, then it isn't helping to give a higher prio to one interrupt - that prio is used to select which ISR to handle when you have multiple interrupt sources pending service.
hi again yeah my interrupts are nested and i can change the priority of each interrupt.