Teensy 3.1 / MK20DX256VLH7 support

[ohanssen]

Thanks for the info. It did the trick. I used the demo example as a starting point. I have searched through the source and found the settings. I added the following to my code. Maybe these defines could be added to ...hal/boards/.../board.h since the drivers are actually activated by defining KINETIS_SERIAL_USE_UARTx.

Code: Select all

#define KINETIS_HAS_SERIAL1         TRUE
#define KINETIS_SERIAL1_IRQ_VECTOR  VectorFC
#define KINETIS_HAS_SERIAL2         TRUE
#define KINETIS_SERIAL2_IRQ_VECTOR  Vector104

[RedoX]

Hi everyone,

It's been a while but I have made some progress on the Teensy 3/3.1 port of ChibiOS.
Changelog is roughly:

• Fixed the clock init in hal_lld.c to allow for more automatic configuration, given a clock frequency.
  It still needs some refinements/bug fixes but it still works better than on my previous port.
• I started merging the K20x5 and K20x7 ports as much as possible using a common K20x base. Still WIP...
  I went with different header files, but I guess it could be done with some preprocessor macros.
  I also think the KL2x port can be included/merged in a larger Kinetis base (replacing the K20x base I made). There are some diffrerences in the clock init and also with some drivers.
• I have a somewhat working USB driver ! Still WIP. I tested it with both Teensy 3.0 and 3.1.
  It's capable of handling the SerialOverUSB driver, and I made some Raw HID tests (using the Teensy's original hid_listen and rawhid tools).
  I think the initialization is not completely correct, since the prompt of the ChibiOS Shell always gets lost (and some strange characters fed back to the input buffer).
  I would be better to use dynamic allocation for the USB buffers, but I am not sure which method would be appropriate

I will merge the last changes regarding the security bytes (as described here), but I didn't have time for that yet. I am not responsible if it bricks your board, make sure you know what you're doing before trying this code...
I have two branches, since I don't want to merge the USB stuff in my main port until it's more stable. They are available on Github: tsy_master and tsy_usb.

Any feedback is welcome, any help would also be highly appreciated.

Cheers
-RedoX

[utzig]

I'll take a look soon!

[flabbergast]

Nice to find this! I am personally very much interested in having Teensy 3.* and Teensy LC support in ChibiOS (the main point for me is the USB stack).

Please keep up the nice work! I'll try to help (e.g. by testing) if I can.

I've done a couple of USB examples (sources here) for STM23F0x2, but it would be awesome if they eventually could run on Teensies.

[RedoX]

Hello,

I don't have any Teensy-LC, and currently don't need any, so I may not work on this port.

I have, and work with, both Teensy3.0 and Teensy3.1, so the code should work on both. The USB stack is basic, but works quite well: I tried USB CDC (for SerialOverUSB) and USB HID, check out the tsy_usb/ branch on my github repository.

Any feedback/help is welcome; it's also nice to see that it can be useful to others.

-RedoX

[utzig]

People,

What would be your opinion about moving Kinetis from SVN to the community repo in Github?

[flabbergast]

What would be your opinion about moving Kinetis from SVN to the community repo in Github?

I would welcome that.

Meanwhile, I've got two compilation issues (talking about RedoX's tsy_usb branch):
- os/hal/ports/KINETIS/K20x/usb_lld.c has a couple of leftover sdPut calls, which of course fail to compile if SERIAL_USB is not enabled
- I get a (for me mysterious) warning when I use palReadPad in my code:

Code: Select all

main.c:65:5: warning: implicit declaration of function '_pal_lld_readpad' [-Wimplicit-function-declaration]

(compiling for teensy 3.0). Just adding 'palReadPad(IOPORT3, 0);' to the testhal/KINETIS/TEENSY3/USB_HID example generates this as well.

[RedoX]

Hi,

About moving to the community Github, what are the advantages ? I am afraid it would make the integration more difficult somehow, since you can't clone two repos in the same folder... I will probably keep working with my fork with the integrated changes anyway, so... do as it's easier for you =)

About the sdPut, you should comment those, or enable SERIAL (instead of USB_SERIAL). Since the driver is still WIP, i kept them, but they should be gone when ready.

About the PAL related warning, I think it's because the prototypes are not defined in pal_lld.h
After line 366, in pal_lld.h, adding

Code: Select all

uint8_t _pal_lld_readpad(ioportid_t port, uint8_t pad);

should fix it =)

Cheers,
-RedoX

[flabbergast]

About the community repo: I actually like when it's side-to-side with chibios proper, and the projects pull files from both, depending on what's required - have a look at some demos in chibios-contrib. Having two forks of chibios proper (e.g. yours and the official one) requires me to keep track of what's changed where, if I want to make sure that projects work (say) both on STM32s and Teensies.

About sdPut: I fully understand why it's there And yes, I've realized my mistake (SERIAL vs USB_SERIAL) just after I posted. Thanks!

_pal_lld_readpad: Thanks, the declaration helps. I was just confused by the fact that palSetPad worked without trouble... but then I went over the include files again and realised why one works and the other doesn't Is this a "bug" in the chibios proper?

[RedoX]

I know about the ChibiOS-contrib (and ChibiOS-driver) repositories and how they are setup, and I did something quite similar in the tsy_custom to keep some code outside the main ChibiOS/.
The main reason I said I would probably keep using my fork (and maintaining it) is that I don't want to spend time switching to a new "layout" if I'm the only one "actively" working on the KINETIS stuff... I already have enough work with other projects, and it's working as it is right now.
But if there's enough interest in the port, why not

The whole "KINETIS" port of ChibiOS, even the files in the main Github/SVN repo, is in the early stages of development, so there are bugs and missing stuff here and there; I wouldn't call that a "bug"