headers
Tomas Frydrych | 1 Dec 2011 14:54

Re: i2c kinetis driver

I put a patch into bugzilla,

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001397

Just basic i2c with 7 bit addressing for now.

Don't know if it's worth registering as a project in it's own right?

Tomas

On 20/11/11 17:04, Ilija Kocho wrote:
> Hi Tomas
> 
> Thank you for jumping in.
> It is indeed a good practice to put such questions here. I am not aware
> of someone working on I2C for Kinetis. Having said that, I do work on
> SPI driver.
> Registering project(s) at http://ecos.sourceware.org/contrib.html may
> help for duplication avoidance.
> 
> Ilija
> 
> 
> On 20.11.2011 13:55, Tomas Frydrych wrote:
>> Hi,
>>
>> Is anyone working on an i2c driver for Kinetis? If not, I can look into
>> porting the lm3s driver, but would prefer to avoid duplicating someone
>> else's effort. :)
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ilija Kocho | 1 Dec 2011 16:37
Picon

Re: i2c kinetis driver

On 01.12.2011 14:54, Tomas Frydrych wrote:
> I put a patch into bugzilla,
>
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001397
>
> Just basic i2c with 7 bit addressing for now.
>
> Don't know if it's worth registering as a project in it's own right?

Tomas

Thanks for contribution.
Registering helps to avoid duplicate projects. But now since driver is
in Bugzilla it is less likely.
Maybe we could consider listing in-Bugzilla projects at web page.

Ilija

>
> Tomas
>
>
> On 20/11/11 17:04, Ilija Kocho wrote:
>> Hi Tomas
>>
>> Thank you for jumping in.
>> It is indeed a good practice to put such questions here. I am not aware
>> of someone working on I2C for Kinetis. Having said that, I do work on
>> SPI driver.
>> Registering project(s) at http://ecos.sourceware.org/contrib.html may
(Continue reading)

Permalink | Reply | 0 comments |
headers
Liam Knight | 8 Dec 2011 06:36
Picon

eCos port to Cobra 5329

Hello

I have started a BSP for senTec's COBRA5329 starter kit for eCos.

I was using the uClinux dragonfire gcc compiler
(m68k-uclinux-gcc-4.1.1) but noticed you have a more recent 4.3.2
m68k-elf toolchain which I switched to but it will not run on a 64-bit
system by default:
$ m68k-elf-gcc -v
bash: m68k-elf-gcc: /lib/ld-linux.so.2: bad ELF interpreter: No such
file or directory
$

Your instructions in http://ecos.sourceware.org/getstart.html say you
need to install the libstdc++ v3 compatibility package but make no
mention that the tools are built for 32bit linux and so also require
the 32-bit version of glibc on 64-bit systems. You may wish to update
your instruction on that web page as 64-bit systems are rapidly
becoming the norm so many users will fall foul of this.

The problem is easily fixed on Fedora:
$ yum install ld-linux.so.2

which you should add to the web page for 64-bit installations.

LK
Permalink | Reply | 2 comments |
headers
Tomas Frydrych | 8 Dec 2011 09:04

Re: eCos port to Cobra 5329

Hi,

On 08/12/11 05:36, Liam Knight wrote:
> Your instructions in http://ecos.sourceware.org/getstart.html say you
> need to install the libstdc++ v3 compatibility package but make no
> mention that the tools are built for 32bit linux and so also require
> the 32-bit version of glibc on 64-bit systems. You may wish to update
> your instruction on that web page as 64-bit systems are rapidly
> becoming the norm so many users will fall foul of this.

I'd go further and say that 64-bit linux systems are and have been the
norm for a while now :-) -- I think it would be desirable to provide
native 64 bit packages rather than instructions on how to work around
the problem.

Tomas
Permalink | Reply | 0 comments |
headers
John Dallaway | 8 Dec 2011 09:36
Picon

eCos host tools on 64-bit Linux [ was Re: eCos port to Cobra 5329 ]

Liam

Liam Knight wrote:

> Your instructions in http://ecos.sourceware.org/getstart.html say you
> need to install the libstdc++ v3 compatibility package but make no
> mention that the tools are built for 32bit linux and so also require
> the 32-bit version of glibc on 64-bit systems. You may wish to update
> your instruction on that web page as 64-bit systems are rapidly
> becoming the norm so many users will fall foul of this.

Thank you for reporting this. I have updated the getting started page.
To be clear, installing the 32-bit libstdc++ library (required for the
eCos host tools) should also bring in 32-bit glibc and loader.

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john
Permalink | Reply | 0 comments |
headers
Tomas Frydrych | 15 Dec 2011 17:57

Adding Kinetis boards

Hi,

I am looking at adding the Kwikstik to the current Kinetis boards, and I
am wondering what would be the best way to approach this.

Currently there are two Kinetis boards, the TWR-K40X256 and TWR-K60N512,
with the directory structure something like this:

kinetis/var/...     - Generic Kinetis code
kinetis/twr_k40x256 - K40 and twr-k40 code
kinetis/twr_k60x256 - K60 and twr-k60 code

Kwikstik is based on the same MCU as the twr-k40x256, so it needs the
same MCU-specific code as the twr-k40x256 board, which I think is all,
or nearly all of the code currently under the twr_k40x256 directory.

