Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Issues for 6LBR in Linux PC #2

Closed
KarHoey opened this issue Mar 12, 2013 · 5 comments
Closed

Issues for 6LBR in Linux PC #2

KarHoey opened this issue Mar 12, 2013 · 5 comments
Assignees
@sdawans
Labels
needs-doc question

Comments

@KarHoey
Copy link

KarHoey commented Mar 12, 2013

Dear developers,

  1. The 6LBR installed in my Ubuntu 10.04 doesn't auto-generate 6lbr.conf.
  2. 6lbr-demo is failed to upload into the Z1 node, with error 'Import Error: No module named serial'. I don't understand why the line 17 in 6lbr/tools/z1/z1-bsl-nopic is appending "/usr/lib/tinyos" in the path? I must install Tiny OS in order to make 6LBR works?
  3. Do you have more examples of 6LBR on Linux PC, I need more examples for understanding.

Thank you.
@sdawans
Copy link
Collaborator

sdawans commented Mar 12, 2013

Hi,
Thanks for using the issue tracker, it makes it much easier for the people searching for info after you.

For your 3 points:

  1. Assuming that you have followed these instructions, if you make it to the make_install step then you should find some configuration files in /etc/6lbr. You must take one of them (the one closest to your configuraiton), rename it to 6lbr.conf and edit it if you need to change something. If this works for you I will make the documentation clearer.
  2. Not sure about this one, I have Z1 motes but I haven't tested 6lbr-demo on it. Have you managed to run other applications on the Z1? Looks like you might have a z1 toolchain problem. BTW, no, there are no dependencies with TinyOS.
  3. I agree, others have been asking for this as well. More examples are on the way, I'll report back here when I get some finished. In the meantime if you have specific questions feel free to ask.

@sdawans
Copy link
Collaborator

sdawans commented Mar 12, 2013

hello,
I saw your second post but it disappeared. Was this intentional on your part? If not I can post it pack, I have the history in email.

  1. For the first bullet, the wiki is now updated.
  2. If you're still experiencing issues with the Z1, could you try programming a Z1 from within the 6lbr/examples/hello-world directory? 6lbr is a clone of Contiki, and we didn't take anything out. If you have the same issue from the hello-world example it means there have been updates in Contiki between feb 3rd (commit 13c842f) and now. We'll be merging in updates of Contiki every month or so, so the next merge might fix your issue. We're running a bit overtime on the first merge so i might make this a prioriy :)

@KarHoey
Copy link
Author

KarHoey commented Mar 12, 2013

Hi,

Sorry for deletion. However the problem was solved.
Good news is the problem is not at the 6lbr. However, this issue happened after I installed the Python2.7 for testing framework, all source codes (Contiki and 6lbr) cannot upload into Z1 mote. You may test it again.
Therefore, I revert the path to Python2.6 instead of remove Python2.7 because it is quite troublesome.

Thanks for help. Currently trying to get it work on Ubuntu 10.04.

@sdawans
Copy link
Collaborator

sdawans commented Mar 12, 2013

No problem I was afraid I had deleted it myself with a missclick :)
If you've just installed python2.7 it's likely you're missing the Serial module. Try something along these lines (this is from the top of my head I didn't check the syntax)

sudo apt-get install python2.7-pip
sudo pip-2.7 install pyserial

@ghost ghost assigned sdawans Mar 12, 2013
@sushil909 sushil909 mentioned this issue Sep 16, 2013
Closed
@laurentderu
Copy link
Member

Solved in #3

laurentderu pushed a commit that referenced this issue Apr 24, 2014
@atiselsts
Fix CPU clock calibration in msp430f2xxx based platforms (e.g. Zolert…
68b65e6 
…ia Z1).

The following problems were present in the existing DCO calibration algorithm:

Problem #1. In function msp430_quick_synch_dco(), the "for(i=0; i < 1000; i++) { .. }" loop is optimized away by the compiler, as i is not volatile. Making i volatile would improve the results, but would not be sufficient: see the next point.

Problem #2. According to MSP430F2617 Device Erratasheet, bug BCL12 precludes a naive implementations of "fast" calibration altogether. The bug is present on all MCU revisions up to date.

The description of the bug:
"After switching RSELx bits (located in register BCSCTL1) from a value of >13 to a value of <12 OR from a value of <12 to a value of >13, the resulting clock delivered by the DCO can stop before the new clock frequency is applied. This dead time is approximately 20 us. In some instances, the DCO may completely stop, requiring a power cycle.

Furthermore, if all of the RSELx bits in the BSCTL1 register are set, modifying the DCOCTL register to change the DCOx or the MODx bits could also result in DCO dead time or DCO hang up."

In Contiki code for msp430f2xxx @ 8MHz, the RSEL search currently typically goes from 15 down to 11, thus violating the rules.

Step-by-step RSEL change is proposed as the best possible workaround:
"[..] more reliable method can be implemented by changing the RSEL bits step by step in order to guarantee safe function without any dead time of the DCO."

Problem #3. The old Contiki code started from the highest possible calibration values: RSEL=15, DCOx=7. According to MSP430F2617
datasheet, this means that the DCO frequency is set to 26 MHz. For one, Vcc under 3V is not supported for this frequency, so this means that battery-powered nodes have a big problem. The minimal operating voltages are:
- 1.8V for RSEL <= 13
- 2.2V for RSEL = 14
- 3.0V for RSEL = 15
So the correct way is to always start calibration from RSEL <= 13, unless explicityly pre-calibred values are present.

Problem #4. Timer B should be turned off after the calibration, following the "Principles for Low-Power Applications" in MSP430 user's Guide.

The patch fixes these issues by performing step-by-step calibration and turning off Timer B afterwards. As opposed to MSP430F1xxx calibration, this algorithm does not change the ACLK divider beforehand; attempts to make calibration more precise would lead to looping in some cases, as the calibration step granularity at larger frequencies is quite big.

Additionally, the patch improves DCOSYNCH_CONF_ENABLED behavior, allowing the resynchronization to correct for more than one step.
bregell pushed a commit to bregell/6lbr that referenced this issue Mar 18, 2015
@peretuset
Merge pull request cetic#2 from adamdunkels/peretuset-master
c7160f1 
Add antenna configuration functionality and a small fix to the button sensor.
@pepeee pepeee mentioned this issue May 2, 2016
Closed
laurentderu pushed a commit that referenced this issue May 24, 2016
@bthebaudeau
enc28j60: Add workaround for erratum #2 "CLKRDY set early"
ba6a0bc 
A delay of 1 ms must be added after the System Reset Command. Still wait
for ESTAT.CLKRDY afterwards as a precaution.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
laurentderu pushed a commit that referenced this issue May 24, 2016
x86: Initialize the 8259 PIC
1109850 
The Programmable Interrupt Controller is a chip responsible for
translating hardware interrupts to system interrupts. When it
receives an Interrupt Request (IRQ), it triggers the appropriate
interrupt line reaching the appropriate IDT gate, following a
previously setup offset.

There are 2 daisy-chained PICs. PIC1 handles IRQs 0-7 and PIC2
handles IRQs 8-15. If no vector offset is set, an IRQ0, for instance,
would trigger the interrupt 0, clashing with the "Division by zero exception"
handler. Thus the IRQs must be remapped.

This patch implements the PICs initialization through their 4
Initialization Command Words (ICWs) in a very "canonical" way:
- ICW1: the initializing command;
- ICW2: the vector offset for the PIC1 and PIC2 (we add an offset of 32 positions);
- ICW3: the inter-PICs wiring setup (we connect PIC2 to PIC1's IRQ2);
- ICW4: extra systems information (we set PIC1 as Master and PIC2 as slave).

It then masks the Interrupt Mask Register, blocking all IRQs but #2 initially.
These must be unmasked on demand. The IMR is 8-bits long, so setting the n^th bit to 1
would DISABLE the IRQ n while setting it to 0 would ENABLE IRQ n.

As stated, this is an implementation of the legacy 8259 PIC. More
investigation is needed so we decide if it is enough or if we need
the (newer) APIC implementation instead.

This patch also adds the outb() helper function to helpers.h. The helpers
is a wrapper for assembly 'out' instruction.

Finally, since we now properly support hardware interrupts, this patch
also enables IRQs in platform main().

More information:
- Quark X1000 Datasheet, section 21.12, page 898.
- http://wiki.osdev.org/8259_PIC
- http://stanislavs.org/helppc/8259.html
@shosant shosant mentioned this issue Jun 29, 2016
Closed
@ClauGarciaG ClauGarciaG mentioned this issue Jul 25, 2016
Closed
@rahultt007 rahultt007 mentioned this issue Jun 20, 2017
Closed
This was referenced Jul 7, 2017
Closed
Closed
This was referenced Oct 3, 2017
Open
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sdawans sdawans

Labels
needs-doc question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@sdawans @laurentderu @KarHoey