I am trying to get one Xbee to talk to another. I understand that I can use putc to broadcast to all Xbees on a network but I want to target one specifically. I know that I need to use the hardware address on the XBee to do this and by using something called AT Commands mode but I don't think I understand it. For example, I have seen that to get into AT Commands mode I need to send '+++', however, I don't understand what to do. I tried this:
xbee.printf('+++');
but don't know where to look for some kind of message in response.
I don't understand this mode and can't seem to find anything which gives me an example for my situation or a relevant one.
I am using a normal Xbee on an FRDM-K64F.
Worked it out.
To do this, you first need to do:
xbee.printf("xxx");
This puts you into AT Command mode and you can then run AT Commands. You need to wait at least 1 second before and after going into AT Command mode for this to work:
wait(1)
To send to a specific Xbee, you need it's 16-bit address and this can be found from the underside of the Xbee (although there is an AT Command to get this). The first 8-bits are the Xbee's high address (this is the same for all Xbees) and the second is it's low address and you need to set both of these using AT Commands before sending to the specific Xbee will work. To set these you must do the following:
xbee.printf("atdh 0013A200\n\r");
xbee.printf("atdl 12345678\n\r");
You must do the \n\r part as this simulates an Enter button press which is needed to actually run the command.
The atdh command sets the high address and the atdl command sets the low address. Once this is done, your sending Xbee will be configured to send to a specific Xbee and will not broadcast to all on the network. So when you now do:
xbee.putc('Y');
it will go to the Xbee who's address you have set.
You may have to wait 10 seconds after running those commands because I don't think I/O works in AT Command mode (I have not worked out yet how to exit AT Command mode yet but will update when I do).
Related
A bit of a strange question here, but I'm wondering if there's any standard way to set the baud rate of non-serial interfaces, e.g. an SSH session to a Linux machine?
There are lots of examples of setting the baud rate for serial ttys in Linux, such as this:
struct termios slow;
tcgetattr(STDOUT_FILENO, &slow);
cfsetispeed(&slow, B1200);
cfsetospeed(&slow, B1200);
tcsetattr(STDOUT_FILENO, TCSANOW, &slow);
However, I've never been able to get any to work for me when working with ttys like an SSH connection. I'm not sure if it's just not supposed to work in those contexts, or if there's something else/different that needs to be done here.
The example compiles and runs just fine, but everything printed out to the screen is still at full speed. I've confirmed none of the functions runs into any issues, tried different baud rates, tried STDIN and STDOUT, set different flags in some of the examples floating around - none of that has any effect.
The stty command itself also seems to have no effect.
Is it possible to set the baud rate of an SSH session in the first place? Maybe it's not, and that's why it doesn't work.
If not, is there any way to achieve this? Short of a brute force solution like:
for each char in str:
print char
sleep 0.03
In case it wasn't obvious from the question, no, there's not a super useful application of this, but sometimes it's useful to simulate different baud rates without actually using a physical serial connection or anything like that, and it would be useful to handle the connection speed at the terminal layer or in the kernel somehow, rather than doing something dumb like printing everything out character by character. Can this be accomplished?
This must be accomplished entirely server-side (the connected SSH client should not have to do anything special), and the speed must be able to be set on demand just like with cfsetospeed.
One solution that does work is to use a pseudoterminal, which relays output from the PTY master to the actual file descriptor (e.g. a socket) one character at a time, with usleep inbetween each call to write.
However, this results in doing dozens to hundreds of calls to write() per second, which uses quite a bit of CPU. I doubt there's any way to space out writing a buffer gradually in the kernel, so this kind of system call overhead might be unavoidable, but if there was a more efficient way to do this, that would be great.
Not sure how to word the title, but what I'm trying to do is test my micro controller with my Linux PC to ensure data is correct. After hours of searching, I found out that the stty command can change how data is managed through the serial port and it turned out that by default if xon or xoff characters are received from the port, they don't get displayed. At first I thought my computer was too slow that I was losing characters at 57.6Kbps but that wasn't the case.
Back in the day when I was playing with the serial mouse in QuickBasic for DOS, I could use this command to start the serial port:
OPEN "com1:1200,n,7,1,op0" for binary as #1
So what I want to do now is create something simple in C that would allow me to open up the serial port in the rawest mode possible. I want it so that whatever data I give to it is sent to it unmodified. I also want to receive data unmodified. so if the controller decides to send a character the PC would recognize as a special control code, I still want to see the character, not have the PC go funny just because a character matches a control code.
One idea I thought of is to create a fork to the stty program and use nearly every (50+?) parameters added to the program making the requirement of program stack space a bit high.
Another idea I thought of is to do direct I/O with the port address itself (using inb and outb) but I'm not sure if the kernel would run those commands through anything else before the data reaches the port, but I'd rather use that as a last option in case I ever replace my computer and the serial port value changes (or becomes a serial port made through USB to serial converter hardware).
so rather than inb and outb and those variants (like inw), and without executing stty with specifying 50+ parameters in my program, is there a function in C I can use (without requiring a special library not included with a standard linux distribution) to force the serial port device as a raw device so I can do any I/O on it without the kernel modifying or dropping data?
Here is the setup. Arduino #1 has a w5100 ethernet shield running a webserver accepting GET strings. It then parses out the data and sends it wirelessly to the other nodes using nRF24l10 transceivers. I'm using maniacbug's RF24 and RF24Network libraries. Also due to having the ethernet shield and the wireless I had to use a modified RF24 for the base that supports soft SPI.
Arduino #2 is just the nRF24L10.
What is working. Sending GET's to Arduino #1 works. It parses the information. It then calls the send routine and that says it's ok.
On arduino #2 I get a "Received:" printout but no message. I'm not sure what is wrong. The code is taken right from maniacbug's tx and rx example. Except I had to convert my sendString to a char to send.
I'm wondering if it's one of the following things but I'm not quite sure how to debug.
That the addition of the RF24Network library broke the softSPI. I've been very careful to remove one libray and add the other when I compile. Though if this were the case I'd never see the "Received:" would i?
It doesn't like my conversion from string to char?
Here is the code.
Base Station: http://pastebin.com/Ehy8pz4Z
Receiver : http://pastebin.com/2mz9FjsR
Here is the modified RF24+ softspi library. https://github.com/shnae/rf24_plus_softSPI if that helps.
I don't think just adding the nrf24network library breaks that but since it calls SPI.begin() it might. That's beyond my skillset..
So as it turns out you need to put network.update(); in loop.... If you only call it per request like I did it will not work. Hence the //do this regularly comment that you see for this.
I am trying to initiate a spi communication between an omap processor an sam4l one. I have configured spi protocol and omap is the master. Now what I see is the test data I am sending is correctly reaching on sam4l and I can see the isr is printing that data. Using more printf here and there in isr makes the operation happen and the respective operation happens, but if I remove all printfs I can't see any operation happening. What can be the cause of this anomaly? Is it a usual case of wrong frequency settings or something?
If code is needed I will post that too but its big.
Thanks
I think you are trying to print message in driver.
As printing message on console with slow down your driver, it may behave slowly and your driver work well.
Use pr_info() for debug and change setting to not come message on console by editing /proc/sys/kernel/printk to 4 4 1 7
-> It will store debug message in buffer.
-> Driver not slow down because of printing message on screen.
-> And you can see it by typing dmesg command later.
Then find orignal problem which may cause error.
If a routine works with printf "here and there" and not otherwise, almostcertainly the problem is that there are timing issues. As a trivial example, let's say you write to an SPI flash and then check its content. The flash memory write will take some times, so if you check immediately, the data would not be valid, but if you insert a printf call in between, it may have taken enough time that the read back is now valid.
During sending ATA commands I found several classifications. For example, first one - we can divide the commands to Data-In, Data-Out and Non-Data commands. Another classification can be that there are 48bit commands and 28bit comands. First ones are for the disks, which are larger that 120Gb.
The question is: do I need to set up some values that the disk will know that it get the 48bit command or not? For example, if I send SCSI command with ATA through SATL or ATA PASS THROUGH command through the controller.
During the research it was found that every controller has its own specificities depending on the driver. That is why implementation of ATA PASS THROUGH commands are so difficult work.
Through reading the Linux driver and checking what structures are sent with ioctl it is possible to figure out if it is 28 or 48 bit command.
Moreover, it is also quite important to check how new is the software, because 48-bit Logical Block Addressing (LBA) was introduced in 2006 in ATA-6 standard. Most probably nowadays all the controllers supports 48-bit command set, but still you should check if the controller supports it.
So, the answer to this question strongly depends on the using controller.