Suggestions on new tutorials?
I would like to ask you guys, the readers of my tutorials, what you would like to see as the next tut? I'm not limiting it to wireless stuff, although that's certainly fair game. If there are any particular applications that you have been wanting to dive into and take a look at, but aren't quite sure how to do, suggest them here. Just a few I've thought about are remote controls, wireless audio transmitter (high difficulty level), sensor networks (also pretty tough), and a few others. Feel free to post comments on this thread (anyone can post) and let me know what you'd like to see!
Labels: audio, avr, lpc2148, misc, nrf24l01, pic, security, tutorials, user submissions
posted by brennen @ 12:21 AM
28 Comments
28 Comments:
How about a true USB node (i.e. not just RS232-over-USB using an FT232) which works on Mac and Linux, not just Windows? I'd love to see a working skeleton where we can take the basic code and add our app-specific functions. If you could do something like that for a bunch of different micros (not just PIC and LPC), I bet you'd have a lot of people interested. (Actually, I'd really like to see your existing tutorials ported to AVR and Freescale, too.)
Unfortunately, I don't have any access to a Mac, but I do have a Linux partition on my machine. USB is definitely an interesting topic, and I think that would be a good thing to get into for the next project. However, the reason that I do stuff for PIC and LPC chips is that they are the chips that I have on hand. If others would like to do ports of my tutorials to other architectures, they are more than welcome to do so and I will post them on the website. Also, any guest tutorials are very welcome!
Nice site, well layed out. How about an e-mail notification when a new tut is available.
Id like to see some more multimedia apps based on higher end ARMs. I picked up some virtual cogs (virtualcogs.com) from sparkfun and need some inspiration!
"How about an e-mail notification when a new tut is available."
That is a great idea. If anybody would like to fill me in on how to create a mailing list (other than just doing it from my own personal email), that would be great (this site is hosted on GoDaddy if that helps).
"Id like to see some more multimedia apps based on higher end ARMs. I picked up some virtual cogs (virtualcogs.com) from sparkfun and need some inspiration!"
I am actually doing some work on an EP9301 board from Olimex right now. I would like to do some tutorials with it, but it's coming along very slowly because I have absolutely no Linux development experience and that's what is running on the chip. More on that later...
Very comprehensive. could you please write a section of code about SPI without using the special header file (SPI) to perform some simple tasks? Like some things you said in the Tutorial 0. ^_^
I'm not totally sure what you mean by "simple tasks." It should be easy for you to take the SPI code from the tutorials to adapt it to your own uses (moreso the PIC code than the LPC2148 code, though, since I mainly used "magic" numbers in the SPI initialization for the 2148 rather than #define's).
The simple tasks i am refering to it's like read a data with 5 bytes length from the transceiver buffer to the micro buffer. I am doing my school project, so i am afraid that i may not be able to understand your header file due to time constrain.
example :
TX:
CE = 0;
CSN = 0;
SPI0DAT = xxxx;
while(SPIF == 0)
{
}
SPIF = 0;
SPI0DAT = xxxx;
while(SPIF == 0)
{
}
SPIF = 0;
CSN = 1;
CE = 1;
Could you give me some examples for the "xxxx" and thier purposes.
Thanks very much.
The PIC code that interfaces the SPI is very simple to understand, and it's not in the scope of this post for me to help you with your homework. It's up to you to make time to get your work done. My suggestion is to ask your professor or TA for more assistance. Sorry.
Thanks anyway. The tutorial really gives me a better and clarified understanding on this device.
I am here again. i am annoying and i know. haha!! This time i just to clarify something can be describe with a yes / no.
For the enhanced shockburst enabled nRF24L01.
The ACTIVATE command follow by 0x73
Q: Is 0x73 follow by a W_REGISTER with Map Address and then the intended data?
I actually haven't tried out the new features that were documented in the new version of the spec. I'll get around to playing with them and adding them to the library, but at this point, you probably already know more than I do about the ACTIVATE command and the features it enables.
Concerning the first post some surreptitious advertising at its best:
True USB mode is already available in the nRF24L01 enabled open source project OpenBeacon USB at http://www.openbeacon.org . It appears as a virtual serial port in Linux and in Windows - unluckily not yet on MAC.
At the same website a neat & tiny button cell powered PIC16F684 + nRF24L01 platform is available.
Both hardware design are available under CC license - both Firmware sources under GPL license.
Suggestion:
I would love to see a tutorial on the nRF2401 with avr in assembly. Most of the tutorials are in C which I cannot do.
BTW, good, informative site! keep up the good work!
Unfortuantely, you won't be seeing any assembly here. While assembly is great for doing things in really time critical areas, most people avoid assembly because it is not portable at all. In other words, I would have to write the 24L01 library from scratch in assembly (not happening), and then it would only work for the AVR chips compatible with that assembly language.
My suggestion is to grab a good book in C and study up. There are tons and tons of sites online to help you with C, and there are also free compilers for the AVR to use. Except for pointers, C is not a difficult language to learn if you've done any programming before.
If you cannot post asm code how about the compiled hex file for avr's?
At least then I can disassemble it and find out what I am doing wrong with my code.
I will never learn C coding because I believe that the compiler does it all, and you can't know what is going on.
I tried a number of times to compile sample c source and it was a nightmare with many errors. Particularly errors involving the incorrect paths and such.
I support Brennen's position. Although assembly is extremely useful in some situations, and I myself have used it quite a bit, it just isn't useful at all in the scope of portability.
And not just portability between AVR, ARM, PIC, etc, but even just to port it from one AVR circuit to the next where the microcontroller is configured differently.
Working just in assembly is fine. If it works for you, then why not? But I feel your attitude needs some adjusting. In this kind of business you can't ever lock yourself in to one idea or technology. You'll be left far behind.
Yes, the C compiler may be doing quite a lot of work for you. But you're still the person that tells the compiler what to do. You're still in control. You've still got full control over the code that the compiler produces. Many C compilers will still allow you to use assembly in your C programs. Some C compilers will show you the assembly code that it produces from your C source code and allow you to fine tune that assembly code.
Personally, I don't really understand what your problem with C is. Maybe you just haven't really looked at it enough with the right attitude.
I'm sorry if I come across in a hostile manner - that's not really my intention (although deep down I probably don't mind so much!). I'd just like to support Brennen in the wonderful work that he is doing. If only I had the time and resources I would have absolutely loved to do the same thing.
If you have GNUARM and Cygwin installed on your machine and your environment variables are set up properly, you should be able to compile the code for the LPC2148. However, you will not be compiling it for an AVR because the source is set up to compile for either the LPC2148 or the PIC18F452 depending on which version you download. I don't have any AVR boards, and at this point I don't really have much need for them as I have an 8-bit platform and a 32-bit platform already working. I am always willing to upload ports or translations of the library or tutorials to the site, however, and I know many readers are using AVR processors.
I really don't think I could have made a better argument for using a high-level language than how Eduard put it. It is my opinion that every embedded programmer should at least have some familiarity with C since it is far and away the most common language you are going to find for embedded systems. Knowing assembly is great, but it only works for the processor you're using it on and when you change processors, you are stuck learning a whole new instruction set. Not true for C.
As Eduard mentioned, most C compilers support inline assembly (any gcc compiler should do this). This is great for doing things in time critical areas. However, in general code, I personally see no advantage to adding complexity and lack of readability to using assembly. That's just my $0.02.
Ultimately, this site is about portability, and I want the library/tutorials to be easily portable to any system that a reader would like. That means that a high-level language is the only choice.
As far as a hex file, I don't have an AVR compiler on my machine, unfortunately, so I can't help you there. It's really not that difficult to get a compiler installed and working. There are plenty of sites that will help you do just this.
In the end, if you like programming in assembly, the by all means go for it. Just keep in mind that you're making your life more difficult because you won't be able to understand C coded programs nor will you be able to share code with people who aren't using your exact architecture and don't know your assembly language.
I also want to thank you guys for the compliments on the site. I have put in a lot of work and I really appreciate that you guys like the site and the tutorials. As I get some free time, I am going to start working on some more tutorials.
Hey, what about using graphical LCD Displays, you could wire up the micro controller with the nrf24l01 and use it like a portable security monitor.
I've actually considered doing something with graphical displays. I bought a few from EIO a while back, but never got around to playing with them. Once I get the nRF24LU1 stuff up and going, I may work on that. Thanks for the suggestion!
What about doing something along the lines of a mesh network, multi hop etc.
And about the NRF24AP1?
I was reading about it and the ant protocol but I'm afraid of buying it and could not put it to work (here in brazil it's veeery expensive).
Hi Brennen. I am currently doing research in flying robotics (check out http://lis.epfl.ch/research/projects/microflyers/), and am using your library with the nRF to set up a wireless link between the robot, a base-station for data-logging and an RC controller for piloting the robot. I used to use Bluetooth, but have switched to the nRF because of its tiny size.
Since all three devices can act as masters, I am trying to setup a protocol that uses handshaking between the different devices to allow each of them to become the master of the link. Do you have any experience using these chips to setup a proper bi-directional link?
This could make for an interesting tutorial, and once I have it figured out I would be glad to send you the source code.
Hey, i'm having to use a 14 bit chip (16F628A) and having to write my own code, is it possible to give some guide lines on testing the interface to see if the nRF 24l01 chips work?
Thanks
Anonymous said...
What about doing something along the lines of a mesh network, multi hop etc.
January 16, 2008 2:35 AM
That would definitely be a cool project. I may try this some time in the future.
Tobias said...
And about the NRF24AP1?
I was reading about it and the ant protocol but I'm afraid of buying it and could not put it to work (here in brazil it's veeery expensive).
April 3, 2008 6:49 PM
Cool looking chip. I may make a breakout of this since it's not an easy breakout to find that's relatively affordable.
Adam said...
Hi Brennen. I am currently doing research in flying robotics (check out http://lis.epfl.ch/research/projects/microflyers/), and am using your library with the nRF to set up a wireless link between the robot, a base-station for data-logging and an RC controller for piloting the robot. I used to use Bluetooth, but have switched to the nRF because of its tiny size.
Since all three devices can act as masters, I am trying to setup a protocol that uses handshaking between the different devices to allow each of them to become the master of the link. Do you have any experience using these chips to setup a proper bi-directional link?
This could make for an interesting tutorial, and once I have it figured out I would be glad to send you the source code.
May 6, 2008 5:20 AM
Technically my simplest tutorial (Tutorial 1) was a bidirectional link between two 24L01's. To add a third would be more complicated, but it goes back to the idea of the mesh network. Cool thing to try out once I get some free time. If you have any success, I would definitely like to post your work on the site!
Smartie_on_computer said...
Hey, i'm having to use a 14 bit chip (16F628A) and having to write my own code, is it possible to give some guide lines on testing the interface to see if the nRF 24l01 chips work?
Thanks
May 6, 2008 3:40 PM
If you have an oscilloscope, you just need to watch the lines to make sure they are outputting the right values.
If not, don't connect the 24L01 to the PIC. Write test programs to use a multimeter to see if you can turn on and off the pins that act as your CSN and CE lines. Verify that SCK and SDO are setup as outputs and SDI is setup as an input. Then short SDO and SDI together and make sure that you can write values 0 through 255 out SDO and read the same value you sent at SDI. If you have that, then you would just need to write your delay functions, and you should be ready to test it with my library.
Any tutorial on the nRF24LE1 is appreciated.
Great tutorials!
Recently I tried to setup the nrf24L01 to have the possibility to use the acknowledge with payload feature of the chip. It is useful when you need to know if the Rx has received a message and that Rx wants to add something to that message. Then there is no need to setup Rx in transmit mode for replying. It is enough to setup the ack payload buffer and that data will be sent with the ACK packet back to Tx.
You can search the pdf for nrf24L01 for the keyword "W_ACK_PAYLOAD". However, when I setup the thing as it says in the document, I still can't get the ack payload to work.
It would be great to have a tutorial which describes this feature and shows a code example for how to use it.
Thanks and keep up the good work.
ZR
I would like to see the W_ACK_PAYLOAD implemented with an example. It would not take too long to do I guess. It would allow a bidirectional link with minimal overhead and possibly a nice data rate.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home