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.
