Hi,

Any alternative to this MCU with high lead times on all distributors?

Thanks,

Hello, Werner:
Sorry to trigger another issue to you. Now I followed the instructions in firmware/readme.md to build mk4.
On my win7, I installed latest tool-chains:
gcc-arm-none-eabi-5_2-2015q4-20151219-win32.exe
make-3.81.exe
coreutils-5.3.0.exe

Compile is OK but there is some conflicts in the linking session.
Please see my my console:

[CC] ch3_handler.c
[CC] channel_reversing.c
[CC] config.c
[CC] config_light_programs.c
[CC] config_lights.c
[CC] crt0.c
[CC] drive_mode.c
[CC] indicators.c
[CC] light_programs.c
[CC] lights.c
[CC] main.c
[CC] persistent_storage.c
[CC] preprocessor_output.c
[CC] servo_output.c
[CC] servo_reader.c
[CC] uart_reader.c
[CC] uart0.c
[CC] utils.c
[CC] winch.c
[LD] build/firmware.elf
c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bi
n/ld.exe: section .init loaded at [00002c00,00002c03] overlaps section .data loaded at [00002c00,00002c3f]
collect2.exe: error: ld returned 1 exit status
make: *** [build/firmware.elf] Error 1

From my understanding, the latest gcc might change _init @crti.o.

See the firmware.map:
.init 0x00002c00 0x4
.init 0x00002c00 0x4 c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/armv6-m/crti.o
0x00002c00 _init

.init will conflict with this .data segment:
.data 0x10000000 0x40 load address 0x00002c00
0x10000000 _data = .
(.data)
.data.throttle_threshold
0x10000000 0x2 build/./drive_mode.o
.data.old_light_switch_position.5100
0x10000002 0x1 build/./lights.o
fill 0x10000003 0x1
.data.last_found.5824
0x10000004 0x4 build/./main.o
.data.st.5839 0x10000008 0x2 build/./main.o
.data.th.5840 0x1000000a 0x2 build/./main.o
.data.channel 0x1000000c 0x30 build/./main.o
0x1000000c channel
.data.next_tx_index
0x1000003c 0x1 build/./preprocessor_output.o
0x10000040 . = ALIGN (0x4)
fill 0x1000003d 0x3
0x10000040 _edata = .

It looks cortex-m0+ belongs to armv6-m branch. So I did not have any idea about this issue.
I could not upload my firmware.map here for some network issue. If you need, need me know.
Could you please take a look? What I would like to do is evaluate how many SRAM this project needs.

Many thanks and Respect to this awesome project.

BR
Locke

Hi,

After building the project with a 5-ch pre-processor I am not able to turn any led ON. I have connected ch3 from receiver into AUX of the pre-processor and light output of 5 ch pre processor to master light controller. Stearing and Throttle works fine. I am using MkP4 rev1 and using a jumper to connect led anode to VIN. I have tested the Mk4P board with the blinking led test firmware and I also have used led15 to be always on, so I know it is working this part.

How can I debug the issue of receiving the CH3 signals?

Will appreciate your comments,
Thanks,

First off, thanks for creating and documenting such an awesome rc-light-controller! I'd been looking for a programmable led controller for a while for my 1:10 drifter and Slash. So accidentally stumbling on the mark1 video made my day :)

While ordering the mark4 at OSHPark i got missing board outlines on the gerber zips, and missing texts in the brd file previews. Even when i tried to reproduce the nicely shared mark2 Shared Project.

Now, i know about software, but i'm a complete noob in electronics, but i think i figured it out: :)
for OSHPark the Gerber zips were missing a specific outline file, and the brds have their text in the tValues layer instead of the tNames.

So, i updated a CAM file from OSHPpark to take for the:
Top Silkscreen: 27 tValues instead of 25 tNames
Bottom Silkscreen: 28 bValues instead of 26 bNames

..and regenerated the gerber files for the 3 PCBs. They all look perfect now in the OSHPark preview, as well as in http://mayhewlabs.com/3dpcb. If you want to take a look, i guess i could do a git-pull-request, or simply mail them or something?

thanks,
/Sander.

Hello, I find small issue. Maybe need you confirm.

Scenario:
Before system is correctly setup(steel, reversing etc), just get normalize via normalize_channel().
normalize value looks not OK since the default endpoint is not correct.

You see, right is large than centre, so what the normalize I got is:
Left: 0, centre 0, right: ~60.

After change right from 1450 to 1750, Left-centr-right is almost -100 to 100.

CHANNEL_T channel[3] = {
{ // STEERING
.normalized = 0,
.absolute = 0,
.reversed = false,
.endpoint = {
.left = 1250,
.centre = 1500,
.right = 1450,
}
},

BR
Locke

Please check void SCT_irq_handler(void) in rc-light-controller-master\mk4-tlc5940-lpc812\firmware\servo_reader.c

                if (channel_flags & (1 << i)) {
                    output_raw_channels(result);
                    channel_flags = (1 << i);
                }
                channel_flags |= (1 << i);

whatever channel_flags and i change, output_raw_channels() is impossible to run. I picked up related code and verified in VS2015. Obviously, output_raw_channels(result) has no chance to run.

Locke