Finding the size was uneccessarily hard. To do it hold the shift key when you click build in the arduino tool. This will show the actual commands and build directory. Go there are use avr-size on the resulting binary, elf file not hex. It prints 3 number, code size, bss (uninitialized data), initialized data. If you did not know you had avr-size on your system, there is a copy in the arduino installation. It is part of the gcc port. I will download the code and give it a try as soon as I can find it. Account info sent to icing.
Oh if you need avr-nm should dump the symbol table that can give you size ideas if you read it carefully. You can see the next address if you are careful an compute allocated size without using the debugger.
just committed my own a4 as R7.
Forgot to add the commit comments (apologies, but I don’t seem to be able to add them afterwards )
If anyone has questions as to the how and why, feel free. Btw: within a week or so I hope to have a second set of cabling to connect my second rfBee so I can start to test the radio functionality as well
Then on the setup of the project on google code, I’m no SVN expert, but it seems like we should have a main trunk and then a 1.1 branch, once we finalize 1.1 development we merge this in the main trunk and start a 1.2 cycle.
@Rich:
Many thanks for the info, we might suggest the Arduino crew to add an item to the tool menu
Do you already have code to put the CommandTable into progmem ? If not, I’ll give it a go next week.
just checked in the new version with the atCommands[] and baudRateTable[] into PROGMEM.
Works like a charm, but requires a little more work when you want to add a new command.
You now need to add a label and an entry in the command table.
Tried to get it to work inline (hiding it in the macro) but that doesn’t seem possible
Anyways, have fun.
Next trick on my todo list will be to try to move the transmit and receive stuff etc into a RFbeeCore file so that Rich will be able to say something like:
to create his echo service. Once we have this we can start working with received data
So instead of just dumping it on the serial, we can parse it for instructions like “set pin 5 HIGH”
Okay I checkout the most recent. it is broken Non stop rf read data errors. I moded the code to print the size, and it is always 0. I put an ignore of calls that are len 0 and It response to the +++ but no command recognition. I assume something is out of sync.
#ifdef USE_INTERRUPT_RECEIVE
// did we miss a receive interrupt ?
if (state==RECV_WAITING)
receiveData();
else
state==IDLE; #endif
What is intended by state==IDLE? I doubt a sideaffect logical test is what is intended, but that is what the line will do. The optimizer may well remove it as it is of no effect. One of the things I always hated about C is the fact that nonsense statements like this are legal.
Are we running with or without interrupts for receive at the moment?
" #define INTERRUPT_RECEIVE " in RFBee_v1_1.pde says it all
Comment this line out and you don’t use interrupts.
I fixed the typo’s in state==IDLE; to state=IDLE;
As I can’t send and receive at the same time (next week I can ), I can’t reproduce the error you get. It could be because of the state==idle error, so if the new version does not work, try with interrupt_receive off.
Command recognition works fine on my bee, so I think its something on your end.
The command issue is my arduino world is not send the \r. It now works from a terminal emulator, which previously did not. I am looking into that.
That idle== is all over the files. Or I noticed in several places.
The RF stuff I am trying to get a test setup in place first and echoing client that sends a tick/tock every few seconds. I am using a separate arduino for that at the moment, so we are only debugging one thing at a time. Eventually I want to add a remote echo mode for test out, something I have done with xbees and other devices.
just out of curiosity: what was the reason to add the SI command ?
A) Was it to reduce the number of bytes send ?
or
B) Was it to make it easier to parse the output ?
If it is B then I would suggest we create a OF (output format) command (and remove the SI command):
0: payload only
1: source, dest, payload
2: source, dest, payload, rssi
3: payload len, source, dest, payload, rssi
The purpose of adding SI command is to reduce the number of bytes as we do not need the SSI info.
So I agree with your suggestion , and it is more flexible.
BTW, I have added our code to the branches in google code(http://code.google.com/p/rfbee/). So you can check out the whole svn directory using https://rfbee.googlecode.com/svn
So we can commit our update to the branches. And when they are steady, I’ll merge them into the trunk.
I like the idea of the OF option. To me there are two options that make sense. Data only, and packet format. In the XBee world it is a different firmware package if you want packeted data or a stream. Either everything is encoded in a packetized format, or it is a byte stream to the configured destination. Different applications demand separate behaviors, but tend to be one or the other. For a simple sensor I normally want stream mode, send these bytes now. The listener is either a paired node, and wants a stream or a collection point in a multi-drop, many to 1, config, and always wants the address, and RSSI etc. OF works for me, but I would not implement more than the two options unless these is a use case I missed. (Once I have to unwrap data, all I care is that I can unambiguously do it. (byte counts, no parsing please!))
Hmm we have something out of sync. I just deleted and recreated my pool. ran svn diff, no differences appeared.
On both devices if I load the current build, version 13 it says in svn, and I get non-stop
ok
Error: Received invalid RF data size
Error: Received invalid RF data
Error: Received invalid RF data size
Error: Received invalid RF data
…
This shows up as soon as I connect, before sending anything.
What I propose to do is the following:
a) put the 1.03 in the trunk as
svn/trunk/rfbee
b) put the 1.1 in a branch as
svn/branched/rfbee
where we tag it as 1.1
Once 1.1 is released, we merge the 1.1 branch and then that becomes the “stable” version (trunk )
This happens with either of the two rfbees I have, with only one plugged in. The receivedata() I am getting a size of 0, returned from CCx.Read() call at the top. I am in mode 2, ATMD2, at the moment, but I just tried both devices at mode 0 and no change.
I inserted a CCx.ReadSetup() after the CCx.Read call if the size is zero, and I got the following list. Not sure if it is useful, but I thought it might enlighten someone.
I tried atcf and that reset the devices so they are no longer spewing the nonsense. So I have commented out the size == 0 for the time being. Unfortunately I am still not seeing any connectivity at this moment. (I got another powered hub to get both up at the same time on separate uart adapters.) suggestions of where I could productively poke I will follow. I have not yet had the cycles to understand the rfchip yet. BTW atcf4, then back to 0 or 1 cleared the errors I was getting. The work on the same channel that they were reporting the error on. I assume some reset or setup issue. Not a major concern for me, but I will keep it on my list of things to understand.
)
