Show Posts
Pages: [1] 2 3 ... 20
1  Products / Arduino Yún / Re: FileIO in binary mode and Process oddities on: Today at 11:38:08 am

Hi Yuntastic,

there is a deadlock in your sketch, since you do:

Code:
  p.runShellCommand("bin_reader /mnt/sd/arduino/test.png");
  while(p.available()>0)
  {
    char c = p.read();
    Serial.print(c);
  }

runShellCommand waits for bin_reader to finish, but this can't happen because bin_reader outputs more than 64k, and the Bridge can't buffer more until someone reads and empties his buffer.

A longer explanation is here:
https://github.com/arduino/YunBridge/issues/10

I suggest you to retry with runShellCommandAsynchronously that doesn't wait for the process to finish.
2  Products / Arduino Due / Re: Data loss when sending to native USB port (SerialUSB) on: January 21, 2014, 04:26:58 am
Hi stimmer!

I'd like to follow this one, but its not very handy to manually copy the files and figure out what changed from the last time, it will be much more practical if you start a branch on github. I understand that the patch may be not complete, but I'd really appreciate if you can do that :-)

3  Products / Arduino Due / Re: analogRead problem with IDE 1.5.5 libraries on: January 13, 2014, 06:00:39 am
What is the exact effect to the analog section of the SAM when more than one channel is enabled, even if for short time only? Does this mean that the related analog input pins are then electrically connected with low impedance?

Looking at the logic diagram on the datasheet it seems that there is a multiplexer before the ADC, so theoretically only one pin at a time can be connected to the ADC.

@Embed
may you post some more information on your test setup? May the inaccuracy you're experiencing be due to high impedance on your analog source?

4  Products / Arduino Due / Re: analogRead problem with IDE 1.5.5 libraries on: December 20, 2013, 05:11:42 am
@donesolnas

the change applied are the following:

first (high speed, but breaks reading on multiple analog channels), EDIT:this one is in 1.5.5:

   https://github.com/cmaglie/Arduino/commit/1fc54f5003ccd7f9fc50d52698ad174c6f9ddd5e

second (reading are correct again but slow if you read on multiple channels), this one is in 1.5.5:

   https://github.com/arduino/Arduino/commit/a1c48091051bfc7f3366cac6fc23212c4e4fb4a3

third (reading are correct and at high speed as expected):

   https://github.com/arduino/Arduino/commit/b530742603439c87a06d2da9ddd60dd9f82f5082

Another way could be to download the nightly build that should have the patch now:

http://arduino.cc/en/Main/Software

5  Products / Arduino Due / Re: analogRead problem with IDE 1.5.5 libraries on: December 18, 2013, 09:49:36 am
You find it! Thanks MarkT!

It's the second good fix in a row that you propose, I'm really impressed smiley

https://github.com/arduino/Arduino/commit/b530742603439c87a06d2da9ddd60dd9f82f5082

If someone wants to test it the updated wiring_analog.c is here:

https://raw.github.com/arduino/Arduino/b530742603439c87a06d2da9ddd60dd9f82f5082/hardware/arduino/sam/cores/arduino/wiring_analog.c

Quote
I think what is happening is that the conversion sequencer powers down the ADC between conversions if sleep mode is active, but also powers down if no channels are currently enabled.   The datasheet has to be read between the lines here!

As I said, at the time it seemed almost obvious, but I agree, the datasheet should be a little bit clear on that.

C
6  Products / Arduino Due / Re: analogRead problem with IDE 1.5.5 libraries on: December 17, 2013, 09:38:07 am
Hi stratosfear,

That fixes the read values, although conversion times are back to the same as 1.5.4.

Just checked and you're right, If you multiplex over many pins the ADC Startup time is applied at every ADC conversion and things slows up again. The speed increases only if you read from a single pin.

http://www.djerickson.com/arduino/ has some information about speeding up ADC read times.  Using the line
Code:
REG_ADC_MR = (REG_ADC_MR & 0xFFF0FFFF) | 0x00020000;
reduces twenty reads in my sketch from 840uS to 240uS.

The problem with this line is that it sets incorrect Tracking and Conversion timings for the ADC, see the discussion here for more details: https://github.com/arduino/Arduino/issues/1418

Now, the sad thing is that I've already fixed that but I've lost the fix with a clumsy move on git.
And I perfectly remember that I did the same steps we are taking here, i.e.:

1) I applied a patch similar to the one in my previous message
https://github.com/arduino/Arduino/commit/a1c48091051bfc7f3366cac6fc23212c4e4fb4a3
2) I've tested ADC again, and I've seen the slowdown like you did
3) I've applied another change that I can't remember now, but at the time was quite obvious.

So I know for sure that there is a solution and is simple, I just don't remember how smiley-sad

7  Products / Arduino Due / Re: analogRead problem with IDE 1.5.5 libraries on: December 16, 2013, 04:53:11 pm
Hi guys,

The bug was introduced after the optimization of the ADC reads (shame on me  smiley-sad)

May I ask you to try with the following patch and check if that fixes the problem?
https://github.com/arduino/Arduino/issues/1740#issuecomment-30649822

replace the file Arduino/hardware/arduino/sam/cores/arduino/wiring_analog.c
with the file here: https://raw.github.com/arduino/Arduino/a1c48091051bfc7f3366cac6fc23212c4e4fb4a3/hardware/arduino/sam/cores/arduino/wiring_analog.c

