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. > >>>>>>>>> > >> >