iMXRT1064 IP addr assign to 2 ETH interfaces

2021-04-15 Thread Вадим Ястребов

Hello,
I have iMXRT1064 board with 2 Ethernet interfaces and I am seeing that one Eth 
interface does not have an ip addr assigned to it (not using dhcp). How can a 
target/router/mask addresses be assigned to the second interface?
 
I have managed to make both PHYs initialize. Although, only the first (eth0) 
works and gets the ip address assigned. It makes sense because the settings for 
eth1 interface aren’t even specified anywhere.
 
Please, let me know.
 
Regards,
Vadim Yastrebov
 

Re: DALI Interface Proposal

2021-04-15 Thread murat tologlu
Hi Alan,
I am glad to hear that you found my proposal as a nice feature for Nuttx to 
have. I see you have made a good intruction; let me add something: Yes, DALI 
interface standard has DALI and DALI2 versions. DALI2 version was also extended 
with a feature set named as D4i. Therefore we have to cover all. Pysical layer 
is very simple, we can use any of ST STEVAL-ILM001V1 and Mikroe DALI 2 Click, 
or we can make our own hardware  interface for our tests, no problem. 
Manchester encoding is also very simple, as the and since the clodck frequency 
is very low we can implement it by software with register operations without 
using any special counter therefore we can easily obtain portability of our 
code. 
In this work what I can do is, I can get all the information required such as 
IEC62386 standard and others, I can order all the required hardware, I can 
setup the hardware and I can do necessary tests. I can also participate 
implementing these in Nuttx codebase as much as I can with your help. So, let's 
get started, cd nuttxspace/nuttx make distclean :) 

On 2021/04/14 14:11:09, Alan Carvalho de Assis  wrote: 
> Hi Murat,
> 
> I think DALI support should be a nice feature to have!
> 
> Well, I already search for this protocol some time ago, but I don't
> know much about it yet.
> 
> The protocol uses Manchester encoding, maybe driver interface should
> be implemented using GPIO and freerunning timer. Suggestions are
> welcome!
> 
> For HW I think we have two options: ST STEVAL-ILM001V1 and Mikroe DALI 2 
> Click.
> 
> It seams there are two protocol version: DALI and DALI 2. Probably
> those DALI dimmers on Aliexpress are pretty old DALI protocol.
> 
> BR,
> 
> Alan
> 
> On 4/14/21, murat toloğlu  wrote:
> > I would very much like the DALI interface to be in Nuttx and I would like to
> > learn your opinions on this issue. My knowledge and experience in Nuttx is
> > not enough to do this work alone, but if we get a few people together, I can
> > participate in the development work.
> >
> 


Re: DALI Interface Proposal

2021-04-15 Thread Gregory Nutt
Before you start writing code, I think you should talk with the group 
about the architecture that you would develop.


One of the essential, unbend-able rules is that any new development must 
not add new operating system interfaces that are not standard, not 
documented at OpenGroup.org, or are not supported by Linux.  New logic 
can use, for examples, standard character driver interfaces, a BSD 
socket interface, or the file system, but no made up interfaces and no 
direct calls into non-standard OS functions.


I don't know much about DALI other than having scanned some websites.  
My recommendation is that you consider this as a user-space library like 
apps/modbus, perhaps at apps/dali.  The actual, low-level hardware 
interface could be implemented, say, via a character driver known to the 
apps/dali logic.  The user, application interface could then be purely 
of you choosing and exported via a header file at apps/include/dali/dali.h


The dali drivers would go at nuttx/drivers/dali (probably) and the 
interface (IOCTL commands and internal OS setup interfaces) might go in 
nuttx/include/nuttx/drivers/dali.h.


Does that make sense?  In any case, let's get concurrence on the 
interfaces before starting code development.  That will save a lot of 
problems down the road and will probably also engage more people, get a 
good review of the design, and might recruit people help you with the job.


Greg

On 4/15/2021 9:43 AM, murat tologlu wrote:

Hi Alan,
I am glad to hear that you found my proposal as a nice feature for Nuttx to 
have. I see you have made a good intruction; let me add something: Yes, DALI 
interface standard has DALI and DALI2 versions. DALI2 version was also extended 
with a feature set named as D4i. Therefore we have to cover all. Pysical layer 
is very simple, we can use any of ST STEVAL-ILM001V1 and Mikroe DALI 2 Click, 
or we can make our own hardware  interface for our tests, no problem. 
Manchester encoding is also very simple, as the and since the clodck frequency 
is very low we can implement it by software with register operations without 
using any special counter therefore we can easily obtain portability of our 
code.
In this work what I can do is, I can get all the information required such as 
IEC62386 standard and others, I can order all the required hardware, I can 
setup the hardware and I can do necessary tests. I can also participate 
implementing these in Nuttx codebase as much as I can with your help. So, let's 
get started, cd nuttxspace/nuttx make distclean :)

On 2021/04/14 14:11:09, Alan Carvalho de Assis  wrote:

Hi Murat,

I think DALI support should be a nice feature to have!

Well, I already search for this protocol some time ago, but I don't
know much about it yet.

The protocol uses Manchester encoding, maybe driver interface should
be implemented using GPIO and freerunning timer. Suggestions are
welcome!

For HW I think we have two options: ST STEVAL-ILM001V1 and Mikroe DALI 2 Click.

It seams there are two protocol version: DALI and DALI 2. Probably
those DALI dimmers on Aliexpress are pretty old DALI protocol.

BR,

Alan

On 4/14/21, murat toloğlu  wrote:

I would very much like the DALI interface to be in Nuttx and I would like to
learn your opinions on this issue. My knowledge and experience in Nuttx is
not enough to do this work alone, but if we get a few people together, I can
participate in the development work.