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 <spudan...@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 <spudan...@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 <spudan...@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 <spudan...@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 <acas...@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 <mtolo...@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.
> >>>>>>>>>
> >>
> 

Reply via email to