srlm-io / anzhelka Goto Github PK

What steps will reproduce the problem?
1. Put this into a Spin file: 
[code]    {    {{    }}    }    [/code]

What is the expected output? What do you see instead?
The file is highlighted as a comment to the first } (right curly brace), then 
comment highlighting stops and normal highlighting begins.

BST compiles everything between the {} (single curly brace) comments as a 
comment, so highlighting should reflect that.

In general, if the processor can't process a line it fails silently. Two cases:

1. A line with no = sign
2. A line with multiple operations on a level (eg, "a*b*c", instead of 
"(a*b)*c".

What is the expected output? What do you see instead?

It should produce useful output. Instead, BSTC says things like:
1. Symbol XXX already defined.
2. Unresolved symbol.

What steps will reproduce the problem?
1. Create a number, such as %0001_1111 or 5000_0000

What is the expected output? What do you see instead?
The code should be able to highlight the number as a constant. Note this should 
work for binary, decimal, and hex numbers.

What steps will reproduce the problem?
1. Run the Propeller at any frequency besides 80MHz

What is the expected output? What do you see instead?
It should work normally, but instead it has bad timings. It defines _clkmode 
and _xinfreq, along with a "resolution" paremeter.

What steps will reproduce the problem?
1. Print a number such as 1.0101
`   FPrint(fp.FDiv(float(100), float(99)))`
2. Observe output


What is the expected output? What do you see instead?
Expected: 1.0101 (or 1.01)
Actual: 1.10

Floating point printing error

This is rather not an issue but it may help you a bit with the problematic 
UM6-LT IMU.

I bought this IMU also and by visualizing its output I found the attitude is 
not correct at all despite the fact that I've done all sorts of calibration.

There is source code on the sourceforge and you can use the trial version of 
ride7 to build it.

The problem I found in the source code is a that the author swaps y and z axis 
of magnetometer (LS303DLM), which seems to be wrong. But when I build the 
source without any modification and uploaded it to the device, it started to 
work properly. I guess the datasheet of LS303DLM indicates wrong y and z axis 
registers and the programmer did a dirty hack without any announcement of this 
bug fix.

If you want to verify this, try using the desktop utility to see the raw 
magnetometer output. If you rotate it on a flat table, only z value should 
change. If not, you need to upgrade the firmware.

Indeed this is quite annoying but luckily the source code helps. And I should 
say that this IMU gives quite good attitude estimation by visualizing its 
output. I haven't done real testing on a quadrotor but I will do that soon.

What steps will reproduce the problem?
1. In a Spin file in Gedit type a range (such as 55..57)
2. See the failure to highlight.


What is the expected output? What do you see instead?

Should be the same color as other numbers (yellow for oblivion)

What steps will reproduce the problem?
1. Type a hex number in a spin program such as $1FFF or a decimal number such 
as 5000000.


What is the expected output? What do you see instead?
The number should be color coded as a constant.

In the block_test_harness.spin file, in the TimeCalculate function the time it 
takes to execute the cnt assignment is included in the calculate test time. I 
determined that this code:

time_a := cnt
time_b := cnt
diff := time_b - time_a

equals 368 cycles. But when I try to take it out by subtracting it in the 
following line:
    t1 := fp.FMul(fp.FFloat(finish_cnt - start_cnt-368), float(1000))

It gives the following output:

Maximum Time: 1.164ms
Minimum Time: 1.98ms
Average Time: 1.151ms

Without it there, the original output (uncorrected for cnt) is

Maximum Time: 1.169ms
Minimum Time: 1.103ms
Average Time: 1.156ms

The problem is that the minimum time in the first case is not actually the 
minimum. This was tested with the moment block defined in the test harness. The 
issue didn't show when I tried it with motor block instead (ie, it correctly 
subtracted the times).

What steps will reproduce the problem?
-Not relevant 

What is the expected output? What do you see instead?
I expect to see a large capacitor on the 5v servo power rail.

Please use labels and text to provide additional information.
This is on the RevA power board.

What steps will reproduce the problem?
1. Specify a filename that doesn't exist to compile

What is the expected output? What do you see instead?
Expect an error, instead it just goes on and opens a terminal.