FlySky FS-T6 Schematic and Firmware Development

Custom firmware development for the FlySky FS-T6 radio
art103
Posts: 8
Joined: Wed Jul 16, 2014 10:30 pm
Country: -

FlySky FS-T6 Schematic and Firmware Development

Post by art103 » Thu Jul 17, 2014 11:17 pm

I have completed an initial reverse engineered schematic of my FlySky FS-T6 transmitter.
It is "complete", but is likely to contain mistakes until I start implementing all of the features.
The TX has an STM32F100 with 64KB Flash and 8KB SRAM, plus an 8KB I2C EEPROM on board.

I have started a project page / blog here:
http://www2.artaylor.co.uk/ar-t6.html

So far, I have written the basic firmware to boot and initialize the LCD.
Flash space is limited, so whatever I end up implementing won't be as full featured as er9x, but I'm hoping to get the important basics in.

Comments, opinions or beer appreciated :)

art103
Posts: 8
Joined: Wed Jul 16, 2014 10:30 pm
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by art103 » Tue Aug 05, 2014 11:56 pm

All peripherals are implemented and working in the new firmware so I have provided the PDF schematic at the link above.

User avatar
Rob Thomson
Site Admin
Posts: 4537
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by Rob Thomson » Thu Aug 21, 2014 2:43 pm

Nice work!


Let me know if you would like a separate sub forum for this project.

Rob
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

seuchato
Posts: 1
Joined: Wed Oct 22, 2014 2:06 pm
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by seuchato » Wed Oct 22, 2014 2:44 pm

art103

Great work indeed. At the moement I do not have such a transmitter, but that might change soon. I might also b able to help coding/porting as I am currently porting opentx to an industrial based board.

I checked several transmitters like 9xrpro, taranis etc. Looks very interesting. There is a supplier that sports a european ce for it, see here: http://www.conrad.ch/ce/de/product/4056 ... -Kanaele-6
I know the CE will be void after mods, however I might be able to convince them to include another firmware in it. The downside of the T6 is, that it is not module based. On the other hand, it has the roller, which I prefer over the IMHO button solution of 9xr and taranis.
Got a few questions regarding your Hack:
- how did you bring your code to the mcu?
- do you think a branch of say opentx or er9 could be run on this?
- On the scheme I could not find many free pins. What optional inputs do you think can be added to this transmitter?

greez

chris

art103
Posts: 8
Joined: Wed Jul 16, 2014 10:30 pm
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by art103 » Fri Oct 24, 2014 11:52 am

Hi Chris,

I use the FRSky in my Turnigy 9x for the CE reason. I don't claim to understand the full implications, but my scant understanding is that if the radio is a module and is CE approved and you don't modify it then you're OK.

For getting code into the board, I use an STM32F100 discovery board (About £8):
http://uk.farnell.com/stmicroelectronic ... dp/1824325
You can remove two jumpers and use it as a programming and debugging probe.

I have written an entirely new framework for the STM32 to make everything IRQ and DMA driven. The only part that is er9x at the moment is the mixer. I say only... that is the most important part IMHO :)

There is a UART and I2C floating around on the board, so any additions would need to use those.
There is much less RAM and Code space in this chip compared to the T9x Atmel ones so given the lack of pins and code space I had considered telemetry a slow- to no-starter.

Everything is on github now:
https://github.com/art103/ar-t6/

I forget where I was asked, but to return the unit back to normal operation, just erase the chip and flash in the original firmware.
It also seems to detect that the EEPROM contains duff data so starts again with a clean copy.

Cheers,
Richard.


User avatar
michkrom
Posts: 28
Joined: Thu Oct 09, 2014 4:56 pm
Country: United States
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by michkrom » Tue Oct 28, 2014 5:46 am

Hi,

Just started to talk to Richard, forked his fs-t6, build, hacked my T6 and linked it with STM32F0Discovery and I am up and "cooking with gas" as they say around here :-).

This Tx looks like a good one to hack and to play with and with great rev-eng effort by Richard - it is easy.

Since the custom FW is in its infancy it not yet useful. Yet but one can revert to the original FW using ST-LINK utility and the original FW dump from Richard. So no harm done.

Michal
Michal

