Advantages of Polycrystalline Solar Panels
The process used to make polycrystalline silicon is simpler and costs less. The amount of waste is also less on the panel itself because of the way the silicon wafers are applied to the panel.
Solar Panel / PV MODULE:
China manufacturer SUNKET best solar panels, poly panels, mono panels, customized panels, solar cells, Solar Power System.
Polycrystalline Panel,Polycrystalline Solar Module,Polycrystalline Solar Panel Price,Best Polycrystalline Solar Panels Wuxi Sunket New Energy Technology Co.,Ltd , https://www.sunketsolar.com
1. High reliability with guaranteed -3% to +5% power output tolerance, ensuring a return on investment
2. High conversion efficiency based on leading innovative photovoltaic technologies
3. Withstands high wind-pressure and snow load, and extreme temperature variations
4. Attractive appearance unique frame design, high mechanical strength, and Easy Installation
5. Front glass high transmission, low iron, tempered glass
6. Excellent modules efficiency up to 19.58%
7. Reducing power loss caused by covering (dirty efficient)
8. Excellent low-light
9. IP67 junction box available long-term weather endurance
10. Salt mist, ammonia, and blowing sand resistance, apply to seaside farm and desert environment
The eighth chapter is about understanding AMetal in depth. The content of this article includes sections 8.3 Buzzer Interface and 8.4 Temperature Acquisition Interface.
**8.3 Buzzer Interface**
> > >
**8.3.1 Defining Interfaces**
**1. Interface Naming**
Since the object of operation is a buzzer, the interface name is prefixed with "am_buzzer_". For the buzzer, the basic operations are to turn it on and off. Corresponding interfaces can be defined as:
Am_buzzer_on
Am_buzzer_off
In some applications, an operation similar to the buzzer's "click" is required, where the beep automatically stops after a certain period. You can define its interface name:
Am_buzzer_beep
Am_buzzer_beep_async
These two interfaces are used for the buzzer to call for a specified time. The difference is that Am_buzzer_beep will wait for the beep to finish before returning, while Am_buzzer_beep_async will return immediately, and the buzzer will stop automatically after the specified time.
This asynchronous interface was not initially considered but was derived from practical applications. In some scenarios, blocking the program is not desirable, so an asynchronous interface like Am_buzzer_beep_async is necessary.
**2. Interface Parameters**
In designing the LED universal interface, since there may be multiple LEDs in a system, a unique ID number (led_id) is used to distinguish them. However, for the buzzer, which has a single function and is typically a single device in a system, there is no need for parameters like buzzer_id to distinguish between multiple buzzers.
For the interfaces to turn the buzzer on and off, no parameters are needed:
Am_buzzer_on(void);
Am_buzzer_off(void);
However, for the Am_buzzer_beep and Am_buzzer_beep_async interfaces, a parameter specifying the duration of the beep is required. The interface definitions are:
Am_buzzer_beep(uint32_t ms);
Am_buzzer_beep_async(uint32_t ms);
Where "ms" specifies the duration of the beep in milliseconds.
**3. Return Value**
All interfaces have their return value defined as a standard error number of type int. Based on this, the complete definition of the buzzer control interface is shown in Table 8.5.
Table 8.5 Buzzer Universal Interface (am_buzzer.h)
[Image: http://i.bosscdn.com/blog/15/32/33/5305-0.jpg]
The corresponding class diagram is shown in Figure 8.8.
[Image: http://i.bosscdn.com/blog/15/32/33/4628-1.jpg]
Figure 8.8 Buzzer Interface Class Diagram
> > >
**8.3.2 Implementing the Interface**
**1. Abstract Buzzer Device Class**
The buzzer has four general-purpose interfaces. Am_buzzer_beep() and Am_buzzer_beep_async() can be directly implemented based on Am_buzzer_on() and Am_buzzer_off(). The implementation of Am_buzzer_beep() is shown in Listing 8.24.
Listing 8.24 Implementation of Am_buzzer_beep()
[Image: http://i.bosscdn.com/blog/15/32/33/1007-2.jpg]
In the program, first use Am_buzzer_on() to open the buzzer. If the buzzer is turned on (the return value is negative), the corresponding error number is returned. If successful, the specified time is delayed using Am_mdelay(), and then the buzzer is turned off.
For the Am_buzzer_beep_async() interface, the delay function cannot be used directly inside the function. It can be implemented based on the software timer. The sample program is shown in Listing 8.25.
Sample Listing 8.25 Am_buzzer_beep_async() Sample Program
[Image: http://i.bosscdn.com/blog/15/32/33/2145-3.jpg]
In the program, first use Am_buzzer_on() to open the buzzer. If the buzzer is turned on (the return value is negative), the corresponding error number is returned. If successful, the software timer is started, and the function returns immediately after starting the timer. After the software timer expires, the custom callback function __beep_timer_callback() is called. In the callback function, the software timer and buzzer are turned off, and the beep ends.
The software timer needs to be initialized before use. The initialization statement should be placed appropriately, as described later.
Since Am_buzzer_beep() and Am_buzzer_beep_async() can be directly implemented based on Am_buzzer_on() and Am_buzzer_off(), the core of the buzzer interface is to implement these two interfaces. These can be abstracted similarly to the LED or HC595 design method.
Although it is feasible to follow this design method, considering that on and off are mutually symmetric interfaces, it is possible to abstract only one method and use a Boolean parameter to distinguish whether the operation is on or off.
It can be seen that the definition of the abstract method is not necessarily the original abstract method according to the interface definition, and can be adjusted as long as the general interface can be implemented based on the abstract method.
Although there is only one abstract method, to ensure structural consistency and facilitate future extensions, the abstract method is often placed in a virtual function table.
Similarly, the abstract method and p_cookie are defined together, forming an abstract buzzer device.
When defining the buzzer interface, since the buzzer is a single instance device, there is no parameter defined in the interface to distinguish the buzzer object, such as an ID number or handle parameter. Therefore, the interface implementation must find the right device. Since there is only one buzzer device in the system, a global variable can be used to point to the buzzer device.
The implementation of Am_buzzer_on() and Am_buzzer_off() is detailed in Listing 8.26.
Sample Listing 8.26 Sample Programs for Am_buzzer_on and Am_buzzer_off()
[Image: http://i.bosscdn.com/blog/15/32/33/E06-10.jpg]
Where __gp_buzzer_dev is a pointer to the buzzer device and initially does not have any valid buzzer devices, so the initial value is NULL. To use the buzzer properly, you must point __gp_buzzer_dev to a valid buzzer device, which requires the pfn_buzzer_set abstract method to be implemented by the specific buzzer device.
To complete the assignment of __gp_buzzer_dev, a device registration interface is needed for registering a valid buzzer device with the system.
In order to facilitate the addition of a buzzer device to the system, avoid directly operating each member of the buzzer device, and pass the member that needs to be assigned to the interface function through the parameter.
The implementation is detailed in Listing 8.27.
Listing 8.27 Adding a Buzzer Device to the System
[Image: http://i.bosscdn.com/blog/15/32/33/3961-12.jpg]
The program first checks the validity of the parameter, then completes the assignment of the abstract method and p_cookie in the abstract device, assigns the global variable __gp_buzzer_dev to the valid buzzer device, and finally initializes the software timer in the abstract device. This facilitates the asynchronous buzzer sound interface.
It can be seen that the initialization of the software timer is completed when a buzzer device is added.
Next, a specific buzzer device must be derived from the abstract buzzer device, complete the abstract method pfn_buzzer_set in the specific buzzer device, and add the buzzer device to the system using the am_buzzer_dev_register() interface. This allows the user to operate a specific effective buzzer using the buzzer universal interface.
For ease of reference, the contents of the buzzer device interface file (am_buzzer_dev.h) are shown in Listing 8.28. The corresponding class diagram is shown in Figure 8.9.
Listing 8.28 am_buzzer_dev.h File Contents
[Image: http://i.bosscdn.com/blog/15/32/33/G13-13.jpg]
[Image: http://i.bosscdn.com/blog/15/32/33/K22-14.jpg]
Figure 8.9 Abstract Buzzer Device Class
**2. Specific Buzzer Device Class**
Taking the PWM output control buzzer as an example, the implementation method of the specific buzzer device is briefly described. First, a specific device class should be derived based on the abstract device class. The class diagram is shown in Figure 8.10, which can directly define the specific buzzer device class, such as:
[Image: http://i.bosscdn.com/blog/15/32/33/2160-15.jpg]
[Image: http://i.bosscdn.com/blog/15/32/33/2635-16.jpg]
Figure 8.10 Specific Buzzer Device Class
Am_buzzer_pwm_dev_t is the specific buzzer device class. With this type, you can use this type to define a specific buzzer device instance, namely:
[Image: http://i.bosscdn.com/blog/15/32/33/1462-17.jpg]
In particular, since the buzzer is a single-instance device and cannot be defined with this type, it is possible to define a buzzer device instance directly inside a file implemented by a specific device without requiring the user to use a custom device instance of that type. Based on this, the am_buzzer_pwm_dev_t type does not need to be open to the user and can be directly defined in the .c file.
When using the PWM output to control the buzzer, you need to know the handle of the PWM, the channel number, and other related information. This information needs to be saved in the device, so the updated device type is defined as follows:
[Image: http://i.bosscdn.com/blog/15/32/33/3636-19.jpg]
Obviously, these members need to be initialized before they can be used. The prototype for defining the initialization function is:
[Image: http://i.bosscdn.com/blog/15/32/33/5016-20.jpg]
Among them, pwm_handle is the standard PWM service handle, chan is the PWM channel number, duty_ns and period_ns respectively specify the pulse width and period of the output PWM waveform, which determines the loudness and frequency of the buzzer, for example, AM824-Core onboard buzzer.
If SCT output PWM is used, since PIO0_24 corresponds to channel 1 of SCT, the initial call function is called as follows:
[Image: http://i.bosscdn.com/blog/15/32/33/D62-21.jpg]
In the program, the am_lpc82x_sct0_pwm_inst_init() function is used to obtain the PWM handle, channel 1 is used, and the output PWM period is set to 400000ns, which is 2.5KHz (1000000000 / 400000), and the pulse width is exactly half of the period, that is, the output PWM duty cycle is 50%. An example of the implementation of the initialization function is shown in Listing 8.29.
Listing 8.29 Initialization Function Implementation Example
[Image: http://i.bosscdn.com/blog/15/32/33/I38-22.jpg]
The program first determines the validity of the parameter, then completes the assignment of the relevant member in the device instance, then calls the am_buzzer_dev_register() function to add the buzzer device to the system, and finally configures the pulse width and period of the PWM output channel.
When adding a device, assign p_funcs to &__g_buzzer_pwm_drv_funcs, and p_cookie to the address of the specific device, i.e., p_cookie points to the device itself. The concrete implementation of the abstract method is contained in __g_buzzer_pwm_drv_funcs. See Listing 8.30 for a complete definition.
Listing 8.30 Implementation of the Abstract Method
[Image: http://i.bosscdn.com/blog/15/32/33/4344-23.jpg]
For ease of reference, the contents of the buzzer device interface file (am_buzzer_pwm.h) are shown as shown in Listing 8.31.
Listing 8.31 am_buzzer_pwm.h File Contents
[Image: http://i.bosscdn.com/blog/15/32/33/3455-24.jpg]
It can be seen that compared with the interface files of other specific devices (see Listing 8.14, Listing 8.17, and Listing 8.23), the difference is that it does not contain the definition of the specific device type, and the first parameter of the interface is not a pointer to a specific device. This is because the buzzer is a single-instance device, and only one can be defined in the system. Therefore, the definition of the device instance is completed directly in the implementation file, and the related types need not be opened to the user. Similarly, since it is a single instance device, the initialization function must be a device instance defined inside the file, and there is no need to additionally use a pointer to the device to specify the device to be initialized.
So far, the LED universal interface, HC595 interface, and buzzer interface are described in detail, which represent the typical three types of device interfaces in AMetal.
LED universal interface: Different devices are distinguished by unique IDs;
HC595 interface: Use handles to distinguish between different devices, the handle is essentially a pointer to the device;
Buzzer interface: A single instance device that does not use any parameters to distinguish different devices.
**8.4 Temperature Acquisition Interface**
> > >
**8.4.1 Defining Interfaces**
**1. Interface Naming**
Since the object of operation is temperature, to shorten the interface name, temperature is abbreviated as "temp", so the interface name is prefixed with "am_temp_". For temperature acquisition, the main operation is to read the current temperature. The definable interface name is:
Am_temp_read
**2. Interface Parameters**
There may be multiple temperature sensors in a system, and the handle can be used to distinguish different temperature sensors. Therefore, the type of the first parameter is defined as the temperature sensor handle. Similar to the HC595 device, it should be defined as pointing to the abstract temperature device. The pointer, assuming the type of the abstract temperature device is am_temp_dev_t, the type of the handle can be defined as:
[Image: http://i.bosscdn.com/blog/15/32/33/M50-25.jpg]
The core function of the read temperature interface is to return the current temperature value. First, define the type of the temperature value, and determine the return method of the temperature value: return by return value or return by exit parameter.
Usually, a decimal value is used to represent the temperature value, for example, 37.5 °C. It can be seen that the temperature value needs to be represented by a decimal number, but the required precision is not high, and it is often only accurate to one decimal place. Therefore, the temperature value can be used as the float type. Said.
Since the actual hardware platform that Ametal runs is often a low-end Cortex-M0, Cortex-M0+, and Cortex-M3 core chips, these chips do not have hardware floating-point arithmetic units, and the efficiency of floating-point operations is very low. Therefore, in the AMetal platform, the floating point type is not recommended. According to this, the integer can be used to represent the temperature value. At the same time, in order to ensure a certain precision, the integer value is used to express the temperature value after the expansion by 1000 times. If the actual temperature is 37.5 degrees, it is represented by the integer 37500. Using this method cleverly avoids the use of floating point types, but also ensures that the accuracy of the actual temperature is three decimal places. Since the temperature may have a negative value, the signed 32-bit data is used to represent the temperature value, i.e., the type of the temperature value is defined as int32_t.
In the generic interface, the return value is often defined as an error number of type int, and a negative number is used to indicate an error. Obviously, if the return value is used to directly return the temperature, the user will not be able to distinguish between a negative temperature and a read temperature error. To do this, use an output parameter to return the temperature value, i.e., define a pointer of type int32_t as the output parameter:
Am_temp_read(am_temp_handle_t handle, int32_t *p_temp)
Where handle is the handle of the temperature sensor and p_temp is the output parameter, which is used to return the current temperature value, which represents the temperature value 1000 times of the actual temperature value.
**3. Return Value**
The interface has no special description, and directly defines the return value of all interfaces as the standard error number of type int. Based on this, the prototype of the complete read temperature interface is:
[Image: http://i.bosscdn.com/blog/15/32/33/3123-26.jpg]
The corresponding class diagram is shown in Figure 8.11.
[Image: http://i.bosscdn.com/blog/15/32/33/NK-27.jpg]
Figure 8.11 Temperature Acquisition Interface
> > >
**8.4.2 Implementing the Interface**
**1. Abstract Temperature Acquisition Device Class**
According to the read temperature interface, you can define the corresponding abstract method and store it in a virtual function table:
[Image: http://i.bosscdn.com/blog/15/32/33/H07-28.jpg]
Similarly, the abstract method and p_cookie are defined together, which is an abstract temperature acquisition device. Such as:
[Image: http://i.bosscdn.com/blog/15/32/33/6141-29.jpg]
Obviously, the specific temperature acquisition device is directly derived from the abstract temperature acquisition device, and then the specific temperature acquisition device realizes the abstract method of reading temperature according to the actual hardware.
In the read temperature interface, the handle is used as the first parameter, which is essentially a pointer to the device. The read temperature interface can directly call the abstract method implementation. See Listing 8.32 for details.
Listing 8.32 Reading Temperature Interface Implementation
[Image: http://i.bosscdn.com/blog/15/32/33/4263-30.jpg]
In the interface implementation, there is no hardware-related implementation code, just a simple call to the abstract method. The abstract method needs to be implemented by a specific temperature acquisition device. Similarly, since the implementation of the read temperature interface is very simple, its implementation is often stored directly in the .h file as an inline function.
For ease of reference, the contents of the abstract temperature acquisition device interface file (am_temp.h) are shown in Listing 8.33, which contains the abstract method definitions, type definitions, and interface implementations associated with the abstract temperature acquisition device. See Figure 8.12.
[Image: http://i.bosscdn.com/blog/15/32/33/3D3-31.jpg]
Figure 8.12 Abstract Temperature Collection Device Class
Listing 8.33 am_temp.h File Contents
[Image: http://i.bosscdn.com/blog/15/32/33/21A-32.jpg]
**2. Specific Temperature Collection Equipment**
Taking the LM75B temperature sensor for temperature acquisition as an example, the implementation method of the specific temperature acquisition device is briefly described. First, a specific device class should be derived based on the abstract device class. The class diagram is shown in Figure 8.13, which can directly define the specific temperature collection device class. Such as:
[Image: http://i.bosscdn.com/blog/15/32/33/20X-33.jpg]
[Image: http://i.bosscdn.com/blog/15/32/33/5363-34.jpg]
Figure 8.13 Specific Temperature Collection Equipment Class
Am_temp_lm75_t is a specific temperature collection device class. After this type, you can use this type to define a specific temperature acquisition device instance:
[Image: http://i.bosscdn.com/blog/15/32/33/41C-35.jpg]
The LM75B is a standard I2C slave device that requires the slave address of the LM75B to be used to read the temperature data in the LM75B using the I2C bus. Since the slave address is related to the LM75 external pin level, the address information of the LM75 needs to be set by the user according to the actual hardware circuit. Store device-related information that needs to be provided by the user into a new device information structure type. Such as:
[Image: http://i.bosscdn.com/blog/15/32/33/1361-36.jpg]
When using the LM75B onboard the AM824-Core, the 7-bit I2C slave address of the LM75B is 1001A2A1A0. Since A0, A1, and A2 are both tied low to ground, the 7-bit slave address of the onboard LM75B is available. It is 1001000, i.e.: 0x48. Based on this, the device instance information corresponding to the onboard LM75B can be defined as follows:
[Image: http://i.bosscdn.com/blog/15/32/33/N43-37.jpg]
For the same reason, it is necessary to maintain a pointer to device information in the device class. In addition, since the temperature data is read from the LM75B using the I2C interface, the LM75B is equivalent to an I2C slave. To communicate with the I2C interface, you need to define a corresponding I2C slave for the LM75B. Two new members are added. The complete temperature acquisition device definition is:
[Image: http://i.bosscdn.com/blog/15/32/33/1341-38.jpg]
Obviously, before using the I2C interface to read the temperature from the LM75B, you need to complete the assignment of each member of the device. This is usually done in the driver's initialization function. The prototype that defines the initialization function is:
[Image: http://i.bosscdn.com/blog/15/32/33/2403-39.jpg]
P_lm75 is a pointer to an instance of type am_temp_lm75_t;
P_devinfo is a pointer to the instance information of the am_temp_lm75_info_t type.
Handle is an I2C handle, which is convenient for reading temperature data using the I2C interface. The return value of the initialization function is the handle of the temperature acquisition device. The call form is as follows:
[Image: http://i.bosscdn.com/blog/15/32/33/5162-40.jpg]
The return value is the handle of the temperature acquisition device, which can be used as the actual parameter of the first parameter of the temperature acquisition interface. The implementation example of the initialization function is shown in Listing 8.34.
Listing 8.34 Initialization Function Implementation Example
[Image: http://i.bosscdn.com/blog/15/32/33/D48-41.jpg]
The program first establishes a standard I2C slave device, which facilitates subsequent reading of data using the I2C interface, then initializes the p_info member, then completes the assignment of p_funcs and p_cookie in the abstract temperature acquisition device, and finally returns the device address as the user operating temperature acquisition device. Handle. Pfuncs is assigned the value of &__g_temp_lm75_drv_funcs, which contains a concrete implementation of the read temperature abstraction method. See Listing 8.35 for a complete definition.
Listing 8.35 Implementation of the Abstract Method
[Image: http://i.bosscdn.com/blog/15/32/33/5442-42.jpg]
In the read temperature implementation function __temp_lm75_read(), the current actual temperature value is first read from the LM75B using the I2C interface, as shown in Listing 8.35(6); then the data is simply processed, and the two-byte data is integrated. For a 16-bit signed temperature value temp, see Listing 8.35 (10 ~ 11); finally, after confirming that the p_temp pointer is valid, multiply temp by 125 and divide by 32, and the final result is used as the output temperature value.
Why multiply temp by 125 and then divide by 32? This is because the data directly read in the LM75B is 256 times the actual temperature value, i.e.: actual temperature = temp / 256.
The temperature collection interface needs to return a temperature value that is 1000 times the actual temperature, namely:
* p _ temp = actual temperature * 1000 = temp / 256 * 1000 = temp * 1000 / 256
Simplification is available:
[Image: http://i.bosscdn.com/blog/15/32/33/1335-43.jpg]
For ease of reference, the contents of the specific temperature acquisition device (LM75B) interface file (am_temp_lm75.h) are shown in Listing 8.36.
Listing 8.36 am_temp_lm75.h File Contents
[Image: http://i.bosscdn.com/blog/15/32/33/3F5-44.jpg]
Related Products