You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by murat tolo��lu <mt...@hotmail.com> on 2021/04/14 05:24:03 UTC
DALI Interface Proposal
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
Posted by murat tologlu <mt...@hotmail.com>.
I don't know the license issues well. I need to learn better.
On 2021/09/07 12:04:54, Alan Carvalho de Assis <ac...@gmail.com> wrote:
> Hi Murat,
>
> Unfortunately I cannot look this PR, the RIOT use LGPL/GPL code.
>
> BR,
>
> Alan
>
> On 9/7/21, murat tologlu <mt...@hotmail.com> wrote:
> > Hi Alan,
> >
> > The surprise is here : https://github.com/RIOT-OS/RIOT/pull/16766
> >
> > I asked same "Dali Question" in a foreign forum (
> > https://github.com/RIOT-OS/RIOT/pull/16766 ) before I went to vacation,
> > luckily one of maintainers had some previous work about Dali Interface and
> > he added this Pull Request in short time.
> >
> > It works quite satisfactory and became a base for my future works, I started
> > experimenting. Keep in touch.
> >
> > BR,
> > Murat
> >
> > On 2021/09/06 14:42:55, Alan Carvalho de Assis <ac...@gmail.com> wrote:
> >> I think your holidays were really good for you! :-)
> >>
> >> How did you implement it? Did you create a driver or it is just an apps
> >> library?
> >>
> >> BR,
> >>
> >> Alan
> >>
> >> On 9/6/21, Murat Tologlu <mt...@hotmail.com> wrote:
> >> > SURPRISE !
> >> >
> >> >
> >> >
> >> > Dali master worked quite fine on both esp32-wrover-kit and
> >> > stm32f429i-disc1
> >> >
> >> >
> >> >
> >> > Guess, what is the real surprise ! 😊
> >> >
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: Alan Carvalho de Assis <ac...@gmail.com>
> >> > Sent: Wednesday, April 14, 2021 5:11 PM
> >> > To: dev@nuttx.apache.org
> >> > Subject: Re: DALI Interface Proposal
> >> >
> >> >
> >> >
> >> > 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
> >> > <mt...@hotmail.com>> 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
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Murat,
Unfortunately I cannot look this PR, the RIOT use LGPL/GPL code.
BR,
Alan
On 9/7/21, murat tologlu <mt...@hotmail.com> wrote:
> Hi Alan,
>
> The surprise is here : https://github.com/RIOT-OS/RIOT/pull/16766
>
> I asked same "Dali Question" in a foreign forum (
> https://github.com/RIOT-OS/RIOT/pull/16766 ) before I went to vacation,
> luckily one of maintainers had some previous work about Dali Interface and
> he added this Pull Request in short time.
>
> It works quite satisfactory and became a base for my future works, I started
> experimenting. Keep in touch.
>
> BR,
> Murat
>
> On 2021/09/06 14:42:55, Alan Carvalho de Assis <ac...@gmail.com> wrote:
>> I think your holidays were really good for you! :-)
>>
>> How did you implement it? Did you create a driver or it is just an apps
>> library?
>>
>> BR,
>>
>> Alan
>>
>> On 9/6/21, Murat Tologlu <mt...@hotmail.com> wrote:
>> > SURPRISE !
>> >
>> >
>> >
>> > Dali master worked quite fine on both esp32-wrover-kit and
>> > stm32f429i-disc1
>> >
>> >
>> >
>> > Guess, what is the real surprise ! 😊
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Alan Carvalho de Assis <ac...@gmail.com>
>> > Sent: Wednesday, April 14, 2021 5:11 PM
>> > To: dev@nuttx.apache.org
>> > Subject: Re: DALI Interface Proposal
>> >
>> >
>> >
>> > 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
>> > <mt...@hotmail.com>> 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
Posted by murat tologlu <mt...@hotmail.com>.
Hi Alan,
The surprise is here : https://github.com/RIOT-OS/RIOT/pull/16766
I asked same "Dali Question" in a foreign forum ( https://github.com/RIOT-OS/RIOT/pull/16766 ) before I went to vacation, luckily one of maintainers had some previous work about Dali Interface and he added this Pull Request in short time.
It works quite satisfactory and became a base for my future works, I started experimenting. Keep in touch.
BR,
Murat
On 2021/09/06 14:42:55, Alan Carvalho de Assis <ac...@gmail.com> wrote:
> I think your holidays were really good for you! :-)
>
> How did you implement it? Did you create a driver or it is just an apps library?
>
> BR,
>
> Alan
>
> On 9/6/21, Murat Tologlu <mt...@hotmail.com> wrote:
> > SURPRISE !
> >
> >
> >
> > Dali master worked quite fine on both esp32-wrover-kit and stm32f429i-disc1
> >
> >
> >
> > Guess, what is the real surprise ! 😊
> >
> >
> >
> > -----Original Message-----
> > From: Alan Carvalho de Assis <ac...@gmail.com>
> > Sent: Wednesday, April 14, 2021 5:11 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: DALI Interface Proposal
> >
> >
> >
> > 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
> > <mt...@hotmail.com>> 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
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
I think your holidays were really good for you! :-)
How did you implement it? Did you create a driver or it is just an apps library?
BR,
Alan
On 9/6/21, Murat Tologlu <mt...@hotmail.com> wrote:
> SURPRISE !
>
>
>
> Dali master worked quite fine on both esp32-wrover-kit and stm32f429i-disc1
>
>
>
> Guess, what is the real surprise ! 😊
>
>
>
> -----Original Message-----
> From: Alan Carvalho de Assis <ac...@gmail.com>
> Sent: Wednesday, April 14, 2021 5:11 PM
> To: dev@nuttx.apache.org
> Subject: Re: DALI Interface Proposal
>
>
>
> 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
> <mt...@hotmail.com>> 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
Posted by Murat Tologlu <mt...@hotmail.com>.
SURPRISE !
Dali master worked quite fine on both esp32-wrover-kit and stm32f429i-disc1
Guess, what is the real surprise ! 😊
-----Original Message-----
From: Alan Carvalho de Assis <ac...@gmail.com>
Sent: Wednesday, April 14, 2021 5:11 PM
To: dev@nuttx.apache.org
Subject: Re: DALI Interface Proposal
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 <mt...@hotmail.com>> 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
Posted by murat tologlu <mt...@hotmail.com>.
Hi,
This is another good document for our DALI project : https://www.nxp.com/files-static/microcontrollers/doc/ref_manual/DRM004.pdf
On 2021/04/22 17:49:08, murat tologlu <mt...@hotmail.com> wrote:
> I forgot to say: Machester encoder is just an exclusive or gate, manchester decoder is also an exclusive or gate ! If you ex-or the clock and the data then you get the manchester encoded code. At the receiver side, if you start and synchronize a same frequency free running clock with the negative going "start bit" and ex-or the incoming frame with this clock then you decode the code and obtain the same data. This is the same technique how I designed and made Turkey's first military digital voice scrambler unit 40 years ago :)
>
> On 2021/04/22 17:17:09, murat tologlu <mt...@hotmail.com> wrote:
> > This topic is your expertise !
> >
> > On 2021/04/22 16:49:30, Gregory Nutt <sp...@gmail.com> wrote:
> > >
> > > > Both the Microchip solution and the example I've mentioned above uses the UART to communicate with DALI Interface. I think we can consider the same.
> > > >
> > > A better design would be independent of the physical transport layer .
> > >
> >
>
Re: DALI Interface Proposal
Posted by murat tologlu <mt...@hotmail.com>.
I forgot to say: Machester encoder is just an exclusive or gate, manchester decoder is also an exclusive or gate ! If you ex-or the clock and the data then you get the manchester encoded code. At the receiver side, if you start and synchronize a same frequency free running clock with the negative going "start bit" and ex-or the incoming frame with this clock then you decode the code and obtain the same data. This is the same technique how I designed and made Turkey's first military digital voice scrambler unit 40 years ago :)
On 2021/04/22 17:17:09, murat tologlu <mt...@hotmail.com> wrote:
> This topic is your expertise !
>
> On 2021/04/22 16:49:30, Gregory Nutt <sp...@gmail.com> wrote:
> >
> > > Both the Microchip solution and the example I've mentioned above uses the UART to communicate with DALI Interface. I think we can consider the same.
> > >
> > A better design would be independent of the physical transport layer .
> >
>
Re: DALI Interface Proposal
Posted by murat tologlu <mt...@hotmail.com>.
This topic is your expertise !
On 2021/04/22 16:49:30, Gregory Nutt <sp...@gmail.com> wrote:
>
> > Both the Microchip solution and the example I've mentioned above uses the UART to communicate with DALI Interface. I think we can consider the same.
> >
> A better design would be independent of the physical transport layer .
>
Re: DALI Interface Proposal
Posted by Gregory Nutt <sp...@gmail.com>.
> Both the Microchip solution and the example I've mentioned above uses the UART to communicate with DALI Interface. I think we can consider the same.
>
A better design would be independent of the physical transport layer .
Re: DALI Interface Proposal
Posted by murat tologlu <mt...@hotmail.com>.
Both the Microchip solution and the example I've mentioned above uses the UART to communicate with DALI Interface. I think we can consider the same.
On 2021/04/22 15:56:51, murat tologlu <mt...@hotmail.com> wrote:
> One of the best brief explanation of the Dali protocol is in Microchip TB3200 Technical Brief (https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en606182), also, DALI introduction on page 8 of this ( https://download.beckhoff.com/download/document/automation/twincat3/TwinCAT_3_PLC_Lib_Tc2_DALI_EN.pdf ) explains the IEC 62386 standard and DALI messaging very good.
>
> On 2021/04/21 09:52:23, murat tologlu <mt...@hotmail.com> wrote:
> > Wow! I am very glad to see that you are so involved in this subject. I have to be worthy of your attention.
> >
> > Firstly, let me explain what I am thinking about Hasseb USB-Dali Master device. You can consider it in place of the USB-RS485 Converter in Nuttx Modbus tutorial ( http://ta1db.5g.com.tr/nuttx-modbus-setup.jpg ). For me it is just a development tool which can be used for development and test purposes. Indeed, it has a proprietary interface which is made with a LPC1343 but our aim is not to make a usb-dali converter. On the other hand if we look at it's schematic diagram (can be downloaded here http://hasseb.fi/dali/dali2.zip ) we see another example of a dali interface and a dali power supply. Yes, it would be very good if we could find a cheaper similar device, without tax it is 76,61 € for bank transfer payments, offers free shipment, €15 for priority mail.
> >
> > Arduino Dali Shield ( https://www.ebay.it/itm/254211672779 ) can be considered as an alternative, however it is not the same thing, we have to setup another embedded environment with an Arduino or something, while all of us have a pc in front of us. Furthermore it's price is €34,50, together with €39 for international shipment the price comes to € 73,5 which is similar to cost of the Hasseb, furthermore it still requires a 24V power supply ( Hasseb includes the psu ). I am not making marketing 😊 just comparing. Infineon development tools are too complex and expensive also.
> >
> > Dali power supply is just an LM317 with a 250 mA current limiter. Dali interface is just two opto-couplers together with a few components. For those who want to buy a ready made Dali interface I think the best choice is Mikroe Dali 2 Click ( https://www.mikroe.com/dali-2-click ) however I may consider to make it on a breadboard instead of dealing with international ordering details because it is a very simple circuit.
> >
> > Regarding LED-Warrior14 chip and the modules made with it, yes, it is interesting, it frees us dealing with Manchester encoding - decoding process etc., it is easier to send and receive Dali commands through I2C interface. If I would be alone and doing experiments by myself then I would consider using this part. However, I think this shouldn't be a solution that we offer to the Nuttx community here. As Alan said Manchester encoding can be implemented using GPIO and free-running timer. Afterwards nobody needs to buy and use a special chip anymore.
> >
> > This is a good example for us: https://www.mdpi.com/2079-9292/8/9/1021/htm
> >
> >
> > On 2021/04/19 20:06:32, Gregory Nutt <sp...@gmail.com> wrote:
> > > The Infineon Dali Arduino board used a similar Infineon XC836 part that
> > > has a UART interface.
> > >
> > > Greg
> > >
> > > On 4/19/2021 1:35 PM, Alan Carvalho de Assis wrote:
> > > > Hi Greg,
> > > >
> > > > This LW14 is interesting! It is possible to buy a module with it to
> > > > use the I2C interface with any board (don't need to be an Arduino
> > > > form-factor) see:
> > > >
> > > > http://www.saelig.com/product/lw14-02mod.htm
> > > >
> > > > I think the shipping cost will be higher the the product.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On 4/19/21, Gregory Nutt <sp...@gmail.com> wrote:
> > > >> Hi, Murat,
> > > >>
> > > >> At 95 euros that could be a turn off for some hobbyist. I looked around
> > > >> for a low cost solution and found two pretty common solutions.
> > > >>
> > > >> 1. Aruino Dali Shield. There are shields like the daliMaster
> > > >> https://github.com/davideloba/daliMaster that are reasonably priced.
> > > >> These have an I2C interface and bridge to the Dali bus via
> > > >> https://www.codemercs.com/downloads/ledwarrior/LW14_Datasheet.pdf
> > > >>
> > > >> 2. The Mikroe Dali 2 Click is also a good deal:
> > > >> https://www.mikroe.com/dali-2-click . This uses a GPIO interface
> > > >> directly to the Dali bus so must be a big-bang interface:
> > > >> https://download.mikroe.com/documents/add-on-boards/click/dali-2/dali-2-click-schematic-v100.pdf
> > > >>
> > > >> . But Mikroe does have a library for the Click board so that should not
> > > >> be too bad.
> > > >>
> > > >> One thing this says to me is that there needs to be a clear separation
> > > >> between the application which should be communicating in in high level
> > > >> commands (telegrams). I am thinking:
> > > >>
> > > >> - There could be I2C and bit-bang drivers in drivers/dali that would be
> > > >> capable of sending/receiving one telegram of all supported lengths.
> > > >> This would export a common driver interface (IOCTLs and read/write
> > > >> behaviors).
> > > >>
> > > >> - A higher level, Dali interace in apps/dali that understands command
> > > >> semantics and protocols. This should work with any lower level
> > > >> implementation.
> > > >>
> > > >> I am thinking about buying the Arduino board. I imagine that the I2C
> > > >> interface is easier to use and the LW14 is well documented. Do you have
> > > >> any insight into that part?
> > > >>
> > > >> Greg
> > > >>
> > > >>
> > > >> On 4/19/2021 2:47 AM, murat tologlu wrote:
> > > >>> Hi Greg,
> > > >>>
> > > >>> I am going to order this (
> > > >>> http://www.hasseb.fi/shop2/index.php?route=product/product&product_id=50 )
> > > >>> USB Dali-2 Master unit to start playing and getting familiar with DALI
> > > >>> commands. With this unit I will be able to test our own slave hardware -
> > > >>> software as well. I will share my experiments of course. Unfortunately
> > > >>> this is not my main occupation, I am doing in my spare time, therefore may
> > > >>> go slow.
> > > >>>
> > > >>> Best regards,
> > > >>> Murat
> > > >>>
> > > >>> On 2021/04/17 19:18:17, Gregory Nutt <sp...@gmail.com> wrote:
> > > >>>> Hi, Murat,
> > > >>>>
> > > >>>> When you decide on your development/test hardware, let us know. Maybe
> > > >>>> someone will get inspired to duplicate your setup and help at least with
> > > >>>> some testing.
> > > >>>>
> > > >>>> Greg
> > > >>>>
> > > >>>> On 4/17/2021 3:23 AM, murat tologlu wrote:
> > > >>>>> Dear Greg,
> > > >>>>>
> > > >>>>> Thank you very much for your kind response, valuable warnings and
> > > >>>>> suggestions. I see a very good road-map in your answer. On the other
> > > >>>>> hand I ( probably together with Alan and somebody else interested in
> > > >>>>> participating us) will appreciate all other comments and suggestions.
> > > >>>>>
> > > >>>>> Best regards,
> > > >>>>> Murat
> > > >>>>>
> > > >>>>> On 2021/04/15 20:40:32, Gregory Nutt <sp...@gmail.com> wrote:
> > > >>>>>> 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 <ac...@gmail.com>
> > > >>>>>>> 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 <mt...@hotmail.com> 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
Posted by murat tologlu <mt...@hotmail.com>.
One of the best brief explanation of the Dali protocol is in Microchip TB3200 Technical Brief (https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en606182), also, DALI introduction on page 8 of this ( https://download.beckhoff.com/download/document/automation/twincat3/TwinCAT_3_PLC_Lib_Tc2_DALI_EN.pdf ) explains the IEC 62386 standard and DALI messaging very good.
On 2021/04/21 09:52:23, murat tologlu <mt...@hotmail.com> wrote:
> Wow! I am very glad to see that you are so involved in this subject. I have to be worthy of your attention.
>
> Firstly, let me explain what I am thinking about Hasseb USB-Dali Master device. You can consider it in place of the USB-RS485 Converter in Nuttx Modbus tutorial ( http://ta1db.5g.com.tr/nuttx-modbus-setup.jpg ). For me it is just a development tool which can be used for development and test purposes. Indeed, it has a proprietary interface which is made with a LPC1343 but our aim is not to make a usb-dali converter. On the other hand if we look at it's schematic diagram (can be downloaded here http://hasseb.fi/dali/dali2.zip ) we see another example of a dali interface and a dali power supply. Yes, it would be very good if we could find a cheaper similar device, without tax it is 76,61 € for bank transfer payments, offers free shipment, €15 for priority mail.
>
> Arduino Dali Shield ( https://www.ebay.it/itm/254211672779 ) can be considered as an alternative, however it is not the same thing, we have to setup another embedded environment with an Arduino or something, while all of us have a pc in front of us. Furthermore it's price is €34,50, together with €39 for international shipment the price comes to € 73,5 which is similar to cost of the Hasseb, furthermore it still requires a 24V power supply ( Hasseb includes the psu ). I am not making marketing 😊 just comparing. Infineon development tools are too complex and expensive also.
>
> Dali power supply is just an LM317 with a 250 mA current limiter. Dali interface is just two opto-couplers together with a few components. For those who want to buy a ready made Dali interface I think the best choice is Mikroe Dali 2 Click ( https://www.mikroe.com/dali-2-click ) however I may consider to make it on a breadboard instead of dealing with international ordering details because it is a very simple circuit.
>
> Regarding LED-Warrior14 chip and the modules made with it, yes, it is interesting, it frees us dealing with Manchester encoding - decoding process etc., it is easier to send and receive Dali commands through I2C interface. If I would be alone and doing experiments by myself then I would consider using this part. However, I think this shouldn't be a solution that we offer to the Nuttx community here. As Alan said Manchester encoding can be implemented using GPIO and free-running timer. Afterwards nobody needs to buy and use a special chip anymore.
>
> This is a good example for us: https://www.mdpi.com/2079-9292/8/9/1021/htm
>
>
> On 2021/04/19 20:06:32, Gregory Nutt <sp...@gmail.com> wrote:
> > The Infineon Dali Arduino board used a similar Infineon XC836 part that
> > has a UART interface.
> >
> > Greg
> >
> > On 4/19/2021 1:35 PM, Alan Carvalho de Assis wrote:
> > > Hi Greg,
> > >
> > > This LW14 is interesting! It is possible to buy a module with it to
> > > use the I2C interface with any board (don't need to be an Arduino
> > > form-factor) see:
> > >
> > > http://www.saelig.com/product/lw14-02mod.htm
> > >
> > > I think the shipping cost will be higher the the product.
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On 4/19/21, Gregory Nutt <sp...@gmail.com> wrote:
> > >> Hi, Murat,
> > >>
> > >> At 95 euros that could be a turn off for some hobbyist. I looked around
> > >> for a low cost solution and found two pretty common solutions.
> > >>
> > >> 1. Aruino Dali Shield. There are shields like the daliMaster
> > >> https://github.com/davideloba/daliMaster that are reasonably priced.
> > >> These have an I2C interface and bridge to the Dali bus via
> > >> https://www.codemercs.com/downloads/ledwarrior/LW14_Datasheet.pdf
> > >>
> > >> 2. The Mikroe Dali 2 Click is also a good deal:
> > >> https://www.mikroe.com/dali-2-click . This uses a GPIO interface
> > >> directly to the Dali bus so must be a big-bang interface:
> > >> https://download.mikroe.com/documents/add-on-boards/click/dali-2/dali-2-click-schematic-v100.pdf
> > >>
> > >> . But Mikroe does have a library for the Click board so that should not
> > >> be too bad.
> > >>
> > >> One thing this says to me is that there needs to be a clear separation
> > >> between the application which should be communicating in in high level
> > >> commands (telegrams). I am thinking:
> > >>
> > >> - There could be I2C and bit-bang drivers in drivers/dali that would be
> > >> capable of sending/receiving one telegram of all supported lengths.
> > >> This would export a common driver interface (IOCTLs and read/write
> > >> behaviors).
> > >>
> > >> - A higher level, Dali interace in apps/dali that understands command
> > >> semantics and protocols. This should work with any lower level
> > >> implementation.
> > >>
> > >> I am thinking about buying the Arduino board. I imagine that the I2C
> > >> interface is easier to use and the LW14 is well documented. Do you have
> > >> any insight into that part?
> > >>
> > >> Greg
> > >>
> > >>
> > >> On 4/19/2021 2:47 AM, murat tologlu wrote:
> > >>> Hi Greg,
> > >>>
> > >>> I am going to order this (
> > >>> http://www.hasseb.fi/shop2/index.php?route=product/product&product_id=50 )
> > >>> USB Dali-2 Master unit to start playing and getting familiar with DALI
> > >>> commands. With this unit I will be able to test our own slave hardware -
> > >>> software as well. I will share my experiments of course. Unfortunately
> > >>> this is not my main occupation, I am doing in my spare time, therefore may
> > >>> go slow.
> > >>>
> > >>> Best regards,
> > >>> Murat
> > >>>
> > >>> On 2021/04/17 19:18:17, Gregory Nutt <sp...@gmail.com> wrote:
> > >>>> Hi, Murat,
> > >>>>
> > >>>> When you decide on your development/test hardware, let us know. Maybe
> > >>>> someone will get inspired to duplicate your setup and help at least with
> > >>>> some testing.
> > >>>>
> > >>>> Greg
> > >>>>
> > >>>> On 4/17/2021 3:23 AM, murat tologlu wrote:
> > >>>>> Dear Greg,
> > >>>>>
> > >>>>> Thank you very much for your kind response, valuable warnings and
> > >>>>> suggestions. I see a very good road-map in your answer. On the other
> > >>>>> hand I ( probably together with Alan and somebody else interested in
> > >>>>> participating us) will appreciate all other comments and suggestions.
> > >>>>>
> > >>>>> Best regards,
> > >>>>> Murat
> > >>>>>
> > >>>>> On 2021/04/15 20:40:32, Gregory Nutt <sp...@gmail.com> wrote:
> > >>>>>> 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 <ac...@gmail.com>
> > >>>>>>> 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 <mt...@hotmail.com> 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
Posted by murat tologlu <mt...@hotmail.com>.
Wow! I am very glad to see that you are so involved in this subject. I have to be worthy of your attention.
Firstly, let me explain what I am thinking about Hasseb USB-Dali Master device. You can consider it in place of the USB-RS485 Converter in Nuttx Modbus tutorial ( http://ta1db.5g.com.tr/nuttx-modbus-setup.jpg ). For me it is just a development tool which can be used for development and test purposes. Indeed, it has a proprietary interface which is made with a LPC1343 but our aim is not to make a usb-dali converter. On the other hand if we look at it's schematic diagram (can be downloaded here http://hasseb.fi/dali/dali2.zip ) we see another example of a dali interface and a dali power supply. Yes, it would be very good if we could find a cheaper similar device, without tax it is 76,61 € for bank transfer payments, offers free shipment, €15 for priority mail.
Arduino Dali Shield ( https://www.ebay.it/itm/254211672779 ) can be considered as an alternative, however it is not the same thing, we have to setup another embedded environment with an Arduino or something, while all of us have a pc in front of us. Furthermore it's price is €34,50, together with €39 for international shipment the price comes to € 73,5 which is similar to cost of the Hasseb, furthermore it still requires a 24V power supply ( Hasseb includes the psu ). I am not making marketing 😊 just comparing. Infineon development tools are too complex and expensive also.
Dali power supply is just an LM317 with a 250 mA current limiter. Dali interface is just two opto-couplers together with a few components. For those who want to buy a ready made Dali interface I think the best choice is Mikroe Dali 2 Click ( https://www.mikroe.com/dali-2-click ) however I may consider to make it on a breadboard instead of dealing with international ordering details because it is a very simple circuit.
Regarding LED-Warrior14 chip and the modules made with it, yes, it is interesting, it frees us dealing with Manchester encoding - decoding process etc., it is easier to send and receive Dali commands through I2C interface. If I would be alone and doing experiments by myself then I would consider using this part. However, I think this shouldn't be a solution that we offer to the Nuttx community here. As Alan said Manchester encoding can be implemented using GPIO and free-running timer. Afterwards nobody needs to buy and use a special chip anymore.
This is a good example for us: https://www.mdpi.com/2079-9292/8/9/1021/htm
On 2021/04/19 20:06:32, Gregory Nutt <sp...@gmail.com> wrote:
> The Infineon Dali Arduino board used a similar Infineon XC836 part that
> has a UART interface.
>
> Greg
>
> On 4/19/2021 1:35 PM, Alan Carvalho de Assis wrote:
> > Hi Greg,
> >
> > This LW14 is interesting! It is possible to buy a module with it to
> > use the I2C interface with any board (don't need to be an Arduino
> > form-factor) see:
> >
> > http://www.saelig.com/product/lw14-02mod.htm
> >
> > I think the shipping cost will be higher the the product.
> >
> > BR,
> >
> > Alan
> >
> > On 4/19/21, Gregory Nutt <sp...@gmail.com> wrote:
> >> Hi, Murat,
> >>
> >> At 95 euros that could be a turn off for some hobbyist. I looked around
> >> for a low cost solution and found two pretty common solutions.
> >>
> >> 1. Aruino Dali Shield. There are shields like the daliMaster
> >> https://github.com/davideloba/daliMaster that are reasonably priced.
> >> These have an I2C interface and bridge to the Dali bus via
> >> https://www.codemercs.com/downloads/ledwarrior/LW14_Datasheet.pdf
> >>
> >> 2. The Mikroe Dali 2 Click is also a good deal:
> >> https://www.mikroe.com/dali-2-click . This uses a GPIO interface
> >> directly to the Dali bus so must be a big-bang interface:
> >> https://download.mikroe.com/documents/add-on-boards/click/dali-2/dali-2-click-schematic-v100.pdf
> >>
> >> . But Mikroe does have a library for the Click board so that should not
> >> be too bad.
> >>
> >> One thing this says to me is that there needs to be a clear separation
> >> between the application which should be communicating in in high level
> >> commands (telegrams). I am thinking:
> >>
> >> - There could be I2C and bit-bang drivers in drivers/dali that would be
> >> capable of sending/receiving one telegram of all supported lengths.
> >> This would export a common driver interface (IOCTLs and read/write
> >> behaviors).
> >>
> >> - A higher level, Dali interace in apps/dali that understands command
> >> semantics and protocols. This should work with any lower level
> >> implementation.
> >>
> >> I am thinking about buying the Arduino board. I imagine that the I2C
> >> interface is easier to use and the LW14 is well documented. Do you have
> >> any insight into that part?
> >>
> >> Greg
> >>
> >>
> >> On 4/19/2021 2:47 AM, murat tologlu wrote:
> >>> Hi Greg,
> >>>
> >>> I am going to order this (
> >>> http://www.hasseb.fi/shop2/index.php?route=product/product&product_id=50 )
> >>> USB Dali-2 Master unit to start playing and getting familiar with DALI
> >>> commands. With this unit I will be able to test our own slave hardware -
> >>> software as well. I will share my experiments of course. Unfortunately
> >>> this is not my main occupation, I am doing in my spare time, therefore may
> >>> go slow.
> >>>
> >>> Best regards,
> >>> Murat
> >>>
> >>> On 2021/04/17 19:18:17, Gregory Nutt <sp...@gmail.com> wrote:
> >>>> Hi, Murat,
> >>>>
> >>>> When you decide on your development/test hardware, let us know. Maybe
> >>>> someone will get inspired to duplicate your setup and help at least with
> >>>> some testing.
> >>>>
> >>>> Greg
> >>>>
> >>>> On 4/17/2021 3:23 AM, murat tologlu wrote:
> >>>>> Dear Greg,
> >>>>>
> >>>>> Thank you very much for your kind response, valuable warnings and
> >>>>> suggestions. I see a very good road-map in your answer. On the other
> >>>>> hand I ( probably together with Alan and somebody else interested in
> >>>>> participating us) will appreciate all other comments and suggestions.
> >>>>>
> >>>>> Best regards,
> >>>>> Murat
> >>>>>
> >>>>> On 2021/04/15 20:40:32, Gregory Nutt <sp...@gmail.com> wrote:
> >>>>>> 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 <ac...@gmail.com>
> >>>>>>> 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 <mt...@hotmail.com> 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
Posted by Gregory Nutt <sp...@gmail.com>.
The Infineon Dali Arduino board used a similar Infineon XC836 part that
has a UART interface.
Greg
On 4/19/2021 1:35 PM, Alan Carvalho de Assis wrote:
> Hi Greg,
>
> This LW14 is interesting! It is possible to buy a module with it to
> use the I2C interface with any board (don't need to be an Arduino
> form-factor) see:
>
> http://www.saelig.com/product/lw14-02mod.htm
>
> I think the shipping cost will be higher the the product.
>
> BR,
>
> Alan
>
> On 4/19/21, Gregory Nutt <sp...@gmail.com> wrote:
>> Hi, Murat,
>>
>> At 95 euros that could be a turn off for some hobbyist. I looked around
>> for a low cost solution and found two pretty common solutions.
>>
>> 1. Aruino Dali Shield. There are shields like the daliMaster
>> https://github.com/davideloba/daliMaster that are reasonably priced.
>> These have an I2C interface and bridge to the Dali bus via
>> https://www.codemercs.com/downloads/ledwarrior/LW14_Datasheet.pdf
>>
>> 2. The Mikroe Dali 2 Click is also a good deal:
>> https://www.mikroe.com/dali-2-click . This uses a GPIO interface
>> directly to the Dali bus so must be a big-bang interface:
>> https://download.mikroe.com/documents/add-on-boards/click/dali-2/dali-2-click-schematic-v100.pdf
>>
>> . But Mikroe does have a library for the Click board so that should not
>> be too bad.
>>
>> One thing this says to me is that there needs to be a clear separation
>> between the application which should be communicating in in high level
>> commands (telegrams). I am thinking:
>>
>> - There could be I2C and bit-bang drivers in drivers/dali that would be
>> capable of sending/receiving one telegram of all supported lengths.
>> This would export a common driver interface (IOCTLs and read/write
>> behaviors).
>>
>> - A higher level, Dali interace in apps/dali that understands command
>> semantics and protocols. This should work with any lower level
>> implementation.
>>
>> I am thinking about buying the Arduino board. I imagine that the I2C
>> interface is easier to use and the LW14 is well documented. Do you have
>> any insight into that part?
>>
>> Greg
>>
>>
>> On 4/19/2021 2:47 AM, murat tologlu wrote:
>>> Hi Greg,
>>>
>>> I am going to order this (
>>> http://www.hasseb.fi/shop2/index.php?route=product/product&product_id=50 )
>>> USB Dali-2 Master unit to start playing and getting familiar with DALI
>>> commands. With this unit I will be able to test our own slave hardware -
>>> software as well. I will share my experiments of course. Unfortunately
>>> this is not my main occupation, I am doing in my spare time, therefore may
>>> go slow.
>>>
>>> Best regards,
>>> Murat
>>>
>>> On 2021/04/17 19:18:17, Gregory Nutt <sp...@gmail.com> wrote:
>>>> Hi, Murat,
>>>>
>>>> When you decide on your development/test hardware, let us know. Maybe
>>>> someone will get inspired to duplicate your setup and help at least with
>>>> some testing.
>>>>
>>>> Greg
>>>>
>>>> On 4/17/2021 3:23 AM, murat tologlu wrote:
>>>>> Dear Greg,
>>>>>
>>>>> Thank you very much for your kind response, valuable warnings and
>>>>> suggestions. I see a very good road-map in your answer. On the other
>>>>> hand I ( probably together with Alan and somebody else interested in
>>>>> participating us) will appreciate all other comments and suggestions.
>>>>>
>>>>> Best regards,
>>>>> Murat
>>>>>
>>>>> On 2021/04/15 20:40:32, Gregory Nutt <sp...@gmail.com> wrote:
>>>>>> 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 <ac...@gmail.com>
>>>>>>> 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 <mt...@hotmail.com> 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
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Greg,
This LW14 is interesting! It is possible to buy a module with it to
use the I2C interface with any board (don't need to be an Arduino
form-factor) see:
http://www.saelig.com/product/lw14-02mod.htm
I think the shipping cost will be higher the the product.
BR,
Alan
On 4/19/21, Gregory Nutt <sp...@gmail.com> wrote:
> Hi, Murat,
>
> At 95 euros that could be a turn off for some hobbyist. I looked around
> for a low cost solution and found two pretty common solutions.
>
> 1. Aruino Dali Shield. There are shields like the daliMaster
> https://github.com/davideloba/daliMaster that are reasonably priced.
> These have an I2C interface and bridge to the Dali bus via
> https://www.codemercs.com/downloads/ledwarrior/LW14_Datasheet.pdf
>
> 2. The Mikroe Dali 2 Click is also a good deal:
> https://www.mikroe.com/dali-2-click . This uses a GPIO interface
> directly to the Dali bus so must be a big-bang interface:
> https://download.mikroe.com/documents/add-on-boards/click/dali-2/dali-2-click-schematic-v100.pdf
>
> . But Mikroe does have a library for the Click board so that should not
> be too bad.
>
> One thing this says to me is that there needs to be a clear separation
> between the application which should be communicating in in high level
> commands (telegrams). I am thinking:
>
> - There could be I2C and bit-bang drivers in drivers/dali that would be
> capable of sending/receiving one telegram of all supported lengths.
> This would export a common driver interface (IOCTLs and read/write
> behaviors).
>
> - A higher level, Dali interace in apps/dali that understands command
> semantics and protocols. This should work with any lower level
> implementation.
>
> I am thinking about buying the Arduino board. I imagine that the I2C
> interface is easier to use and the LW14 is well documented. Do you have
> any insight into that part?
>
> Greg
>
>
> On 4/19/2021 2:47 AM, murat tologlu wrote:
>> Hi Greg,
>>
>> I am going to order this (
>> http://www.hasseb.fi/shop2/index.php?route=product/product&product_id=50 )
>> USB Dali-2 Master unit to start playing and getting familiar with DALI
>> commands. With this unit I will be able to test our own slave hardware -
>> software as well. I will share my experiments of course. Unfortunately
>> this is not my main occupation, I am doing in my spare time, therefore may
>> go slow.
>>
>> Best regards,
>> Murat
>>
>> On 2021/04/17 19:18:17, Gregory Nutt <sp...@gmail.com> wrote:
>>> Hi, Murat,
>>>
>>> When you decide on your development/test hardware, let us know. Maybe
>>> someone will get inspired to duplicate your setup and help at least with
>>> some testing.
>>>
>>> Greg
>>>
>>> On 4/17/2021 3:23 AM, murat tologlu wrote:
>>>> Dear Greg,
>>>>
>>>> Thank you very much for your kind response, valuable warnings and
>>>> suggestions. I see a very good road-map in your answer. On the other
>>>> hand I ( probably together with Alan and somebody else interested in
>>>> participating us) will appreciate all other comments and suggestions.
>>>>
>>>> Best regards,
>>>> Murat
>>>>
>>>> On 2021/04/15 20:40:32, Gregory Nutt <sp...@gmail.com> wrote:
>>>>> 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 <ac...@gmail.com>
>>>>>> 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 <mt...@hotmail.com> 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
Posted by Gregory Nutt <sp...@gmail.com>.
Mouser has only this Infineon board:
https://www.mouser.co.cr/datasheet/2/196/AP0810414_LightNet-1840577.pdf
. It is based on an Infineon bridge part that has a USB/UART connection
to the host.
The Hasseb USB Dali Master that you referenced
(http://www.hasseb.fi/shop2/index.php?route=product/product&product_id=50)
has a USB HID interface. That is probably a proprietary interface and
not an embedded friendly solution.
While the Dali bus may be well standardiazed, clearly there is no
standard host interface.
Greg
On 4/19/2021 12:56 PM, Gregory Nutt wrote:
> Hi, Murat,
>
> At 95 euros that could be a turn off for some hobbyist. I looked
> around for a low cost solution and found two pretty common solutions.
>
> 1. Aruino Dali Shield. There are shields like the daliMaster
> https://github.com/davideloba/daliMaster that are reasonably priced.
> These have an I2C interface and bridge to the Dali bus via
> https://www.codemercs.com/downloads/ledwarrior/LW14_Datasheet.pdf
>
> 2. The Mikroe Dali 2 Click is also a good deal:
> https://www.mikroe.com/dali-2-click . This uses a GPIO interface
> directly to the Dali bus so must be a big-bang interface:
> https://download.mikroe.com/documents/add-on-boards/click/dali-2/dali-2-click-schematic-v100.pdf
> . But Mikroe does have a library for the Click board so that should
> not be too bad.
>
> One thing this says to me is that there needs to be a clear separation
> between the application which should be communicating in in high level
> commands (telegrams). I am thinking:
>
> - There could be I2C and bit-bang drivers in drivers/dali that would
> be capable of sending/receiving one telegram of all supported
> lengths. This would export a common driver interface (IOCTLs and
> read/write behaviors).
>
> - A higher level, Dali interace in apps/dali that understands command
> semantics and protocols. This should work with any lower level
> implementation.
>
> I am thinking about buying the Arduino board. I imagine that the I2C
> interface is easier to use and the LW14 is well documented. Do you
> have any insight into that part?
>
> Greg
>
>
> On 4/19/2021 2:47 AM, murat tologlu wrote:
>> Hi Greg,
>>
>> I am going to order this (
>> http://www.hasseb.fi/shop2/index.php?route=product/product&product_id=50
>> ) USB Dali-2 Master unit to start playing and getting familiar with
>> DALI commands. With this unit I will be able to test our own slave
>> hardware - software as well. I will share my experiments of course.
>> Unfortunately this is not my main occupation, I am doing in my spare
>> time, therefore may go slow.
>>
>> Best regards,
>> Murat
>>
>> On 2021/04/17 19:18:17, Gregory Nutt <sp...@gmail.com> wrote:
>>> Hi, Murat,
>>>
>>> When you decide on your development/test hardware, let us know. Maybe
>>> someone will get inspired to duplicate your setup and help at least
>>> with
>>> some testing.
>>>
>>> Greg
>>>
>>> On 4/17/2021 3:23 AM, murat tologlu wrote:
>>>> Dear Greg,
>>>>
>>>> Thank you very much for your kind response, valuable warnings and
>>>> suggestions. I see a very good road-map in your answer. On the
>>>> other hand I ( probably together with Alan and somebody else
>>>> interested in participating us) will appreciate all other comments
>>>> and suggestions.
>>>>
>>>> Best regards,
>>>> Murat
>>>>
>>>> On 2021/04/15 20:40:32, Gregory Nutt <sp...@gmail.com> wrote:
>>>>> 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
>>>>>> <ac...@gmail.com> 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 <mt...@hotmail.com> 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
Posted by Gregory Nutt <sp...@gmail.com>.
Hi, Murat,
At 95 euros that could be a turn off for some hobbyist. I looked around
for a low cost solution and found two pretty common solutions.
1. Aruino Dali Shield. There are shields like the daliMaster
https://github.com/davideloba/daliMaster that are reasonably priced.
These have an I2C interface and bridge to the Dali bus via
https://www.codemercs.com/downloads/ledwarrior/LW14_Datasheet.pdf
2. The Mikroe Dali 2 Click is also a good deal:
https://www.mikroe.com/dali-2-click . This uses a GPIO interface
directly to the Dali bus so must be a big-bang interface:
https://download.mikroe.com/documents/add-on-boards/click/dali-2/dali-2-click-schematic-v100.pdf
. But Mikroe does have a library for the Click board so that should not
be too bad.
One thing this says to me is that there needs to be a clear separation
between the application which should be communicating in in high level
commands (telegrams). I am thinking:
- There could be I2C and bit-bang drivers in drivers/dali that would be
capable of sending/receiving one telegram of all supported lengths.
This would export a common driver interface (IOCTLs and read/write
behaviors).
- A higher level, Dali interace in apps/dali that understands command
semantics and protocols. This should work with any lower level
implementation.
I am thinking about buying the Arduino board. I imagine that the I2C
interface is easier to use and the LW14 is well documented. Do you have
any insight into that part?
Greg
On 4/19/2021 2:47 AM, murat tologlu wrote:
> Hi Greg,
>
> I am going to order this ( http://www.hasseb.fi/shop2/index.php?route=product/product&product_id=50 ) USB Dali-2 Master unit to start playing and getting familiar with DALI commands. With this unit I will be able to test our own slave hardware - software as well. I will share my experiments of course. Unfortunately this is not my main occupation, I am doing in my spare time, therefore may go slow.
>
> Best regards,
> Murat
>
> On 2021/04/17 19:18:17, Gregory Nutt <sp...@gmail.com> wrote:
>> Hi, Murat,
>>
>> When you decide on your development/test hardware, let us know. Maybe
>> someone will get inspired to duplicate your setup and help at least with
>> some testing.
>>
>> Greg
>>
>> On 4/17/2021 3:23 AM, murat tologlu wrote:
>>> Dear Greg,
>>>
>>> Thank you very much for your kind response, valuable warnings and suggestions. I see a very good road-map in your answer. On the other hand I ( probably together with Alan and somebody else interested in participating us) will appreciate all other comments and suggestions.
>>>
>>> Best regards,
>>> Murat
>>>
>>> On 2021/04/15 20:40:32, Gregory Nutt <sp...@gmail.com> wrote:
>>>> 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 <ac...@gmail.com> 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 <mt...@hotmail.com> 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
Posted by murat tologlu <mt...@hotmail.com>.
Hi Greg,
I am going to order this ( http://www.hasseb.fi/shop2/index.php?route=product/product&product_id=50 ) USB Dali-2 Master unit to start playing and getting familiar with DALI commands. With this unit I will be able to test our own slave hardware - software as well. I will share my experiments of course. Unfortunately this is not my main occupation, I am doing in my spare time, therefore may go slow.
Best regards,
Murat
On 2021/04/17 19:18:17, Gregory Nutt <sp...@gmail.com> wrote:
> Hi, Murat,
>
> When you decide on your development/test hardware, let us know. Maybe
> someone will get inspired to duplicate your setup and help at least with
> some testing.
>
> Greg
>
> On 4/17/2021 3:23 AM, murat tologlu wrote:
> > Dear Greg,
> >
> > Thank you very much for your kind response, valuable warnings and suggestions. I see a very good road-map in your answer. On the other hand I ( probably together with Alan and somebody else interested in participating us) will appreciate all other comments and suggestions.
> >
> > Best regards,
> > Murat
> >
> > On 2021/04/15 20:40:32, Gregory Nutt <sp...@gmail.com> wrote:
> >> 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 <ac...@gmail.com> 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 <mt...@hotmail.com> 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
Posted by Gregory Nutt <sp...@gmail.com>.
Hi, Murat,
When you decide on your development/test hardware, let us know. Maybe
someone will get inspired to duplicate your setup and help at least with
some testing.
Greg
On 4/17/2021 3:23 AM, murat tologlu wrote:
> Dear Greg,
>
> Thank you very much for your kind response, valuable warnings and suggestions. I see a very good road-map in your answer. On the other hand I ( probably together with Alan and somebody else interested in participating us) will appreciate all other comments and suggestions.
>
> Best regards,
> Murat
>
> On 2021/04/15 20:40:32, Gregory Nutt <sp...@gmail.com> wrote:
>> 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 <ac...@gmail.com> 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 <mt...@hotmail.com> 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
Posted by murat tologlu <mt...@hotmail.com>.
Dear Greg,
Thank you very much for your kind response, valuable warnings and suggestions. I see a very good road-map in your answer. On the other hand I ( probably together with Alan and somebody else interested in participating us) will appreciate all other comments and suggestions.
Best regards,
Murat
On 2021/04/15 20:40:32, Gregory Nutt <sp...@gmail.com> wrote:
> 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 <ac...@gmail.com> 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 <mt...@hotmail.com> 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
Posted by Gregory Nutt <sp...@gmail.com>.
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 <ac...@gmail.com> 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 <mt...@hotmail.com> 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
Posted by murat tologlu <mt...@hotmail.com>.
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 <ac...@gmail.com> 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 <mt...@hotmail.com> 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
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
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 <mt...@hotmail.com> 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.
>