art103
Posts: 8
Joined: Wed Jul 16, 2014 10:30 pm
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by art103 » Tue Oct 28, 2014 9:14 am

Things are now progressing nicely. Christoph and Michal have kindly joined the effort.
I'll pull the key information from our e-mail discussions and put them here:

Some additional information on setting up a development environment:
http://minkbot.blogspot.com/2014/10/emb ... e-arm.html

The pinout for the JTAG (actually an SWD port) is in the .pdf schematic I created. The pinout for the stm32f100-disco board is in the documentation.
http://www2.artaylor.co.uk/images/ar-t6/fst6.pdf

Remove the jumpers from CN3
Connect VDD, SWCLK, GND and SWDIO from CN2 to the corresponding pins on the FS-T6 (an unpopulated 20-pin header):
VDD ---> 3v3 / pin 1
SWCLK ---> TCK / pin 9
GND ---> GND / pin 20
SWDIO ---> TMS / pin 7

For code collaboration, please create a fork from https://github.com/art103/ar-t6 and send pull requests.
Alternatively, send me a PM / e-mail with your github username to be added to the main repository as a collaborator.
Michal wrote: Code issues:
------------------
I will clean up the bool - for now let's stick to pure C99. However, in general What do you think about "C++ without heap" coding? Things like bools, stricter typing localized vars (like in for(int n..) ) etc come handy. The down is that importing code from 9x or other may be harder. (selfishness speaking - I do C++ 8+ hours a day...)
I agree on C99 for the bools. I'm not a fan of C++ in embedded MCUs, as it is very easy to bloat things and slow them down.
I use it in my day job and you are correct it has its uses, but it also has some expensive overheads at times :)
Michal wrote: EEPROM - continue to replace fixed "delay(5500)" with IRQ based "read status after write". Also, it bothers me that the "partial page write" is unexplained (experience tells me it may come back and bite me later).
The partial write is a worry - the datasheet is pretty clear on it being supported. I also agree that it is the sort of thing that will bite us at the wrong moment!
Michal wrote: Text entry - I will look at it.
MIXES - so the system setup menus in t6 are new framework not compat with 9x? I did not look at 9x code yet...Why the "temptation" to do a new one?
EEPROM size - there is 64kB of flash in CPU ...parts of it could be re-purposed (yea it's flash so slower but the EEPROM is only 8kB)...(some of the structs could be compressed such as use of bools, can do bitfield structs)..Let's worry about this later.
The mixing code is almost identical to er9x.
The GUI isn't - I struggled to get to grips with the macros and code flow / organisation of the original.
That isn't to say it is bad, just that I found it easier to re-implement a new one (with my existing LCD driver code) than port the er9x one.

We're already a fair way into the 64KB of CPU Flash. I would expect to be at ~80% use by the time the model menus are implemented.
It is also a risk erasing pages in the same flash as the main code. If anything goes wrong it's a brick until you hook up the JTAG.
The er9x EEPROM structs (global and model) already use bitfields; however depending on which parts we chose to implement some more may be removable.

That reminds me...
The FS-T6 has a UART on the PS/2 style connector on the back - technically the STM32 should have a serial boot loader that allows flashing without opening up the case. I haven't got it working yet, but that would be a great route for people who would prefer not to pull apart and solder the units.

The data model is DMA and IRQ driven wherever possible, especially on the sticks -> mixer -> PPM path. If we add other functionality to this domain (or example EEPROM updates, which are currently part DMA/IRQ and part main loop) then we must be careful to keep the priorities correct.
I'd prefer a pause in the UI due to an EEPROM update compared to a glitch on the PPM output :)

Cheers,
Richard.

User avatar
michkrom
Posts: 28
Joined: Thu Oct 09, 2014 4:56 pm
Country: United States
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by michkrom » Tue Oct 28, 2014 4:08 pm

Is there a way to have multiple threads related to AR-T6 fw work on the forum here?

SWD
The 4 wire connection did not work well for me. Lack of nSRST caused the system to hang/misbehave on each fw reload as the peripherals were not getting reset. So I have switched to 6-pin Stlink-V2 connection as in every other-than-VL discovery boards (and the STM31F0Discovery w/V2 is even cheaper then the F1). Also, there were some complains about STLINK-V1 software state (SCSI emulation broken) on openocd setups. I am planning to post my notes/pics tonite...
With only two directions on the roller (compared to four on the turnigy9x) text entry is not as easy as it could be.
It also appears broken in some cases - try setting your name in the general settings menu.
is this the intended method?:
ROLLER selects field to edit; press ROLLER to enter into a field modification (this is as today)
ROLLER initially sets cursor position in text filed (or changes value immediately in enum/num fields)
press ROLLER again to enter active character selection (shows on GUI the change of state through flashing? etc)
one of the char selections is "delete" and another "insert"?
press ROLLER to set the char and go back to cursor selection, repeat at will for other chars
press Ok to apply changes to text field and go back to field selection or press Cancel to aboard changes (not sure if this is easily possible)

Alternatively could use hold-down "cancel" (or "ok") to activate char selection? Do not like to have multipurpose buttons usually - not intuitive. Another scheme could be a dedicated screen for entering text and use of "ok" and "cancel" as up and down cursors (annotated on the screen) then roller is "left/right" and there are on-screen "buttons" : Ok/Cancel/Del/Clear that can be reached with up/down/left/right (a bit more involved aka "Roku" text editor)...

The roller "click" in my T6 is funky - does not always work even though it produces mechanical "click" ...
Michal

User avatar
Rob Thomson
Site Admin
Posts: 4537
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by Rob Thomson » Tue Oct 28, 2014 6:15 pm

Looking at the recent activity... it is time for me to make you guys a sub forum for this project?

rob
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

art103
Posts: 8
Joined: Wed Jul 16, 2014 10:30 pm
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by art103 » Tue Oct 28, 2014 7:49 pm

Hi Rob,
That would be great, please!

User avatar
michkrom
Posts: 28
Joined: Thu Oct 09, 2014 4:56 pm
Country: United States
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by michkrom » Wed Oct 29, 2014 5:09 am

Please!

In mean time here are the mods to get SWD connection on T6:

http://minkbot.blogspot.com/2014/10/fs- ... -hack.html
Michal

art103
Posts: 8
Joined: Wed Jul 16, 2014 10:30 pm
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by art103 » Thu Oct 30, 2014 8:46 am

michkrom wrote: I am planning to post my notes/pics tonite...
Good work on the blog - very useful.
michkrom wrote: is this the intended method?:
ROLLER selects field to edit; press ROLLER to enter into a field modification (this is as today)
...
Yes, I think making the cursor flash when in character cycle mode would be sensible.
That would require the addition of a timer / event for that purpose.

I like the popup idea. Failing that, what you describe with the Ok / Cancel makes more sense. I'm not a fan of long presses unless there's a short press alternative and we can support both :).

