Forum Rule: Always post complete source code & details to reproduce any issue!
Page 17 of 21 FirstFirst ... 7 15 16 17 18 19 ... LastLast
Results 401 to 425 of 502

Thread: Prop Shield Beta Test

  1. #401
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,668
    <edit>:: I just moved the R/G/B for Roll/Pitch/Yaw code into Wozzy's sketch and it is working as expected. Not sure why it is failing in the other sketch - but all is well with Fusion on my Prop board.

    Fairly stable and consistent. Oddly it has the gimbel lock apparent with one LED color per R/P/Y - nose up has two move in counter sync with each other - nose down they move in sync.

    Quote Originally Posted by KurtE View Post
    It runs, not sure what it is supposed to do?
    As you move the PropShield the RGB lights should follow the Roll/Pitch/Yaw in some deterministic fashion - they should not be a twinkling mess. If you have SerMon - every so often you'll see my Max/Min pass by - showing the extremes of three sensors and then RPY, I see that 4th group as noted above showing the device is giving scattershot/full range readings while stationary- but my device works fine on Wozzy's code with your suggested re-scaling.
    Last edited by defragster; 03-30-2016 at 03:25 AM.

  2. #402
    Senior Member Pensive's Avatar
    Join Date
    Aug 2014
    Location
    Basingstoke, UK
    Posts
    562
    Quote Originally Posted by Frank B View Post
    My built with connectorboard v2 - all pins accessible:

    Attachment 6875
    There is something very elegant in it's simplicity - great work!

  3. #403
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,878
    As i reported earlier, I had a solder mis-hap (trying to de-solder a right angle female header I put on the APA102 pin output), and the i2c sensors seemed to go missing. I did try to clean up the solder some more, and it looks like the sensors now respond to i2c detect requests once again, and the prop shield test spews a lot of numbers (I may have missed updates).

    I was trying to access the flash memory, and I can't get anywhere. I've tried teensytethertool (on a Fedora 22 workstation) and -w file doesn't seem to work. I've downloaded new versions of the tool, and I'm still having problems (and not having the serial monitor means I can't put in println's to trace things).

    I decided to try the RawHardwareTest from SerialFlash, and I get:

    Code:
    Raw SerialFlash Hardware Test
    
    Read Chip Identification:
      JEDEC ID:     0 0 0
      Part Nummber: (unknown chip)
      Memory Size:  1048576 bytes
      Block Size:   65536 bytes
    
    Reading Chip...
      Previous data found at address 0
      You must fully erase the chip before this test
      found this: 00 00 00 00 00 00 00 00 
         correct: 00 00 00 00 15 F5 95 4B 
    
    Tests Failed  :{
    
    The flash chip may be left in an improper state.
    You might need to power cycle to return to normal.
    So I go to EraseEverything also from SerialFlash:

    Code:
    Flash Memory has 1048576 bytes.
    Erasing ALL Flash Memory:
      estimated wait: 3 seconds.
      Yes, full chip erase is SLOW!
    Erase completed
      actual wait: 0 seconds.
    I reran RawHardwareTest, and it gives me the same answer.

    Just to be sure, I power cycle the Teensy 3.2 + prop shield, and I get the same thing as well.

    Am I using the right sketches?

    Would it be possible to have a 2 sketches in 1.28 examples, one that tests all of the functionality in the normal shield, and the other that tests things in the LC shield to verify that everything is as expected? Note, these would need to be standalone and not need separate tools to visualize the data or use a tool to download files to simplify complex setup issues.

  4. #404
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,593
    Quote Originally Posted by MichaelMeissner View Post

    Am I using the right sketches?

    Would it be possible to have a 2 sketches in 1.28 examples, one that tests all of the functionality in the normal shield, and the other that tests things in the LC shield to verify that everything is as expected? Note, these would need to be standalone and not need separate tools to visualize the data or use a tool to download files to simplify complex setup issues.
    Using the SerialFlash examples as you did should work. You need to run EraseEverything first, and it should report 8 MB and take about 19 seconds. How is your teensy 3.2 attached to your prop shield? Seems that your de-soldering trauma may have messed up SPI access to shield's flash. flash uses 3.3v,grnd,11,12,13 with CS on pin 6.

    EDIT:
    Paul. it might be helpful if EraseEverything did some validation checks. As it is, it says things are erased even if SPI is disconnected. You might print the id[] and verify it's non-zero. After erase, you could read page 0 and verify that it is 256 0xff's. (of course, it could report 0xff's even if erase failed, but in my testing it seems to report 0's with disconnected/mis-wired SPI)
    Last edited by manitou; 03-30-2016 at 03:19 PM.

  5. #405
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,593
    Quote Originally Posted by PaulStoffregen View Post
    The Prop Shield pages are now on the website.

    http://www.pjrc.com/store/prop_shield.html

    http://www.pjrc.com/store/prop_shield_lowcost.html

    I'd like to invite everyone to comment or give feedback. As you can see, there's still a few TODO items. I've almost certainly missed some important details too.
    In the Technical Details section you might add links to the data sheets for sensors, audio amp, and serial flash (and maybe do as Sparkfun does, and make your own copy of the PDFs on pjrc.com)

  6. #406
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,878
    Quote Originally Posted by manitou View Post
    Using the SerialFlash examples as you did should work. You need to run EraseEverything first, and it should report 8 MB and take about 19 seconds. How is your teensy 3.2 attached to your prop shield? Seems that your de-soldering trauma may have messed up SPI access to shield's flash. flash uses 3.3v,grnd,11,12,13 with CS on pin 6.

    EDIT:
    Paul. it might be helpful if EraseEverything did some validation checks. As it is, it says things are erased even if SPI is disconnected. You might print the id[] and verify it's non-zero. After erase, you could read page 0 and verify that it is 256 0xff's. (of course, it could report 0xff's even if erase failed, but in my testing it seems to report 0's with disconnected/mis-wired SPI)
    It looks like the CLK (pin 13) pin on the APA102 pinout is damaged, but the DATA (pin 11) pin is ok, as are ground and 5v pins.

    I am getting sound through the DAC/amp when I enable it.

    Note, I never tried the flash memory before, so I can't necessarily blame the attempt at un-soldering the APA102 leds.

    I did run a blink test where each digital pin was turned on and then off, and I could see all of the main pins (0-23) did provide power when I put the Teensy + prop shield into a breadboard (this includes pins 6, 11-13). I'm now suspecting that I may not have proper solder connections to the shield itself for the SPI/flash pins (6, 11-13). So I'll check it tonight.

    This is why I was hoping there was a sketch that checked to see if all of the proper connections were made. Given it should take 19 seconds to erase, and it took 0, I imagine something isn't soldered.
    Last edited by MichaelMeissner; 03-30-2016 at 03:48 PM.

  7. #407
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,001
    Quote Originally Posted by manitou View Post
    In the Technical Details section you might add links to the data sheets for sensors, audio amp, and serial flash (and maybe do as Sparkfun does, and make your own copy of the PDFs on pjrc.com)
    Added.

  8. #408
    Senior Member
    Join Date
    Oct 2012
    Location
    Portland OR
    Posts
    706
    Quote Originally Posted by manitou View Post
    Paul. it might be helpful if EraseEverything did some validation checks. As it is, it says things are erased even if SPI is disconnected. You might print the id[] and verify it's non-zero. After erase, you could read page 0 and verify that it is 256 0xff's. (of course, it could report 0xff's even if erase failed, but in my testing it seems to report 0's with disconnected/mis-wired SPI)
    Is it possible to set weak pull-down resistors on the data input line for this test, so that you can tell for sure if the line is being driven high externally, or left floating?

  9. #409
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,017
    This would help for the case when there is no flash connected or it puts its output to high-impendance, better than nothing.
    But the id should be invalid in this case, too.

    Maybe read the first bytes (128?) of each page ? or, if less than 8..16MB (to save time), read the whole flash, to be sure ?

  10. #410
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,017
    Quote Originally Posted by MichaelMeissner View Post
    (and not having the serial monitor means I can't put in println's to trace things).
    The serial monitor works with RAW_HID, you can use Serial.print() !

    But if your hardware is not working, this is meaningless..
    Last edited by Frank B; 03-30-2016 at 08:19 PM.

  11. #411
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,668
    RAW_HID can have a bit more lag to catch initial messages.

    On pushing sketches or 'TYQT Reset' I've seen this more than a few times talking to the NXP hardware:
    config error FXOS8700
    I suppose the hardware is just caught in an odd state mid i2c transaction - but to recover takes a power cycle.

    Here is the sketch I got working from the Wozzy APA102 sketch that puts R=Roll, G=Yaw, B=Pitch from the Fusion data. I put in sampling to get a centered WHITE LED from start position. Noted before Nose up/down the R/G pixels gimbal lock out/in sync. This is the same I was trying to do within the calibration sketch ("I cannot get stable data from filter.update()")and the RGB were all over the place - as if the sensors were not pulling together in the fusion data - though each sensor alone gave good data plotting the x,y,z in the same way.

    YawPitRol_t2.ino <edited sketch - will set point after seeing same point 10 times>
    Last edited by defragster; 03-31-2016 at 06:27 PM.

  12. #412
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,017
    TyQT has a little bug with HID, too - when i have my other TODO's done, i'll post an example. Sometimes the monitor duplicates a character (somewhere near 128 bytes..127 or 129?).

  13. #413
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,593
    Quote Originally Posted by defragster View Post
    RAW_HID can have a bit more lag to catch initial messages.

    On pushing sketches or 'TYQT Reset' I've seen this more than a few times talking to the NXP hardware:
    config error FXOS8700

    I suppose the hardware is just caught in an odd state mid i2c transaction - but to recover takes a power cycle.
    Post #344 noted that you might be able to reset the I2C slaves (digital IO to the SCL/SDA) and avoid power cycle. i2c_t3 lib has a busReset_() that does this. you need to configure the pins back to I2C mode after the digital IO (part of busReset_())

    I haven't tried it though ...

    As Paul notes, it would be nice to know what causes the I2C to hang.
    Last edited by manitou; 03-30-2016 at 09:45 PM.

  14. #414
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,001
    Quote Originally Posted by Frank B View Post
    Bugfix for my flash problem:

    In SerialFlashChip.cpp,
    void SerialFlashChip::write(uint32_t addr, const void *buf, uint32_t len) {

    add a delay:
    .....
    I've *finally* added this on github.

    https://github.com/PaulStoffregen/Se...44972faed6b11e

    Sorry this took so very long. I've been pretty distracted by motion sensors and tons of mundane but critical PJRC business stuff the last couple weeks!

    For now (and for Teensyduino 1.28) I'd like to go with the safest approach. We can optimize later. Eventually I want to seriously optimize all this to use the SPI FIFOs, so probably look at the timing issue then....

  15. #415
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,878
    FWIW, I resoldered the pins 2, 6, 11-13, 18-19, 3.3v, AGND, 5v, and now I can run the various flash memory programs (EraseEveryThing, RawHardwareTest, and TeensyTransfer). I was able to download, list, and erase small files.

  16. #416
    I have ordered a loaded and an unloaded Prop shield and they are winging their way to me. Looking foward to them.

  17. #417
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,668
    Quote Originally Posted by manitou View Post
    Post #344 noted that you might be able to reset the I2C slaves (digital IO to the SCL/SDA) and avoid power cycle. i2c_t3 lib has a busReset_() that does this. you need to configure the pins back to I2C mode after the digital IO (part of busReset_())

    I haven't tried it though ...

    As Paul notes, it would be nice to know what causes the I2C to hang.
    Thanks Manitou - I missed that : force all I2C devices to reset. I've seen it a a few times - and had it on the clipboard and it always got dumped before I got here.

    My APA102 sketch is stable looking and good - like yesterday but restarted today. Right now the R&G&B are centered side by side since my earlier post ...

    @MichaelM: Good job NOT toasting but recovering your Prop Shield

  18. #418
    Junior Member
    Join Date
    Dec 2013
    Location
    San Francisco, California
    Posts
    10
    Hi, this thing looks awesome! I just ordered 2. Can someone describe the level of compatiblity with OctoWS2811 and specifically the OCTOWS2811 board sold by PJRC?

  19. #419
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,668
    Paul - Now that there are multiple PJRC product shields - a table of pin usage might help answer questions like P#418.

  20. #420
    Senior Member mortonkopf's Avatar
    Join Date
    Apr 2013
    Location
    London, uk
    Posts
    923
    Frank. I am testing your teensy transfer on Mac. Setup is MacBook Pro (mid 2012 spec), Arduino IDE 1.6.7 with Teensyduino 1.2.7. These are both fresh installations this morning, with the latest SerialFlash from Paul's github, and a fresh download from yours: https://github.com/FrankBoesing/TeensyTransfer

    The transfer tool works well for -w and -l. output is:
    ###:~ Home$ /Users/Home/Documents/Arduino/libraries/TeensyTransfer/extras/teensytransfer [-w] tty000 /Users/Home/Documents/Arduino/libraries/TeensyTransfer/test.rtf
    ###:~ Home$ /Users/Home/Documents/Arduino/libraries/TeensyTransfer/extras/teensytransfer -l
    341 /Users/Home/Documents/Arduino/libraries/TeensyTransfer/test.rtf
    from the IDE serial window, using the listless sketch, the window output is:
    All Files on SPI Flash chip:
    /Users/Home/Documents/Arduino/libraries/TeensyTransfer/test.rtf 341 bytes
    I will now see about reading the file contents.
    Question: what is the correct syntax / location to use, as it looks as though I am currently giving the written file a filename that is the whole file path?

  21. #421
    Senior Member mortonkopf's Avatar
    Join Date
    Apr 2013
    Location
    London, uk
    Posts
    923
    Have used the read teensy transfer function. Output is:

    ###:~ Home$ /Users/Home/Documents/Arduino/libraries/TeensyTransfer/extras/teensytransfer -r tty000 /Users/Home/Documents/Arduino/libraries/TeensyTransfer/test.rtf
    {\rtf1\ansi\ansicpg1252\cocoartf1348\cocoasubrtf17 0
    {\fonttbl\f0\fswiss\fcharset0 Helvetica;}
    {\colortbl;\red255\green255\blue255;}
    \paperw11900\paperh16840\margl1440\margr1440\vieww 10800\viewh8400\viewkind0
    \pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3 968\tx4535\tx5102\tx5669\tx6236\tx6803\pardirnatur al

    \f0\fs24 \cf0 this is a test}
    this is output for an rtf file containing the text "this is a test".

  22. #422
    Senior Member mortonkopf's Avatar
    Join Date
    Apr 2013
    Location
    London, uk
    Posts
    923
    And, finally, using SerialFlash file.read(buffer, 512); read from the flash file and print contents to serial monitor for given number of char:

    Code:
    #include <SerialFlash.h>
    #include <SPI.h>
    
    const int FlashChipSelect = 6; // digital pin for flash chip CS pin
    
    void setup() {
      // wait for Arduino Serial Monitor
      while (!Serial) ;
      delay(100);
      Serial.println("All Files on SPI Flash chip:");
    
      if (!SerialFlash.begin(FlashChipSelect)) {
        error("Unable to access SPI Flash chip");
      }
    }
    
    void spaces(int num) {
      for (int i=0; i < num; i++) {
        Serial.print(" ");
      }
    }
    
    char buffer[512];
    
    void loop() {
    SerialFlashFile file;
    file = SerialFlash.open("/Users/Home/Documents/Arduino/libraries/TeensyTransfer/test.rtf");
    //your file name
    if (file) {  // true if the file exists
      Serial.println("exists!");
    
    file.read(buffer, 512);}
    for (int x=0;x<512;x++){
    Serial.print(buffer[x]);}
    Serial.println("...end");
    blinkLed();
    }
    
    void error(const char *message) {
      while (1) {
        Serial.println(message);
        delay(2500);
      }
    }
    
    void blinkLed()
    {
          digitalWrite(13, HIGH);
          delay(1);
          digitalWrite(13, LOW);
    }
    serial monitor output is:
    exists!
    {\rtf1\ansi\ansicpg1252\cocoartf1348\cocoasubrtf17 0
    {\fonttbl\f0\fswiss\fcharset0 Helvetica;}
    {\colortbl;\red255\green255\blue255;}
    \paperw11900\paperh16840\margl1440\margr1440\vieww 10800\viewh8400\viewkind0
    \pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3 968\tx4535\tx5102\tx5669\tx6236\tx6803\pardirnatur al

    \f0\fs24 \cf0 this is a test}...end
    the object is now to use the file to hold Led data sets, and send data to the led strip rather than to the monitor (debug).

  23. #423
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,017
    Great that it works on MAC !
    It's still an old version with some minor bugs (and the files must be in the same directory as teensytransfer, on MAC in this old version)- and i can't compile it
    Unfortunately, now, the MAC Version is not able to access the Teensy EEPROM.

    I'll add some more functions (parallel connected flash, perhaps erase chip) in the days, and then ask somebody who owns a MAC to do a fresh compile..
    I'll open a new thread then, which will contain a "howto".
    Last edited by Frank B; 03-31-2016 at 12:30 PM.

  24. #424
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,878
    Quote Originally Posted by defragster View Post
    Paul - Now that there are multiple PJRC product shields - a table of pin usage might help answer questions like P#418.
    I put together the following spreadsheet to keep track of all of the Teensy's and shields. Unfortunately, it is starting to get too big to fit without having to scroll horizontally: https://docs.google.com/spreadsheets...gid=1103027528

  25. #425
    Senior Member
    Join Date
    Oct 2012
    Location
    Portland OR
    Posts
    706
    Quote Originally Posted by MichaelMeissner View Post
    I put together the following spreadsheet to keep track of all of the Teensy's and shields. Unfortunately, it is starting to get too big to fit without having to scroll horizontally: https://docs.google.com/spreadsheets...gid=1103027528
    Very nice; that's a great summary of the pinouts. Is that link suitable for long-term reference?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •