Custom Saleae Logic Analyzer plugin load fails on OSX with "Unable to 'dlopen' so/dylib " error 

One of our custom analyzer plugin started to fail to load after started using an std::set variable with the error above with the similar output from the Logic:


Starting /Applications/Logic.app/Contents/MacOS/Logic...
exe File path is /Applications/Logic.app/Contents/MacOS/Logic [ /Users/build/ob_logic/Source/Environment.cpp; Environment; 260 ]
exe folder path is /Applications/Logic.app/Contents/MacOS [ /Users/build/ob_logic/Source/Environment.cpp; Environment; 261 ]
Release Mode; analyzer path is /Applications/Logic.app/Contents/Resources/Analyzers [ /Users/build/ob_logic/Source/Environment.cpp; Environment; 283 ]
Release Mode; exe path is /Applications/Logic.app/Contents/MacOS; user path is /Users/Miklos [ /Users/build/ob_logic/Source/Environment.cpp; Environment; 318 ]
Found log directory at Library//Logs//DiagnosticReports [ /Users/build/ob_logic/Source/Environment.cpp; Environment; 327 ]
dlopen fail (null) [ /Users/build/ob_logic/Source/AnalyzerManager.cpp; LoadAnalyzersAtPath; 159 ]
dlopen fail dlopen(/Users/Miklos/git/saleae_xline_analyzer/bin/libXLiNEAnalyzer.1.0.dylib, 1): Symbol not found: __ZTISt12out_of_range
Referenced from: /Users/Miklos/git/saleae_xline_analyzer/bin/libXLiNEAnalyzer.1.0.dylib
Expected in: /Applications/Logic.app/Contents/MacOS/../MacOS/libAnalyzer.dylib


Solution:

Add -lc++ to the linker flags before the -lAnalyzer.
[ hozzászólás ] [ 0 trackbackek ] permalink ( 0 / 0 )
STM8 compiler comparison SDCC vs. Cosmic 

I have converted a project previously built with Cosmic to be compiled with SDCC.

The size results were really bad, the project cannot fit in the 8K memory of the STM8S003:

SDCC:

flash size: 6912 occupied: 8706 (125.95%) free: -1794 (-25.95%)

sensor size: 2092 (30.27%)
interrupt size: 1959 (28.34%)
signalprocessing size: 1577 (22.82%)
xlineslave size: 1309 (18.94%)
led size: 988 (14.29%)
init size: 253 (3.66%)
config size: 129 (1.87%)
delay size: 123 (1.78%)
seedbuffers size: 104 (1.50%)
main size: 86 (1.24%)
adc size: 86 (1.24%)


While Cosmic:

flash size: 6912 occupied: 6480 (93.75%) free: 432 (6.25%)

interrupt.o size: 1540 (22.28%)
sensor.o size: 1464 (21.18%)
xlineslave.o size: 802 (11.60%)
signalprocessing.o size: 688 (9.95%)
led.o size: 559 (8.09%)
ldiv.o size: 235 (3.40%)
init.o size: 222 (3.21%)
lmul.o size: 139 (2.01%)
config.o size: 131 (1.90%)
interrupt_vectors.o size: 128 (1.85%)
crtsi0.sm size: 80 (1.16%)
delay.o size: 73 (1.06%)
main.o size: 69 (1.00%)
adc.o size: 60 (0.87%)
seedbuffers.o size: 45 (0.65%)
imul.o size: 33 (0.48%)
lcmp.o size: 32 (0.46%)
lgadd.o size: 23 (0.33%)
lsbc.o size: 23 (0.33%)
lneg.o size: 21 (0.30%)
cmulx.o size: 20 (0.29%)
ludiv.o size: 20 (0.29%)
lgneg.o size: 19 (0.27%)
rtol.o size: 18 (0.26%)
lursh.o size: 15 (0.22%)
lgursh.o size: 14 (0.20%)
utolx.o size: 7 (0.10%)


The total flash size is just 6912 bytes because of the bootloader.
[ hozzászólás ] ( 1 megtekintés ) [ 0 trackbackek ] permalink ( 0 / 0 )
Beware of the chinese 5 output chargers sold with 150mAh LiPos! 

One of my friend bought a similar 5 pack of 150mAh LiPo batteries + 5 output USB charger from ebay for his Furibee F36:



He told me that the batteries bought with it start loosing their capacity after a short period.

He also noticed that the charger charged pretty quickly the at the first cycles too.

After tearing apart the charger we figured out that reason for both thing (the degradation and the fast charge):

There are 5 individual chargers on the PCB built around the LTC4045 IC.



The charging current is controlled by a resistor which was 2700 Ohm in the board.

If we look into the datasheet we find the equation of the charging current:


As you can calculate the charging current is set to 1000V/2700Ohm == 370 mA. In the case of a 150mAh battery the charging current is ~2.5C which is pretty high. Usually it is recommended to charge with maximum 1C these batteries.
1C gives us 1000/0.150 == 6666Ohm for prog resistor. It is not so common resistor, so a 6800Ohm (charge current == 147mAh)should fit well.

We wish your batteries long life!

[ hozzászólás ] ( 3 megtekintés ) [ 0 trackbackek ] permalink ( 0 / 0 )
DJI Phantom 1 SR6 transmitter teardown 

I have not found any info on the web about this topic, so I was curious what RF frontend did they used.



Solution was obvious: they have used the same as they used in the receiever: the CYRF6936.

I was hoping for having some UART to hook up an Arduino to get trainer output, but I had to get disappointed.

The lower 5 pin connector is the ICE connector of the Nuvoton MINI54ZAN with:
VCC, ICE_DAT, ICE_CLK, !RESET, GND, GND

And the 3 pin is:
P2.3, GND P2.4
[ hozzászólás ] ( 3 megtekintés ) [ 0 trackbackek ] permalink ( 3 / 10 )
Nikko C1069C protocol reverse engineering 

I have did some reverse engineering on one of my old Nikko transmitters which is based on the Nikko C1069C ASIC.

My plan is to get rid from the old transmitters and emulate the protocol in a 27 Mhz PPM transmitter with an MCU.

Here are my findings:
The IC sends out the encoded serial signal on pin 2.

Frames sent out with ~30 ms interval.

The frame could be separated to 3 segments:
1st is the steering:
- If steering is in norminal state 168 us L, 1433 us H is sent
- If steering is in right state 168 us L, 3706 us H is sent
- If steering is in left state 168 us L, 252 us H is sent

2nd part is the motor:
- If motor is in norminal state 168 us L, 1433 us H is sent
- If motor is in forward state (no turbo) 168 us L, 252 us H is sent
- If motor is in backward state 168 us L, 3706 us H is sent
- If motor is in forward turbo state 168 us L, 252 us H is sent 168 us L 500 us H is sent

There is a 3rd optional segment the horn:
- If the horn/whatever else button is pressed 168 us L 500 us H 168 us L 500 H sent.

There is a static end part:
- 168 us L 500 us H 168 us L -> H


[ hozzászólás ] ( 4 megtekintés ) [ 0 trackbackek ] permalink ( 3.3 / 12 )

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Következő> >>

 
számláló