User avatar
michkrom
Posts: 28
Joined: Thu Oct 09, 2014 4:56 pm
Country: United States
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by michkrom » Fri Oct 31, 2014 4:11 am

Fixed the text edit - followed the overall edit style:
1) entering edit by pressing roller; the whole text of a field inverts
2) a small cursor (an underline) shows; it blinks; it can be moved left-right with roller;
3) pressing roller enters "character selection"l; cursor changes to big block cursor and it blinks
4) rollers selects a char and returns to #2
5) pressing roller exits edit mode

The mplementation of blinking is kinda hacky but practical IMHO. Since the edit func is constantly but timely called, every few calls the cursor blinks. I hope this constant calling was on purpose...?

I think text edit is good for now.
Michal

User avatar
michkrom
Posts: 28
Joined: Thu Oct 09, 2014 4:56 pm
Country: United States
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by michkrom » Fri Oct 31, 2014 6:28 am

Added rudimentary model selection and model name edit. Need to pull/merge to master...

The gui code may use some generalization as there is a lot of boiler plate code.
One idea would be a data driven+events for set/get/format and w/ standard types (int,string,enum) serviced by build-in stuff. This would save some code space IMHO.
Michal

seakay
Posts: 2
Joined: Sun Nov 02, 2014 11:59 am
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by seakay » Mon Nov 10, 2014 4:14 pm

michkrom

I am eagerly looking to get your code, so I can start following up and probably add some code. When do you think you can commit your changes to art103' master branch?

Greetings

SeaKay

User avatar
michkrom
Posts: 28
Joined: Thu Oct 09, 2014 4:56 pm
Country: United States
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by michkrom » Thu Nov 13, 2014 8:18 pm

master ar-t6 is up to date AFAIK

https://github.com/art103/ar-t6
Michal

mastertheif
Posts: 1
Joined: Mon Nov 24, 2014 7:11 am
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by mastertheif » Tue Nov 25, 2014 8:18 am

I just came across this project, great work!
Will you release a binary file to flash the fs-t6?

User avatar
rperkins
Posts: 1422
Joined: Sun Jan 08, 2012 12:51 pm
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by rperkins » Wed Nov 26, 2014 4:27 am

very cool
One could learn a lot following the build up of a program like this.
I even have one of those ST discovery kits but have never used it

sorry for the digression but these points interest me.
I was poking around the source and things like this always confuse me.
https://github.com/art103/ar-t6/blob/ma ... icense.doc
did some searching and this muddled it more
http://developer.mbed.org/blog/entry/CM ... -Licensed/

so this 'Cortex Microcontroller Software Interface Standard' is not open source. Do you use it in your distributed firmware ?

art103
Posts: 8
Joined: Wed Jul 16, 2014 10:30 pm
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by art103 » Wed Nov 26, 2014 9:38 am

mastertheif wrote:I just came across this project, great work!
Will you release a binary file to flash the fs-t6?
It's early days yet, but I would expect so.
The FS-T6 should also support serial update over the buddy-lead connector.
rperkins wrote: so this 'Cortex Microcontroller Software Interface Standard' is not open source. Do you use it in your distributed firmware ?
From what I have read, the interface standard (i.e. the document defining the standard) is not open source. I do not use this document, nor have I distributed it.
The source provided by ARM looks open source enough to me. IANAL, however the following taken from a source file under system doesn't seem ambiguous:
ARM wrote: * ARM Limited (ARM) is supplying this software for use with Cortex-M
* processor based microcontrollers. This file can be freely distributed
* within development tools that are supporting such ARM based processors.
It's built within a development tool that is building a binary to run on an ARM Cortex-M based device.
I'm quite happy for ARM to limit the use of this source to their devices, after all they put in the effort to create the Cortex-M architecture and software to support it.

If anyone wants to submit a patch moving the CMSIS code over to the BSD licensed version, I'm happy to accept :)

User avatar
michkrom
Posts: 28
Joined: Thu Oct 09, 2014 4:56 pm
Country: United States
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by michkrom » Wed Nov 26, 2014 5:39 pm

The CMSIS is also distruted with STM32VL discovery board package AN3862 as found here:
http://www.st.com/web/en/catalog/tools/PF257914#

However, there is no license there from STM and only a very confusing statement in release notes:
"The enclosed firmware and all the related documentation are not covered by a License Agreement, if you need such License you can contact your local STMicroelectronics office."
IANAL but the statement "...firmware and ...documentation...are not covered by License Agreement" creates legal confusion as its language suggests "no rights to any use unless such licence is obtained as we did not give you a any licence"? I can't believe it as it would require every owner of disco boards to contact them?

The STM package contains CMSIS w/ license dated 06/11/2008, where ARM allow one to copy and modify for the purpose of development of software:
1. Subject to the provisions of Clauses 2, 3, 4 and 5, ARM hereby grants to you under any intellectual property that is (a) owned or freely licensable by ARM without payment to unaffiliated third parties and (b) either embodied in either or both the Source Code and Specification, as applicable, or Necessary (defined in Clause 4 below) to copy or implement an applications binary interface compliant with the Specification, a perpetual, non-exclusive, non-transferable, royalty free, worldwide licence to:
(i) use and copy the Specification for the purpose of developing, having developed, manufacturing, having manufactured, offering to sell, selling, supplying or otherwise distributing products which comply with the Specification;
(ii) use, copy, modify and sublicence the Source Code (in source or object code form) solely for the purpose of developing, having developed, manufacturing, having manufactured, offering to sell, selling, supplying or otherwise distributing products which comply with the Specification, provided that you preserve all copyright notices included in the Source Code.


I think it _may_ not be legal to "distribute" the STM package or its parts (as in checking our own version into github) but the contained CMSIS is ok.
(now certainly freely available and given that ARM released the CMSIS itself into Apache/BSD licence we should be safe.)

However, this still leaves the parts we use from STM...need to contact them?
Michal

pabl0
Posts: 1
Joined: Tue Jan 27, 2015 6:43 pm
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by pabl0 » Tue Jan 27, 2015 7:25 pm

Hi to all!

I am very happy to see that somebody is working on firmware for FS-T6. Can't wait for first release candidate! :)

I have one suggestion. If schematic is correct, we could easily replace SWA and SWB with 3 way switches.
Their inputs on micro are ADC's and they are pulled high with 10k resistors. The only way the micro could see
them turned on is to pull them to the ground.

Example for switch SWA:
On 3 way switch the middle position is off and we connect that to connector CH5 - pin 5.
First pin of the switch we connect to the ground, the third one to 10k resistor and from this resistor
to the ground. This way we made voltage divider (3.3/2 V) and we have a 3 way switch.

pin1 (ground) ---- pin2 (CH5 pin5) ---- pin3 (10k-->ground)

What do you all think? This can be easily coded into the firmware.
Maybe this kind of mod will work on stock firmware? :?:

Regards,
pablo

art103
Posts: 8
Joined: Wed Jul 16, 2014 10:30 pm
Country: -

Alternative Switch Handling

Post by art103 » Wed Jan 28, 2015 8:51 am

Hi Pablo,

Whilst technically this is possible, it would mean having to re-architect the way switches are handled.
The switches are currently implemented as a simple GPIO read which is fast.
Moving this to one or more ADCs would increase the work required per PPM frame by a considerable margin.

Have a look at the firmware source and see what you think.

Cheers,
Richard.

User avatar
michkrom
Posts: 28
Joined: Thu Oct 09, 2014 4:56 pm
Country: United States
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by michkrom » Thu Jan 29, 2015 7:09 am

Potentially, the switches could be added to the ADC read chain, then ADC value stored in a var, and then the ppm/mixer routine would just probe the vars instead for wasting time for ADC conversion?

Alas, there is work galore to make the current FW usefull...barely getting through mixer/limits/dr systems.
Michal

mkschreder
Posts: 22
Joined: Sun Feb 08, 2015 9:22 pm
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by mkschreder » Sun Feb 08, 2015 9:27 pm

I was able to put the stm32f100 into boot mode by shorting pin 60 (BOOT0) with VDD (+). This allows low level flashing using the built in ROM bootloader. You can then use stm32flash to flash the firmware over the main serial interface on the back. The BOOT0 pin has to be pulled high before turning on the tx. When you turn on the tx with boot0 pin high, it should not boot. But it will be listening for instructions on the UART1 interface. Use a usb to serial interface to flash the firmware.

I would like to correct the notion that the chip has 64k flash. My board ver 2.3 has following specs:

Serial Config: 57600 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0420 (Medium-density VL)
RAM : 8KiB (512b reserved by bootloader)
Flash : 128KiB (sector size: 4x1024)
Option RAM : 15b
System RAM : 2KiB
LibK - Cross platform bare metal firmware development library: https://github.com/mkschreder/martink

User avatar
michkrom
Posts: 28
Joined: Thu Oct 09, 2014 4:56 pm
Country: United States
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by michkrom » Wed Feb 11, 2015 7:34 am

Martin,

It would be interesting to see if you can flash the original fw this way?
Then, to check if the original's fw upgrade method (from system menus) uses this same stm32 bootloader?

Btw, it's interesting library! How are you planning to avoid "least common denominator" effect for such a beast? E.g. the eeprom handling is in art6 is an i2c with dma & interrupts and custom code to handle this particular EEPROM. Seems hard to make portable across different MCUs or to make generic?

Thanks,
Michal
Michal

mkschreder
Posts: 22
Joined: Sun Feb 08, 2015 9:22 pm
Country: -

Re: FlySky FS-T6 Schematic and Firmware Development

Post by mkschreder » Wed Feb 11, 2015 11:05 am

Already tried flashing original firmware. Works like a charm.

When it comes to EEPROM support, libk is build such that the board "driver" is the top level interface. Typically, as I have done in my flight controller project, I would have a method in the board driver called "write_settings" and "read_settings" that would provide the service of reading and writing settings. In my implementation for the cc3d flight control board (which uses flash) I actually use a flash file system driver to arrange data in the flash. From the top level it looks exactly the same to the flight controller code - ie it only needs write/read_settings interface - but underneath the file-system driver actually takes care of never erasing any sectors in the flash until it is absolutely necessary.

So the abstractions are done from bottom up. The idea is that for most projects (ie boards) we would have a board specific interface that is defined in the board file. These interfaces are built from the reusable components of libk. If we have multiple boards that fulfil the same functionality then we could have an abstract interface for that class of boards as well - that will all provide the same API for all boards of that class. But in most cases, the application code would simply use top level services provided by the board driver to both talk to the user and control the hardware.

So for example, a transmitter board such as the FS-T6 can be though of as a class of board that provides following services: read sticks, read switches/keys, store settings (read/write), write ppm signal to radio, expose a frame-buffer for the display, expose buzzer, expose ability to read battery level. That's pretty much it. This is all that actual application code needs to know about. We can then implement the underlying functionality however we like - for instance reading adc is handled now using DMA so it doesn't require CPU to wait. In fact, one of the design goals of LibK is to never wait for anything unless it is the most efficient way to go about things.

Here is an application example for the fst6 board using the board specific interface: https://github.com/mkschreder/martink/b ... o/main.cpp

As you can see everything is hidden away nicely behind generic interfaces. Even the screen is in this case accessed though a standard serial interface (which in turn is connected to a VT100 emulator driver, which in turn accesses the screen display though a text display interface). This setup allows one to use vt100 codes printed as part of the string in order to move the cursor around etc.

The portability works as follows: all drivers that are responsible for devices outside of the chip, access these devices though interfaces provided by the "arch" layer. The arch layer is responsible for providing drivers and interfaces for the on chip devices found on a soc. So for instance, SoCs can have multiple UARTs. The board driver initializes the UARTs by calling uart_init(uart_id) for each id from 0 to 255 until the call returns -1.

An UART driver found in "arch" layer then exposes serial_dev_t interface. This is a handle that one can get by calling uart_get_serial_interface(uart_id). The serial interface can then be used to read and write to/from the specific uart in an architecture agnostic fashion. Whoever is passed the serial interface handle does not need to even know which uart number is used. This is very useful when we have drivers for things that are connected to serial interfaces such as GPS.

SPI uses the same principle - so drivers such as NRF24L01 use a generic serial interface to communicate with the NRF chip. I2C is the same - except it is an interface of type i2c_dev_t. All drivers for devices that connect through i2c are written to only use that interface to communicate with hardware - making them completely portable. One only needs to implement i2c driver for the target chip and make sure that it exports an i2c interface and one can then use any driver for any i2c device directly without having to modify any driver code - which is very useful when building for multiple platforms.

A long post, but I felt it was necessary to provide a little explanation. I know the docs are not nearly completed.. so here you have it. An overview :)
LibK - Cross platform bare metal firmware development library: https://github.com/mkschreder/martink

User avatar
michkrom
Posts: 28
Joined: Thu Oct 09, 2014 4:56 pm
Country: United States
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by michkrom » Wed Feb 11, 2015 4:32 pm

Moving discussion to "my custom library" thread.
Michal

User avatar
michkrom
Posts: 28
Joined: Thu Oct 09, 2014 4:56 pm
Country: United States
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by michkrom » Tue Feb 17, 2015 7:49 am

My first attempt to control a plane (on the ground). Not so successful. There appears to be an interruption in the ppm train about once a second. I did not see this on the scope, need to look closer!

http://youtu.be/bfuX1ElKe3Q
Michal

User avatar
jhsa
Posts: 18221
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: FlySky FS-T6 Schematic and Firmware Development

Post by jhsa » Tue Feb 17, 2015 8:57 am

Good that you removed the props ;) :D

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

User avatar
michkrom
Posts: 28
Joined: Thu Oct 09, 2014 4:56 pm
Country: United States
Contact:

Re: FlySky FS-T6 Schematic and Firmware Development

Post by michkrom » Wed Feb 18, 2015 9:39 pm

OK, this attempt looks much better after a fix to interrupt configuration. I am going to risk flying today...(crash) report later ;-)

http://youtu.be/aqvavWvj7O8
Michal

Post Reply

Return to “AR-T6”