| Author |
Message |
|
|
 Posted: Feb 07, 2012 - 07:42 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
Okay, and I always wondered why the Atmel EK1 has a 32 kHz oscillator. Maybe I can find a way to upgrade the board with a crystal.
Quote:
but you'll have to disable calibration in the HAL
Which functions are involved?
Last question for today!
Thanks a lot. Have a good evening! |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2012 - 07:44 PM |
|
Joined: Apr 15, 2009
Posts: 4865
Location: San Jose, CA
|
|
| halStartingCalibrate() |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I’m affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 07:51 AM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
But to calibrate internal RC oscillator BitCloud uses 32 kHz oscillator as a reference.
So would it also be a problem to use USART at higher speeds (>9600 Baud)?
Quote:
The only reason why halReadUid() might take that much time is to wait until few bytes are sent over SPI.
I haven't configured the EEPROM part so far. My EEPROM is on PB4. There is no UID in my EEPROM. Could that also be part of the problem?
I don't understand the selection of Int. RC Oszillator in the Fuses.
Int. RC Osz.: 32kHz
CKDIV: 8 kHz
Result: 4 kHz
The Blink-example demands a 8 MHz system clock. How does that fit with the 4 kHz Clock? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 04:13 PM |
|
Joined: Apr 15, 2009
Posts: 4865
Location: San Jose, CA
|
|
|
guitero wrote:
So would it also be a problem to use USART at higher speeds (>9600 Baud)?
Yes, it will. Normal UART operation is the main reason for calibration.
guitero wrote:
I haven't configured the EEPROM part so far. My EEPROM is on PB4. There is no UID in my EEPROM. Could that also be part of the problem?
No, SPI will just receive 0 as UID, but it should happen quickly.
guitero wrote:
I don't understand the selection of Int. RC Oszillator in the Fuses.
You have selected 8 MHz internal RC oscillator in your fuses. CKDIV8 will divide it to 1 MHz for easy calibration and after calibration stack will disable CKDIV8. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 04:48 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
You have selected 8 MHz internal RC oscillator in your fuses
Aha, the internal RC is 16 MHz and the Prescaler is 1:2 in the default state, isn't it? Thus it's 8 MHz.
If I use the USART (9600 Baud) with the fuses I have posted above I get wrong output on the terminal. If I change Fuses to the Transceiver Oscillator instead the output is correct. Why can't I use the Transceiver Oscillator. Which part of the Bitcloud won't work? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 04:51 PM |
|
Joined: Apr 15, 2009
Posts: 4865
Location: San Jose, CA
|
|
|
guitero wrote:
Aha, the internal RC is 16 MHz and the Prescaler is 1:2 in the default state, isn't it? Thus it's 8 MHz.
Correct.
guitero wrote:
If I use the USART (9600 Baud) with the fuses I have posted above I get wrong output on the terminal. If I change Fuses to the Transceiver Oscillator instead the output is correct.
That's because calibration to non-existing 32 kHz made frequency completely off.
guitero wrote:
Why can't I use the Transceiver Oscillator. Which part of the Bitcloud won't work?
Sleeping. RF transmitter frequency is disabled during the sleep. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 05:06 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
Without an 32 kHz Oscillator I can't
1. address an external EEPROM (very slow)
2. use sleeping mode
Is that right?
According to that I have to find a way to upgrade my board. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 05:22 PM |
|
Joined: Apr 15, 2009
Posts: 4865
Location: San Jose, CA
|
|
|
guitero wrote:
Is that right?
I don't know why SPI is so slow. It should not be this way. I assume something else is wrong and your entire system might run at a very slow speed. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 05:33 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
I assume something else is wrong and your entire system might run at a very slow speed.
Damn! Any suggestions what I can do to solve the problem?
How can I check whether the entire system is affected or not. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 05:37 PM |
|
Joined: Apr 15, 2009
Posts: 4865
Location: San Jose, CA
|
|
First of all I would try to understand what parts of UID read take that much time.
After that I'd run some code that blinks an LED (not a Blink application, but rather hard-coded while (1) loop and manual delays between blinks and try to estimate expected blink interval and compare it to the actual interval) |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I’m affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 06:29 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
First of all I would try to understand what parts of UID read take that much time
I think this is the part where the delay (20 seconds) happens.
Code:
// wait for end of action
while(!(TWCR & (1 << TWINT)));
Quote:
After that I'd run some code that blinks an LED (not a Blink application, but rather hard-coded while (1) loop and manual delays between blinks and try to estimate expected blink interval and compare it to the actual interval
It's all fine. I wrote a small application that toggled a LED every second. After that I tried to send one Byte to a terminal every second. I checked Int. OSC. (8 MHz) and Transceiver OSC (16 MHz). I recognized no significant delay. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 06:34 PM |
|
Joined: Apr 15, 2009
Posts: 4865
Location: San Jose, CA
|
|
| Oh, you have TWI UID enabled. It can cause delays if device is not present. I was looking at RCB version, which uses SPI. Then you'll just need to remove this read. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I’m affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 06:40 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
Then you'll just need to remove this read.
All right! Can you give me a hint how I can integrate my external EEPROM (CS is on PB4) into the BitCloud. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 06:43 PM |
|
Joined: Apr 15, 2009
Posts: 4865
Location: San Jose, CA
|
|
| I would just remove UID read from the HAL and read it in the application. This way it will be much easier for you to maintain the code. Just set CS_UID to a read value before starting a network. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I’m affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 06:55 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
|
Quote:
Just set CS_UID to a read value before starting a network.
Sorry, I don't quite follow. CS_UID is the unique identifier for every node. How can that be set to a read value? Would you mind getting more into detail? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 06:59 PM |
|
Joined: Apr 15, 2009
Posts: 4865
Location: San Jose, CA
|
|
You will read some UID value from the EEPROM; then you need to write this value to UID:
Code:
ExtAddr_t addr;
readValueFromEeprom(&addr);
CS_WriteParameter(CS_UID_ID, &addr);
That all valid if you want to read UID from external EEPROM; if you don't I don't understand what the problem is. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I’m affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 07:09 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
| Sorry. You've got me wrong. My problem is to change the pin of the EEPROM because on the example board it's not on PB4. But I don't find the file where I can change the pinning. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 07:17 PM |
|
Joined: Apr 15, 2009
Posts: 4865
Location: San Jose, CA
|
|
What example board? STK600-megaRF does not have CS for EEPROM at all.
That depends on what you want to achieve.
My advice: BitCloud is a networking library, treat it as such. EEPROM does not have anything to do with sending data, so just access it as you would without BitCloud around. |
_________________
The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I’m affiliated with.
|
| |
|
|
|
|
|
|
Posted: Feb 08, 2012 - 07:22 PM |
|
Joined: Feb 03, 2012
Posts: 74
Location: Oldenburg
|
|
| Okay,I think I can manage that. Thanks a lot for your answers Alex! |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