Thanks
8  Products / Arduino Yún / Re: Setting PWM frequency with Arduino Yun on: November 27, 2013, 08:34:02 am
It does have TCCR0B, TCCR1B and TCCR3B so if I change the 2B to 3B, the code compiles. I guess I now have to check which of the pin pairs each of these registers controls.

Exactly, probably someone else already did this for the Leonardo, maybe a search on the forum its worth a try.
9  Products / Arduino Yún / Re: Setting PWM frequency with Arduino Yun on: November 27, 2013, 07:15:14 am
Hi Nick,

TCCR2B is a register specific for the Atmega328, the Yùn (as like the Leonardo) mounts an Atmega32u4 that doesn't have this register. You should look for the equivalent in the 32u4's datasheet or find some code example that works on the 32u4.
10  Products / Arduino Yún / Re: Bridge.get() return value on: November 25, 2013, 05:08:05 pm
It was a bug in the Bridge, there was a "return" missing in the inlined version of get:

https://github.com/arduino/Arduino/commit/583dafb576ae1ffbcbd8de1d050120564fbe9a68

to fix it you should change line 39 of Bridge.h from:

Code:
unsigned int get(const char *key, char *value, unsigned int maxlen)
{
  get(key, reinterpret_cast<uint8_t *>(value), maxlen);
}

to

Code:
unsigned int get(const char *key, char *value, unsigned int maxlen)
{
  return get(key, reinterpret_cast<uint8_t *>(value), maxlen);
}

This should solve the issue.
The fix will be available in the next IDE release.
Thanks for the bug report!
11  Products / Arduino Yún / Re: FileIO.cpp fix on File::doBuffer() on: November 25, 2013, 06:51:43 am
Great!

thank you for the clear bug report and for the feedback smiley-wink
12  Products / Arduino Yún / Re: Bridge.get() return value on: November 25, 2013, 04:03:03 am
Bridge.get(...) returns the number of byte contained in the result (or TRANSFER_TIMEOUT if failing).
If the key is not present in the datastore an empty string is returned (so the resulting number of bytes is 0).

Hope this answers all your doubts!

13  Products / Arduino Yún / Re: JSON and Bridge lib issue with python on: November 25, 2013, 03:35:37 am
This is due to the fact that bridgeclient uses a slightly patched version of json.py.

The orignal json.py is here:
./usr/lib/python2.7/site-packages/json.py

The patched one here:
./usr/lib/python2.7/bridge/json.py

The patched version contains support for "streaming" json (adds the capability to read a sequence of json objects from the same stream of data) in our case from the socket that connects to the bridge.

To solve your problem you can move the import after adding the import path:

Code:
#!/usr/bin/python

import sys   
import subprocess

sys.path.insert(0, '/usr/lib/python2.7/bridge/')
import json
from bridgeclient import BridgeClient as bridgeclient

value = bridgeclient()                             
temperatureIn= value.get('temperatureIn');

if you are courious this is the patch applied to json.py:

Code:
--- json-yun.py 2013-11-25 09:35:02.000000000 +0100
+++ json.py     2013-07-10 20:14:21.000000000 +0200
@@ -38,6 +38,9 @@
                        raise StopIteration
        def all(self):
                return self.string
+
+       def pos(self):
+               return self.index
 
 class WriteException(Exception):
     pass
@@ -52,7 +55,7 @@
     def read(self, s):
         self._generator = _StringGenerator(s)
         result = self._read()
-        return result
+        return result, self._generator.pos()+1
 
     def _read(self):
         self._eatWhitespace()
14  Products / Arduino Yún / Re: FileIO.cpp fix on File::doBuffer() on: November 22, 2013, 11:07:48 am
@fabiog45

I've checked your sketch with file1.txt and the problem randomly happens (about 1 time out of 4 or 5).

Would you like to try to change the /usr/bin/run-bridge script on the yun with the following:

Code:
#!/bin/sh

cd /usr/lib/python2.7/bridge

exec python -u bridge.py 2> /tmp/bridge.py-stderr.log

I've added the "-u" flag on the last line, that tells python to not line-buffer incoming data from the 32u4.
After this change I wasn't able to reproduce the bug, anymore, I want to know how it works for you.
15  Products / Arduino Yún / Re: Asynchronous HTTP request on: November 18, 2013, 03:59:05 am
Hi NielsBE,

the documentation was incomplete (it seems that the page you're linking was somewhat missed during the review), I've fixed it. Thanks.

You can use the
Code:
client.ready()
function to check if the HTTP request is completed or is still in progress.
Note that the ready function may return true (=> HTTP request completed) even if you don't read all the data coming from the server.

an example of use may be:

Code:
client.getAsynchronously("http://url/page?t=" + String(buttonOn));
// Wait for the http request to complete
while (!client.ready()) {
     delay(100); // or do other stuff
}
// Read all the data
while (client.available()) {
    char c = client.read();
    Serial.print(c);
}

I see that you also copy all the message coming from the server into a String:

Code:
      while (client.available()) {
        char c = client.read();
        message += c;
      }

I must warn you that this may easily lead to memory exhaustion because you have a total of 2K of RAM available on the 32U4 (and the server may easily send a response with more bytes).

Hope to be of any help!
Pages: [1] 2 3 ... 20