Prop Shield Beta Test

[defragster]

<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.

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.

[Pensive]

My built with connectorboard v2 - all pins accessible:

Attachment 6875

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

[MichaelMeissner]

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:

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:

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.

[manitou]

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)

[manitou]

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)

[MichaelMeissner]

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.

[PaulStoffregen]

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.

[JBeale]

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?

[Frank B]

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 ?

[Frank B]

(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..

[defragster]

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>

[Frank B]

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?).

[manitou]

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.

[PaulStoffregen]

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....

[MichaelMeissner]

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.

[dpharris]

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

[defragster]

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

[drichelson]

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?

[defragster]

Paul - Now that there are multiple PJRC product shields - a table of pin usage might help answer questions like P#418.

[mortonkopf]

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?

[mortonkopf]

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".

[mortonkopf]

And, finally, using SerialFlash file.read(buffer, 512); read from the flash file and print contents to serial monitor for given number of char:

#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).

[Frank B]

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".

[MichaelMeissner]

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

[JBeale]

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?