I need to communicate to the board over a serial port but I need to keep UART0 in use as is in order to have USB connectivity for downloading code, debug etc. First glance at the code makes it look like you use one or the other but not both. Is there some sample code that uses both the USB bridged uart / serial port and another serial device using UART1 or do I need to write my own driver to handle this?
Thanks
John
Thanks for the replies Mark and Yong Li. I'm using the BLDC_Sensorless Project labs and the Freemaster application to start with to configure and control our motor. The other board in the tower is a TWR-MC-LV3PH. Right now we're using the Linix motor that comes with the kit but we're in the process of trying to get our real motor working using the tuning app.
Eventually the Freemaster app will go away and we'll set all the motor parameters up in SW and then communicate via a serial link from/to another controller board that basically replaces the PC running Freemaster and will send speed commands to the KV10 and get back status. I used the QuickStartPackage available on the Freescale web page to get started and I'm using IAR to compile and download.
Mark, would it be pretty straightforward to pull in your dual UART implementation from the uTasker project into my project?
Hi John
Have you modified the BLDC_Sensorless code yet to add your own additional functionality or are you using it 'as delivered'?
I checked the project to see how it operates and see that it is a fully blocking SW solution which presently only uses the FreeMaster interface as basis for control and monitoring. Although it is quite easy to add the second UART to it as it is I wouldn't do it (personally) because it still results in a polling/blocking based approach that will quickly become difficult to extend in a modular fashion (with risks of deterministic performance loss once multiple interfacs are in operation).
The motor control part is fine since it is being controlled purely based on interrupts and some control variables (which are presently controlled by FreeMaster).
The way that I would do it would be to place the content of main() into a task and not use the existing UART interface(s) (polling and blocking) but instead open them from the task so that they benefit from DMA, flow control etc. This task will then be idle when there is no UART communication so that the processor can utilise its low power capabilites rather than spinning on the UART interfaces. Often the power consumption can be reduce by around 50% with no loss of functionality/reaction time (depending on interrupt load). The BLDC_Sensorless functionality would be maintained, but become more efficient due to removal of polling and blocking interfaces, and multiple UARTs and low power support, etc. will be available as and when required. With the possible exception of some library code that the lab is using the rest would become environment independent and so work with CodeWarrior, KDS etc. without any further effort (in case IAR is not the preferred final solution).
This may take a couple of hours to adapt (mainly due to the IAR project configuration and probably to avoid some contentions in the libraries) but the uTasker project is also available as IAR project so it would be a case of suitably merging to a single configuration.
I also checked the lab's clock configuration and see that it was set up to work at 75MHz from the oscillator but this was commeneted out and it actually runs at 72MHz from an internal source. Perhaps this is due to similar debugger difficulties that I had encountered??
Regards
Mark
Kinetis: µTasker Kinetis support
KV10: µTasker Kinetis TWR-KV10Z32 support
For the complete "out-of-the-box" Kinetis experience and faster time to market
Hi John
Update:
Since I wanted to make some progress on the KV10 port I have done some more work and integrated the FreeMaster UART interface into the project (on UART1) whereby I have retained the command line interface on UART 0 (accelerometer data can still be enabled in the I2C menu rather than being always on over UART1). A binary is attached in case you would like to load it to the TWR-KV10Z32 and verify both UARTs (especially FreeMaster use). Of course the variables don't match with the LAB project but it can be seen that the connection is good and (changing) values are seen.
The UARTs are now using DMA and there is no more more polling and current is reduced since it uses low power modes whenever there is no activity.
Thsi has been built and tested using IAR, KDS and GCC standalone to ensure that there is nothing compiler dependent.
What I didn't do (yet) is add the motor control parts from the LAB project but the only thing actually missing (but requires adding the files and library) are the calls
MCU_init()
and
M1_SetAppSwitch(1)
and the rest should then automatically operate identically (entirely controlled by FreeMaster and interrupts).
This is however not so simple to do cross-platform due to the complicated header and file structures involved in linking in the project files pulled in by these routines and also the fact that there is a library involved (probably IAR specific?) but of course the IAR version shouldn't pose any big complications.
As a side note, this version also includes RTC support - see µTasker FRDM-KL02Z support (available in the command line shell) which was originally developed for the KL02 (which has no inbuilt RTC) but is also practical for the KV10 since it also hasn't one, but this SW based solution allows Gregorian time/date and alarms to be used as well as maintaining the time over software resets!
Regards
Mark
Kinetis: µTasker Kinetis support
KV10: µTasker Kinetis TWR-KV10Z32 support
For the complete "out-of-the-box" Kinetis experience and faster time to market
Hi John
Last update:
- By adding the header files and a handful of C files from the original project, plus the CM0+_MMCLIB_IAR.a I could build the BLDC_Sensorless project (with IAR)
- It has the uTasker OS with DMA based UART drivers for UART0 at 115'200 Baud (command line shell interface with quite a lot of functionality; RTC, accelerometer, lower power support, etc.) and UART1 (FreeMaster at 9'600 Baud)
Apart from connecting wiith FreeMaster and viewing variables (and seeing soem output pulses) I can't test the BLCD_Sensorless operation (also no motor/extension board available) but I could verify that the ACD0, FTM1 and FTM2 interrups are operating.
The only changes to the driver code used by the motor control part was to configure the interrupt to match the framework style (and operate in RAM), which looks like (eg.)
fnEnterInterrupt(FTM1_IRQn, ISR_PRIORITY_FORCED_CMT, FTM1_Isr);
instead of
enable_irq(FTM1_IRQn);
set_irq_priority(FTM1_IRQn, ISR_PRIORITY_FORCED_CMT);
I have attached the binary which just still fits into the Flash (it has loads of strings for the command line interfaces many menus and other features so doesn't need to be so larger).
Also the .out file that can be read in by FreeMaster to synchronise its variables.
I have a complete IAR project in case of interest to check out the environment for future product development.
Below is a screen shot of the IAR workspace showing the BLCD part inserted into the uTasker application framework:
Regards
Mark
Kinetis: µTasker Kinetis support
KV10: µTasker Kinetis TWR-KV10Z32 support
For the complete "out-of-the-box" Kinetis experience and faster time to market
Hi Mark,
Thanks for all the work on this. My main concern is having to pull in uTasker for your implementation due to code size. How much will this add to my code, and is it easily configurable to pull out un-needed stuff like TCP/IP etc and only pull in what I need?
We weren't planning on pulling in an OS for this project so I'm not sure it's even an option for me. I do like the fact that power could be reduced and it would be non-blocking so I may bring this up as an option.
I may be able to get by with one UART and use JTAG for download and debugging but it's not the ideal solution for us.
Thanks,
John
Hi John
If the parts doesn't have Ethernet the TCP/IP stack (and USB etc.) are automatically removed so there is no effort required on main configurations.
The cost of an OS with drivers for both UARTs, watchdog task and non-blocking operation on top of the BLDC project is +4.2k
- a second application interface with "Hello, World" type output on UART0 and minimal user interface is +4.5k (i.e. +4.2 + 0.3k)
- with DMA operartion on both UARTs it is +5.0k (i.e. 4.5k + 0.5k)
- with dymanic low power support it is +5.5k (i.e. 5k + 0.5k)
- etc. depending on which features are of use in the project and enabled
{These sizes are with interupt vectors located in SRAM, which is a bit faster than the original Flash location. By putting then back to Flash a further size reduction of up to about 1k can be achieved}
However, since the OS includes various functions (software timers, queue systems etc.) that can be used by the application (rather than having to add them when needed to achieve the project's behavioral requirements) the difference reduces as the application grows (because the functions would need to be developed and added - taking up this space - anyway).
See also : https://community.freescale.com/message/485881#485881
which shows that the OS includes everything you need for using formatted output and in case this is done by using libraries instead the code size will tend to explode to a multiple of the OS size anyway (and still leave various things unsolved).
However code size is not necessarily the main argument since the OS generally makes development easier and more reliable. It also allows the project to be simulated (in VisualStudio - free Express Edition is adequte), which can greatly accelerate much development work.
In case you need something like a parameter system or external SPI Flash storage capabilities it can be added by enabling a single project define and it is there. If you later move up to a Kinetis part with USB it will still be compatible (assuming peripherals available) but you could add USB operation with a single define change. This is valid right up to processors with Ethernet where the TCP/IP stack could be enabled without changing any of the original application code.
So at the end of the day it is more a question of whether 4.2k is more expensive than ability to significantly reduce project time scales and obtain easy to maintain code for future advancements.
As reference I have attached a build with just a "Hello, world" and echo on the application/debug UART (UART 0) to show the + 4.5k case; The BLDC part is all there with FreeMaster on UART1.
Further noteworthy advantages of the framework is that if there is USB available FreeMaster can operate over it, which is presently not possible with the standard FreeMaster project code (this in parallel with other USB-CDC interfaces and/or MSD, HID etc. as composite device). Not an issue for this chip (without USB) but worth noting generally. Although not in this binary the uTasker FreeMaster implementation allows optionally reading and writing from/to Flash (both internal and SPI based types)
Regards
Mark
Kinetis: µTasker Kinetis support
KV10: µTasker Kinetis TWR-KV10Z32 support
For the complete "out-of-the-box" Kinetis experience and faster time to market
John
If you are logged in all attachment should be visible - I can see them. Perhaps you looked before logging on or your browser has a difficulty with them?
I have copied them to these locations too:
Regards
Mark
Kinetis: µTasker Kinetis support
KV10: µTasker Kinetis TWR-KV10Z32 support
For the complete "out-of-the-box" Kinetis experience and faster time to market
I was logged in but for some reason couldn't see the attachments. As soon as I clicked your links all the attachments show up for the other parts of the thread too.
Can you attach the source so I can build this and make changes?
thanks
John
Hi John
The complete project is on the uTasker developer's site at http://www.utasker.com/kinetis/developers.html
See "10.3.2015 Three-Phase Brushless DC Sensorless Control - IAR for TWR-KV10Z32"
Please see your personal message input for details.
To build it:
- open the IAR workspace \Applications\uTaskerV1.4\IAR7_Kinetis\uTaskerV1.4.eww
- all settings are prepared so command build.
Operation:
- the entry point that will interest you as orientation point is in Applications\uTaskerV1.4\application.c in the function fnOpenFreeMasterUART()
- after the FreeMaster UART has been opend there are calls to
MCU_init();
FMSTR_Init();
M1_SetAppSwitch(1);
- the interrupts and UpdateBldcHwModules() are then just below in that file (copied from the original main.c)
The 'debug' UART is handled in the application task in that same file and is just doing
while ((Length = fnRead(SerialPortID, ucInputMessage, MEDIUM_MESSAGE)) != 0) {
fnEchoInput(ucInputMessage, Length);
}
You'll not need to be aware of any other uTasker files and can concentrate on the original BLDC content although it you want to see that it is operating you can look at the watchdog task in \uTasker\Watchdog.c which is being scheduled once every 200ms.
You mentioned that FreeMaster is a provisional control interface. The project also supports MODBUS on the UARTs (ASCII or RTC) so a MODBUS based control implementation would be possible too: µTasker MODBUS Extension pack
Regards
Mark
Kinetis: µTasker Kinetis support
KV10: µTasker Kinetis TWR-KV10Z32 support
For the complete "out-of-the-box" Kinetis experience and faster time to market
Hi Mark,
Thanks..... I got it running and saw "Hello, world... KINETIS" and characters entered are being echoed. I'll play around with this more when I get the tower back. Right now I just have a standalone TWR-KV10Z32 and someone else is using the motor controller and tower. Right now the BLDC_Sensorless application fails since it can't talk to the motor controller.
Thanks
John
Hi John
OK. I also have only the board so can only verify that all clocks and communication are OK and that the interrupts are firing.
Since the BLDC part is otherwise very independent from the rest (almost exclusively controlled by the interrupts) I don't see any reason why it won't work as before but there is of course alway a remaining risk that can't be excluded without full testing.
Regards
Mark
Kinetis: µTasker Kinetis support
KV10: µTasker Kinetis TWR-KV10Z32 support
For the complete "out-of-the-box" Kinetis experience and faster time to market
Hi John
I wanted to update on the code size due to the fact that my version of IAR7 has a bug (CALL 465414g_IAR) which only occurs when using highest optimisation. For this reason I use medium optimisation rather than high (it is fixed in version 7.30.4 and above). If highest optimisation is actually used the size difference is about 1k Bytes less than I previous stated (therefore about 3.4k instead of 4.2k with reduction possibility with fixed Flash interrupt vectors to about 2.5k).
Regards
Mark
Kinetis: µTasker Kinetis support
KV10: µTasker Kinetis TWR-KV10Z32 support
For the complete "out-of-the-box" Kinetis experience and faster time to market
Hi John
Note that the KV31 framework has now been prepared (supporting 3 UARTs and one LPUART - all DMA based) - µTasker Kinetis TWR-KV31F120M support
and its PMSM Sensorless application will be used as a test vehicle for industrialisation verification.
Regards
Mark
Kinetis: µTasker Kinetis support
KV10: µTasker Kinetis TWR-KV10Z32 support
KV31: µTasker Kinetis TWR-KV31F120M support
For the complete "out-of-the-box" Kinetis experience and faster time to market
Hi Flack,
I would recommend using CodeWarrior v10.6 (download it directly from Freescale website) and creating a project by yourself.
it is easy to do it by using Processor Expert (a software tool that integrated in CW).
the step is as below:
1. launch CW v10.6 and click "File"->"New"->"bareboard project"
2. give a name to the project and select "mkv10z32" as the device.
3. "CHECK" "OpenSDA" in step "connections"
4. choose "Processor Expert" in step "Rapid Application Development" and then click "Finish", you will created a new project
5. in the new created project, from "Component" tab, double "ConsoleIO" to add this component to this project. then confige this component IO1 to UART0.
6. add another component "Serial_ldd" to project and confige to UART1.
After configuration, generate code.
Add your code in main.c.
printf() will output string to UART1 from USB port when debugging by using OpenSDA. data put from UART1 will output to UART1.
the UART communication methods are in the generated PE files.
Hope it helps!
Hi John
I don't know which SW you are referencing to or what is presently available for this device but if you are feeling brave you are welcome to try with the (extremely) new TWR-KV10Z32 framework in the uTasker project.
I have attached a binary for the TWR-KV10Z32 which has a UART menu (shell) on the OpenSDA UART0 connection (115'200 Baud). The accelerometer is being read and output values are written to UART1 (by moving the jumper on J22 from the default setting 2-3 to 3-4 this (also 115'200 baud) this will be sent over the OpenSDA virtual COM port - but is of course available as UART signals in parallel).
Both UARTs are operating in DMA mode and there are various other things that it does - mostly controlled in menus on the UART0 connection.
Truth is I started the port only a few hours ago but since the KV is very close to a standard K device almost all standard driver code works on it (with a few adjustements here and there). I only checked a few things like UARTs and I2C so there will probably be a few more adjustments needed before it can be called complete. However the uTasker simulator has been adapted to the board so that it accurately shows pin usage etc. Screen shot below.
A couple of things that I haven't understood just yet:
- the FLL is operating at 50MHz; when trying 75MHz it runs but looks to not manage to lock correctly and there may be something needed to get the high-speed mode going correctly.
- I am having a hard time with the debugger - if I run the FLL derived from the fast internal clock it behaves well but running with the FLL derived from the 10MHz external clock causes the debugger to disconnect as soon as it switches to the higher speed (?)
Therefore I also have plenty to learn about the device before becoming really proficient.
A simple tip with UART1 is however that it can use code from any old K device and just needs to respect that whilst UART0 is clocked at the core speed UART1 is clocked at the bus speed instead (in K devices both UARTs 0 and 1 are clocked at core speed).
Regards
Mark
Kinetis: µTasker Kinetis support
KV10: µTasker Kinetis TWR-KV10Z32 support
For the complete "out-of-the-box" Kinetis experience and faster time to market