I've been using libraries for every project I've gone into. If there's no library, for me it was a dead end. Also, whenever I have a problem with some of of a peripheral, I see a people suggesting to run code tests using hex values or sending the bits and bytes directly instead of having the library handle that.
So Here I am. Looking at this datasheet for the 16channel PWM driver
Starting from Section 7, it gives you some setup definitions and a table of all the functions.
How do I use this? How do I build that data message myself instead of having a library handle it for me. There are a lot of various chips which come with no libraries, but they offer these tables and I do not possess the know how to figure out how to use this data to communicate with these ICs.
For all intents and purposes - no. I've thus far used peripherals by using libraries made specifically for those peripherals (like adafruit) and code examples provided by those companies. I've never really created my own messages and sent them manually.
Is the wire library made for just that? Communicating with these peripherals when a library was not provided and all you have to go on is the datasheet with binary codes?
TobiasRipper:
I've been using libraries for every project I've gone into. If there's no library, for me it was a dead end. Also, whenever I have a problem with some of of a peripheral, I see a people suggesting to run code tests using hex values or sending the bits and bytes directly instead of having the library handle that.
Starting from Section 7, it gives you some setup definitions and a table of all the functions.
How do I use this? How do I build that data message myself instead of having a library handle it for me. There are a lot of various chips which come with no libraries, but they offer these tables and I do not possess the know how to figure out how to use this data to communicate with these ICs.
Try to Google - I cannot believe I said that - and look for "device register access" or something similar.
Look for graphical display of I2C standard showing what goes on - from S - ( start) to sending slave address etc.
You already noted that not every I2C device has "library" - more commonly referred to as "driver".
Beware that "Arduino Wire library " (IMHO) is one of the most typical sloppy documented libraries , not really good teaching aid on I2C.
Especially since there are multiple "libraries" written for Arduino claiming to handle I2C protocol for Hitachi LCD controller(s).
This particular device - yes it has a library. A lot of other more specialized I've looked at and would like to use, most often offer a datasheet with bits and byte definitions for commands, and no arduino library. Also I want to consider micro-controller storage for smaller projects, where libraries would have bloated functions I don't necessarily need in my particular application. And finally I actually want yo know how to do this so that should there be No library or a broken / outdated one would be given, It wouldn't mean a dead end for me.
Also as mentioned sometimes people here suggest fixes and tests for troubleshooting with codes meant to be used with your own communication code, not with a library like "Send this Hex Code at this point and see what happens"
OK, I guess it depends on your level experience in dealing with complex ICs. The datasheets vary greatly in quality from manufacturer to manufacturer and device to device. But, typically, they all include a few common things:
A block diagram. I consider this one of the most important items as it gives you an idea of the device's inner architecture and workings.
Theory of operation / functional description -- read it, learn it
Register map -- most of these complex devices are control by register banks. They configure the mode the device will operate in.
Control Interface -- how are the registers set and read? This is how you control the device and get it to do what you want. The interface could be I2C, SPI, RS232, GPIO, etc.
Pin Out, Power Supply Info, Bypassing, Recommended PWB layout -- if you're using a module (rather than a chip) many of these things should be taken care of for you already.
If I really wanted to learn the guts of one of these devices, I'd read the datasheet cover-to-cover several times. Then, if there was already a library available, I'd go through that code line-by-line with the datasheet right in front of me.
If there were no library, I'd start one from scratch by first implementing the most basic functions and then building from there. Many devices power up (or reset) in a configuration that allows you to do SOMETHING without too much messing around. Build from there until you've implemented the modes you need. If you're just doing it for a one-off project, then you don't need to build a complete library that implements EVERY function of the device. Just get it to do what you need for your project.
The reason I asked if you were familiar with I2C is because if you are not the I2C stuff can easily get in the way of thinking about the peripheral.
Many peripherals work by receiving a message (often a number that represents a register) which causes them to make a specific response - for example it might send back the value that is in the register.
My recent experience is with SPI and nRF24L01+ modules. I suspect the overall process for using your peripheral is essentially the same.
One thing that can be confusing is that you sometimes need to send a "dummy" byte (any old nonsense, the value won't matter) to cause the necessary clock pulses to allow the peripheral to send a byte to you.
A good way to learn how it is done is to look at the source code for an library.