I came across code from TI written for audio sampling and transmitting for a cc2510 Soc. The application I am trying to develop is similar to this wherein I have to sample the data at certain frequency and send it. I have couple of questions.
Has anyone used this code or ported it to work on wixel based on cc2511? ti.com/apps/docs/litabsmulti … Everything
If not, can this be ported easily and complied in the Wixel environment (SDCC)?
If there has been no attempt, I will post more questions specific to __xdata as I was not clear if there will be a conflict with __xdata as defined in include\cc*.h
I looked at the code in AN064, and the first 80 lines of ioCC2510.h indicate that it only supports IAR and Keil compilers. It should be possible to port it to SDCC, and I have done that kind of porting before, but it was not easy. To do it, you would need to learn many details about the SDCC compiler, the 8051 architecture, and the CC251x, and be ready to debug obscure problems. I do not know of anyone who has ported that particular code. Another difficulty is that the code was written for the CC2510, while the Wixel uses the CC2511, so some register settings would probably need to be changed.
If you want to sample an analog accelerometer with a Wixel, I recommend using the Wireless Tilt Mouse App as a starting point. This app is documented in the Pololu Wixel User’s Guide and its source code can be found in the Wixel SDK.
Thanks David. Have more followup questions if that is ok.
In comparison to audio sampling program, which uses DSM and enables interrupt and sets up sampling, tilt mouse application seems to use polling. Would the audio sampling program be more efficient? In other words, it appears that tilt mouse application does not seem to follow the flow as specified in AN064.
If I need to follow the flowchart of AN064, does the Wixel library support functions or code that can be used without modification? That would be great if I could call a function to initialize the ports, setup the interrupts, DMA etc and only make changes to my app based on what it needs, it would be great! I can understand if generic function modules are not supported as part of library.
One more question that I have is, in Wixel software dev env, how is a function registered for a specific interrupt? It was not obvious in the TI code as well.
Please bear with me if the queries are too basic.
I have not looked carefully at the AN064 design so I do not know how efficient it would be. If you want to follow their flowcharts, I think you would have to write a lot of your own code or port code from AN064 into your Wixel app.
The documentation of interrupts in the SDCC compiler can be found in the “Interrupt Service Routines” section of the compiler’s manual. You can also look at the ISR macro we provide in the Wixel SDK, which is defined and documented in cc2511_map.h. There are several libraries in the Wixel SDK that use the ISR macro to define an ISR.
Thanks so much David for the pointers. Could you also point me to flow chart of tilt mouse app if it is documented?
We do not have a flow chart for the Wireless Tilt Mouse App.
My requirement is as below:
- Sample ADC output for three different ports at a certain frequency
- Transmit a fixed number of samples from the three ports
I will also listen to incoming packets and take certain actions but my problem right now is sampling and tx
When I looked at the code, the wireless tilt mouse code, the ADC registers for P0_1 is read first and right away, ADC register for P0_2 is read. I did not see the initialization of ADCCON registers. Since the ADC registers are being read one after the other, question is since only the current position is of relevance, only the current data is read? It looks like the ADC registers do not retain converted data until read. If only current data is relevant, a fixed number of samples are gathered and sent.
If my assumption is true, how can one sample data from three ports at fixed intervals and get an accurate sense of how the input signal? Which one of the following would be better?
- use dma, which will move a fixed block of data to memory after sampling thru specified number of input ports
- use interrupt (which occurs at regular intervals) then in the interrupt read ADC registers for different ports
- Is it possible at all to use the capture (leading/falling) mode and Read ADC registers for different ports at regular intervals? In this option, I’m thinking, after detecting a change, switch to (2) above to read ADC registers for a certain time period before switching to capture mode?
- Any other option?
Basically, I guess the question is if DMA is not used, do we lose converted data if there is a delay in reading the ADC register? If so what would be the appropriate method to use to capture most data from all three ports?
Figured out some answers to my questions. However, would like to increase the payload size from 18 to 48. What kind of problems will crop up if done so? Also, any pointers on how to increase the payload size will be appreciated.
To increase the payload size, you would need to modify the radio_queue library to have bigger packet buffers. This can be done by changing the definition of RADIO_QUEUE_PAYLOAD_SIZE in libraries/include/radio_queue.h. The Wixel SDK Makefile will automatically recompile the library the next time you build your app. You would also need to make corresponding changes in the app itself to actually send/receive bigger packets.
The radio_queue library allocates 19 buffers for packets, so this change will increase its memory usage by 570 bytes, which increases the risk that you will run out of RAM. Another thing I would be concerned about is that with longer packets, your packet success rate might go down because any error during a long packet could invalidate the entire packet and make the CRC not match.
Please let me know if you have more questions.