I initially thought I'd just clone twr_k40x256 into a new kwikstik
directory, but that's probably not the best approach for
maintainability. I am thinking it might be better to split out the
generic K40 code so it can be shared between distinct boards, but I am
not sure where to split this to: should there be a separate k40x256
subdirectory and a corresponding package that the twr_k40x256 requires?
Or is there a better way of approaching this altogether?

Many thanks in advance,

Tomas
Permalink | Reply | 4 comments |
headers
Ilija Kocho | 15 Dec 2011 19:04
Picon

Re: Adding Kinetis boards

Hi Tomas

It may be just enough to add a new target entry in ecos.db.
I am not familiar with Kwikstik I only know that it is based on same
chip as TWR-K40. Can you please point the differences between boards
with respect to: HAL, devices, etc.

Ilija

On 15.12.2011 17:57, Tomas Frydrych wrote:
> Hi,
>
> I am looking at adding the Kwikstik to the current Kinetis boards, and I
> am wondering what would be the best way to approach this.
>
> Currently there are two Kinetis boards, the TWR-K40X256 and TWR-K60N512,
> with the directory structure something like this:
>
> kinetis/var/...     - Generic Kinetis code
> kinetis/twr_k40x256 - K40 and twr-k40 code
> kinetis/twr_k60x256 - K60 and twr-k60 code
>
> Kwikstik is based on the same MCU as the twr-k40x256, so it needs the
> same MCU-specific code as the twr-k40x256 board, which I think is all,
> or nearly all of the code currently under the twr_k40x256 directory.
>
> I initially thought I'd just clone twr_k40x256 into a new kwikstik
> directory, but that's probably not the best approach for
> maintainability. I am thinking it might be better to split out the
> generic K40 code so it can be shared between distinct boards, but I am
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tomas Frydrych | 15 Dec 2011 20:55

Re: Adding Kinetis boards

Hi Ilija,

On 15/12/11 18:04, Ilija Kocho wrote:
> It may be just enough to add a new target entry in ecos.db.
> I am not familiar with Kwikstik I only know that it is based on same
> chip as TWR-K40. Can you please point the differences between boards
> with respect to: HAL, devices, etc.

I think HAL-wise the Kwikstik board is the same as the twr-40x256, it
just exposes different features of the MCU through the attached devices,
which include a microphone, a buzzer, an audio output, rechargeable
battery (with usb charging), a dot-matrix LCD.

The Kwistik is attractive because of its low cost (~$30), and even comes
with an on board Segger J-Link chip! Seems like an affordable base for
all kinds of hobby projects.

I think just having an additional target might work with all the
differences handled in device implementation, and all the HAL
functionality subsumed under the twr-k40x256, e.g., in the case of the LCD.

Tomas

> 
> Ilija
> 
> On 15.12.2011 17:57, Tomas Frydrych wrote:
>> Hi,
>>
>> I am looking at adding the Kwikstik to the current Kinetis boards, and I
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ilija Kocho | 16 Dec 2011 09:38
Picon

Re: Adding Kinetis boards

Hi

Today I made brief comparison between TWR-K40 and Kwikstik schematics.
There are some differences such as different XTAL frequency and
different UART routed to TWR-SER. This would imply different CDL which
would require a separate directory tree for Kwikstik. I dislike copying
too, but I think that, from essential files, only twr_k40n512_misc.c
(kwikstik_misc.c) may stay a "verbatim", eventually. For instance,
another important file plf_io.h contains pin assignments (UART, etc)
that have to be updated.

Ilija

On 15.12.2011 20:55, Tomas Frydrych wrote:
> Hi Ilija,
>
> On 15/12/11 18:04, Ilija Kocho wrote:
>> It may be just enough to add a new target entry in ecos.db.
>> I am not familiar with Kwikstik I only know that it is based on same
>> chip as TWR-K40. Can you please point the differences between boards
>> with respect to: HAL, devices, etc.
> I think HAL-wise the Kwikstik board is the same as the twr-40x256, it
> just exposes different features of the MCU through the attached devices,
> which include a microphone, a buzzer, an audio output, rechargeable
> battery (with usb charging), a dot-matrix LCD.
>
> The Kwistik is attractive because of its low cost (~$30), and even comes
> with an on board Segger J-Link chip! Seems like an affordable base for
> all kinds of hobby projects.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tomas Frydrych | 19 Dec 2011 22:33

Re: Adding Kinetis boards


On 16/12/11 08:38, Ilija Kocho wrote:
> Today I made brief comparison between TWR-K40 and Kwikstik schematics.
> There are some differences such as different XTAL frequency and
> different UART routed to TWR-SER.

Thanks Ilija, I missed that on my initial comparison, but it seems those
are the only differences as far as current features of the kinetis port
are concerned -- I had a bit of time to poke at it today and got both
redboot and kernel+sram start up working (once I realized that the
kwikstik does not supply 3.3V into the Tower elevators, so it is
necessary to power the serial module from the elevator supply).

I'll prepare patches and put them into bugzilla in the next couple of
days, time permitting.

Tomas

> This would imply different CDL which
> would require a separate directory tree for Kwikstik. I dislike copying
> too, but I think that, from essential files, only twr_k40n512_misc.c
> (kwikstik_misc.c) may stay a "verbatim", eventually. For instance,
> another important file plf_io.h contains pin assignments (UART, etc)
> that have to be updated.
> 
> Ilija
> 
> 
> On 15.12.2011 20:55, Tomas Frydrych wrote:
>> Hi Ilija,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane