Summary

This article shows the completion of the PSoC 6 SDK One Wire Bus library.  It shows the test apparatus for evaluating DS18B20 sensors.

Story

If you remember from the previous articles, I created the one wire bus library by looking at the function calls in the DS18B20 library and reverse engineering the function prototypes.  And, as I said in the earlier article, it would have been way better to just look at the David Antliff “OWB” library.  But that is not how it went down.  I wonder how much time in the world is wasted by programmer re-implementing code that already exists?

After the first four articles, I had three functions which the DS18B20 library defined, but I had not yet implemented.

owb_ret_t owb_write_rom_code(OneWireBus *bus, OneWireBus_ROMCode romcode);
owb_ret_t owb_crc8_bytes(uint32_t val, uint8_t *buffer, uint32_t length);
void   owb_set_strong_pullup( OneWireBus *bus, bool val);

I had not implemented them because I was not totally sure how they worked.  So, I decided to go back to GitHub and see what David had done originally.  When I got to the GitHub site, https://github.com/DavidAntliff/esp32-owb/blob/master/include/owb.h, there were actually quite a few functions in his owb library that I had not implemented.

Here is the list:

owb_ret_t owb_use_crc(OneWireBus * bus, bool use_crc);
owb_ret_t owb_use_parasitic_power(OneWireBus * bus, bool use_parasitic_power);
owb_ret_t owb_use_strong_pullup_gpio(OneWireBus * bus, cyhal_gpio_t gpio);
owb_ret_t owb_read_rom(OneWireBus * bus, OneWireBus_ROMCode * rom_code);
owb_ret_t owb_verify_rom(OneWireBus * bus, OneWireBus_ROMCode *rom_code, bool * is_present);
owb_ret_t owb_write_rom_code(OneWireBus * bus, OneWireBus_ROMCode *rom_code);
uint8_t owb_crc8_byte(uint8_t crc, uint8_t data);
uint8_t owb_crc8_bytes(uint8_t crc, const uint8_t * data, size_t len);
owb_ret_t owb_search_first(OneWireBus * bus, OneWireBus_SearchState * state, bool *found_device);
owb_ret_t owb_search_next(OneWireBus * bus, OneWireBus_SearchState * state, bool *found_device);
char * owb_string_from_rom_code(OneWireBus_ROMCode *rom_code, char * buffer, size_t len);
owb_ret_t owb_set_strong_pullup(OneWireBus * bus, bool enable);

In this article I will create and/or copy the missing functions.  As I look through his implementation I also notice that we have some style differences that I will discuss.  In general I will say that his implementation is very good and any place that I did something different was just a matter of programming taste.

I was originally planning on this article taking you linearly through how I did the changes, but in reality I jumped around while I was doing the changes, that approach won’t work.  Here is the list of what I did:

1. Add Doxygen Function Headers
2. Move Logging Function to Library
3. Change Commands to Enumerated Type
4. Change Const Bus Pointer
5. Pack the Structures
6. Pass Structures as Pointers
7. Driver Functions
8. Test the Search
9. Test the Parastitic Power

Doxygen Headers

I like using documentation that has been generated with Doxygen.  Specifically I like that the documentation is written “at the point of attack”.  But I have never actually used or generated it using Doxygen.  To make the documentation you need to put comments into your c-header files in the right format.  Here is an example from owb.h

/**
* @brief Represents a set of the legal one wire bus commands
*/
typedef enum {
OWB_ROM_SEARCH        =0xF0,  ///< Perform Search ROM cycle to identify devices on the bus
OWB_ROM_READ          =0x33,  ///< Read device ROM (single device on bus only)
OWB_ROM_MATCH         =0x55,  ///< Address a specific device on the bus by ROM
OWB_ROM_SKIP          =0xCC,  ///< Address all devices on the bus simultaneously
OWB_ROM_SEARCH_ALARM  =0xEC,  ///< Address all devices on the bus with a set alarm flag
} owb_commands_t;

In this case, David had done most of the work already and all I needed to do was copy/modify his headers in the few places where we had differences in the public interface to the library.  After that, I ran doxygen.  When I first did this I got an absolute boatload of warnings about places where I had not documented with comments.  If Hassane is reading he will say … “Really Alan didn’t write comments, imagine that”

arh (master *) p6sdk-onewire $ doxygen
Doxygen version used: 1.8.18
Searching for include files...
Searching for example files...
Searching for images...
Searching for dot files...
Searching for msc files...
Searching for dia files...
Searching for files to exclude
Searching INPUT for files to process...
Searching for files in directory /Users/arh/proj/owb-ds18b20/DS18B20Test/p6sdk-onewire
Reading and parsing tag files
Parsing files
Reading /Users/arh/proj/owb-ds18b20/DS18B20Test/p6sdk-onewire/README.md...
Preprocessing /Users/arh/proj/owb-ds18b20/DS18B20Test/p6sdk-onewire/owb.c...
Parsing file /Users/arh/proj/owb-ds18b20/DS18B20Test/p6sdk-onewire/owb.c...
Preprocessing /Users/arh/proj/owb-ds18b20/DS18B20Test/p6sdk-onewire/owb.h...
Parsing file /Users/arh/proj/owb-ds18b20/DS18B20Test/p6sdk-onewire/owb.h...
Building group list...
Building directory list...
Building namespace list...
Building file list...
Building class list...
Computing nesting relations for classes...
Associating documentation with classes...
Building example list...
Searching for enumerations...
Searching for documented typedefs...
Searching for members imported via using declarations...
Searching for included using directives...
Searching for documented variables...
Building interface member list...
Building member list...
Searching for friends...
Searching for documented defines...
Computing class inheritance relations...
Computing class usage relations...
Flushing cached template relations that have become invalid...
Computing class relations...
Add enum values to enums...
Searching for member function documentation...
Creating members for template instances...
Building page list...
Search for main page...
Computing page relations...
Determining the scope of groups...
Sorting lists...
Determining which enums are documented
Computing member relations...
Building full member lists recursively...
Adding members to member groups.
Computing member references...
Inheriting documentation...
Generating disk names...
Adding source references...
Adding xrefitems...
Sorting member lists...
Setting anonymous enum type...
Computing dependencies between directories...
Generating citations page...
Counting members...
Counting data structures...
Resolving user defined references...
Finding anchors and sections in the documentation...
Transferring function references...
Combining using relations...
Adding members to index pages...
Correcting members for VHDL...
Generating style sheet...
Generating search indices...
Generating example documentation...
Generating file sources...
Generating code for file owb.h...
Generating file documentation...
Generating docs for file owb.h...
Generating page documentation...
Generating docs for page md_README...
Generating group documentation...
Generating class documentation...
Generating docs for compound OneWireBus...
Generating docs for compound OneWireBus_ROMCode...
Generating docs for nested compound OneWireBus_ROMCode::fields...
Generating docs for compound OneWireBus_SearchState...
Generating namespace index...
Generating graph info page...
Generating directory documentation...
Generating index page...
Generating page index...
Generating module index...
Generating namespace index...
Generating namespace member index...
Generating annotated compound index...
Generating alphabetical compound index...
Generating hierarchical class index...
Generating member index...
Generating file index...
Generating file member index...
Generating example index...
finalizing index lists...
writing tag file...
Running plantuml with JAVA...
lookup cache used 45/65536 hits=385 misses=48
finished...
arh (master *) p6sdk-onewire $

Now I have some documentation

I will say that I wish I had a few days to really learn Doxygen as there are many many many options which I have no idea what they do.  Oh well.

Fix the Logging Function

David built the library on top of the ESP32 libraries.  This included calls to the ESP32 logging library “log.h/.c“.  All through his library he calls “ESP_LOG” like this.

ESP_LOGE(TAG, "bus is NULL");

When I first looked at this I decided to just do this to make the error messages go away.  This is just a trick that will use the c-preprocessor to replace the function call to “ESP32_LOGE” with NOTHING

#define ESP_LOGE(...)

After I sorted everything else out I went back to decide what to do.  My choices were

1. Clone the Espressif library and “fix it”
2. Implement the functions that David used in the OWB library
3. Find another library

I decided to use option 3 – a logging library that I found on GitHub called “log.c” (which is a very unfortunate name when you clone it).  It is really simple and works well.  Since the Tour de France is going as I write this article I will say “chappeau rxi”.  This library is written in C99 (just normal C) and has functions which can easily replace the ESP_LOG functions.  I add it to my project with “git clone git@github.com:rxi/log.c.git”

log_trace(const char *fmt, ...);
log_debug(const char *fmt, ...);
log_info(const char *fmt, ...);
log_warn(const char *fmt, ...);
log_error(const char *fmt, ...);
log_fatal(const char *fmt, ...);

This means that I just replace “ESP_LOGE” with “log_error”.  In reality rxi did something very nice by using a feature of the compiler to insert the file/line numbers.

#define log_trace(...) log_log(LOG_TRACE, __FILE__, __LINE__, __VA_ARGS__)

This only left me with the function

ESP_LOG_BUFFER_HEX_LEVEL(TAG, scratchpad, count, ESP_LOG_DEBUG);

Which I decided to do something cheap to solve.  The original code was:

              //ESP_LOG_BUFFER_HEX_LEVEL(TAG, &scratchpad->trigger_high, 3, ESP_LOG_DEBUG);

And I replaced the two uses with:

log_debug( "scratchpad write 3 bytes:%02X%02X%02X",scratchpad[0],scratchpad[1],scratchpad[2]);

and

                //ESP_LOG_BUFFER_HEX_LEVEL(TAG, scratchpad, count, ESP_LOG_DEBUG);
log_debug( "%02X%02X%02X%02X%02X%02X%02X%02X%02X",
scratchpad[0],scratchpad[1],scratchpad[2],
scratchpad[3],scratchpad[4],scratchpad[5],
scratchpad[6],scratchpad[7],scratchpad[8]);

I know it isn’t beautiful what I did, but it works.

Enumerated Command Type

When I examined the original source code, the one-wire commands were defined using #defines.

// ROM commands
#define OWB_ROM_SEARCH        0xF0  ///< Perform Search ROM cycle to identify devices on the bus
#define OWB_ROM_READ          0x33  ///< Read device ROM (single device on bus only)
#define OWB_ROM_MATCH         0x55  ///< Address a specific device on the bus by ROM
#define OWB_ROM_SKIP          0xCC  ///< Address all devices on the bus simultaneously
#define OWB_ROM_SEARCH_ALARM  0xEC  ///< Address all devices on the bus with a set alarm flag

When I did the implementation originally I chose to make the #defines into an enumerated list.  I suppose that it doesn’t really matter.  But, by enumerating the values it lets the compiler help you in situations like a switch or a function call.

typedef enum {
OWB_ROM_SEARCH        =0xF0,  ///< Perform Search ROM cycle to identify devices on the bus
OWB_ROM_READ          =0x33,  ///< Read device ROM (single device on bus only)
OWB_ROM_MATCH         =0x55,  ///< Address a specific device on the bus by ROM
OWB_ROM_SKIP          =0xCC,  ///< Address all devices on the bus simultaneously
OWB_ROM_SEARCH_ALARM  =0xEC,  ///< Address all devices on the bus with a set alarm flag
} owb_commands_t;

Const Bus pointer

Through out the original one wire bus library, the bus pointer is defined as const.  Like this:

owb_status owb_read_rom(const OneWireBus * bus, OneWireBus_ROMCode * rom_code)

But, I wanted to use the OneWireBus structure to also store some context.  By context I mean variables (which can change) but hold state for the bus.  This included the semaphore that I used to fix the delay functions.

/**
* @brief Structure containing 1-Wire bus information relevant to a single instance.
*/
typedef struct  
{
cyhal_gpio_t  pin;                   ///<Pin that the bus is attached to
cyhal_gpio_t strong_pullup_gpio;     ///<Pin that the pullup gpio is attached to
bool use_parasitic_power;            ///<Driver is using parastic power mode
bool use_crc;                        ///<Enable the use of crc checks on the ROM
// Internal use only
bool is_init;                        ///<Private
bool detect;                         ///<Private
SemaphoreHandle_t signalSemaphore;   ///<Private
cyhal_timer_t bitTimer;              ///<Private
SemaphoreHandle_t owb_num_active;    ///<Private
uint8_t scratchBitValue;             ///<Private
} OneWireBus;

ROM Code Structure Packed

In the original library the ROMCode is a union that allows access to individual bytes, or the actual data.

typedef union
{
/// Provides access via field names
struct fields
{
uint8_t family[1];         ///< family identifier (1 byte, LSB - read/write first)
uint8_t serial_number[6];  ///< serial number (6 bytes)
uint8_t crc[1];            ///< CRC check byte (1 byte, MSB - read/write last)
} __PACKED fields;             ///< Provides access via field names
uint8_t bytes[8];              ///< Provides raw byte access
} OneWireBus_ROMCode;

The problem is there is no guarantee that the compiler will pack the family, serial number and crc.  You should tell it to with the __PACKED macro.  I would say that I think that David got luck that there was not a bug.

/**
* @brief Represents a 1-Wire ROM Code. This is a sequence of eight bytes, where
*        the first byte is the family number, then the following 6 bytes form the
*        serial number. The final byte is the CRC8 check byte.
*/
typedef union
{
/// Provides access via field names
struct fields
{
uint8_t family[1];         ///< family identifier (1 byte, LSB - read/write first)
uint8_t serial_number[6];  ///< serial number (6 bytes)
uint8_t crc[1];            ///< CRC check byte (1 byte, MSB - read/write last)
} __PACKED fields;             ///< Provides access via field names
uint8_t bytes[8];              ///< Provides raw byte access
} OneWireBus_ROMCode;

C-Programming: Passing Structures as Function Arguments

In the original library David passed the rom_code structure as an argument on the stack.  But, because I started programming in the days before it was legal to pass a structure as a function argument when I did the implementation I passed a pointer.

owb_status owb_verify_rom(const OneWireBus * bus, OneWireBus_ROMCode rom_code, bool * is_present);

I wrote

owb_ret_t owb_verify_rom(OneWireBus * bus, OneWireBus_ROMCode *rom_code, bool * is_present);

Which meant that he could write

        OneWireBus_SearchState state = {
.rom_code = rom_code,
.last_discrepancy = 64,
.last_device_flag = false,
};

but I had to write

        OneWireBus_SearchState state = {
//.rom_code = rom_code,
.last_discrepancy = 64,
.last_device_flag = false,
};
memcpy(&state.rom_code,rom_code,sizeof(OneWireBus_ROMCode));

In this case it doesn’t really matter as the structure is small.

Driver Functions

If you look at the original implementation the author has a “driver”

typedef struct
{
const struct _OneWireBus_Timing * timing;   ///< Pointer to timing information
bool use_crc;                               ///< True if CRC checks are to be used when retrieving information from a device on the bus
bool use_parasitic_power;                   ///< True if parasitic-powered devices are expected on the bus
gpio_num_t strong_pullup_gpio;              ///< Set if an external strong pull-up circuit is required
const struct owb_driver * driver;           ///< Pointer to hardware driver instance
} OneWireBus;

Which is a structure with function pointers to talk to bus.

/** NOTE: Driver assumes that (*init) was called prior to any other methods */
struct owb_driver
{
/** Driver identification **/
const char* name;
/** Pointer to driver uninitialization function **/
owb_status (*uninitialize)(const OneWireBus * bus);
/** Pointer to driver reset functio **/
owb_status (*reset)(const OneWireBus * bus, bool *is_present);
/** NOTE: The data is shifted out of the low bits, eg. it is written in the order of lsb to msb */
owb_status (*write_bits)(const OneWireBus *bus, uint8_t out, int number_of_bits_to_write);
/** NOTE: Data is read into the high bits, eg. each bit read is shifted down before the next bit is read */
owb_status (*read_bits)(const OneWireBus *bus, uint8_t *in, int number_of_bits_to_read);
};

Which meant that he did this:

bus->driver->read_bits(bus, &id_bit, 1);
bus->driver->read_bits(bus, &cmp_id_bit, 1);

In my implementation I wrote functions for those things.

owb_read_bit(bus,&id_bit);
owb_read_bit(bus,&cmp_id_bit);

I don’t really think that it helped abstract the hardware because he also did this.

            gpio_set_level(bus->strong_pullup_gpio, enable ? 1 : 0);

Perhaps a driver with function pointers would have made the original port easier if I had started there?  But if so, it would have required more adherence to the original  architecture.

Test Search

A nice thing that came with his library was an implementation of the search feature which allows multiple devices to be attached to the bus.  To test this I added two sensors.

Then made a command in my console to run the test.

static int usrcmd_search(int argc, char **argv)
{
printf("Search\n");
OneWireBus_SearchState state;
bool found_device;
owb_search_first(&bus, &state, &found_device);
do {
if(found_device)
{
printf("Found Device = ");
for(int i=0;i<8;i++)
{
printf("%02X ",state.rom_code.bytes[i]);
}
printf("\n");
}
owb_search_next(&bus, &state, &found_device);
} while(found_device);
printf("Search done\n");
return 0;
}

Which worked perfectly.

Parasitic Power

I would like to test the functionality of the parasitic power.  Here is a schematic from the data sheet of how it work.  But I don’t have that transistor so that will be left for another day.

What is Next?

There are several things that I should do.

1. Fix up the libraries to use the manifest files so they are available all of the time
2. Fix up the libraries to use the dependency scheme
3. Test the parasitic power
4. Test the actual DS18B20 library (the original point of this whole thing)

I have found myself in the middle of a bunch of other problems, so these things will need to happen another day.

Summary

Recently, I have been helping a reader sort out some code that makes strings of WS2812 LEDs work.  Specifically, this code takes data from a frame buffer inside of the PSoC 6 and drives it out a SPI port via the MOSI pin. I have written about this a couple of times, but,  the new wrinkle in our code is that it allows you to use any combination of SPI port/pins on the chip.  Instead of using the configurators to setup the SPI to GPIO connection, I setup the connection using PDL to talk directly to the PSoC 6 configuration the registers.

Perhaps it is obvious to everyone how a connection from a peripheral to a GPIO works, but I thought that I would write about it anyway.  In this article I am going to show you a bunch of the documentation for PSoC as well as the PDL source code which implements the documentation.  Specifically, I will show you the PSoC 6

1. Architecture TRM
2. Register TRM
3. Datasheet
4. PDL

Architecture TRM

In the picture below, which I copied from the PSoC 6 Architecture TRM, you can see how an individual GPIO works.  Starting  at the Pin of the chip you can see that there are three connections from/to the pin (look at the green box).

• A set of switches to/from the Analog Mux Bus which enable CapSense or Analog peripherals to talk to the Pin
• A connection from the pin to the Analog peripherals (some Analog peripherals can attach directly to a pin and not though the Analog Mux Bus
• A connection to the High Speed I/O Matrix (HSIOM) – for the digital peripherals

Notice that all of the signals coming into the green box from the top are DIGITAL.  All of the signals coming into the box from the bottom are Analog and the line coming into the middle of the box controls the behavior of the I/O.

For my case the SPI is one of the “Fixed Function Digital Peripherals”.  In order to get it to connect to the pin I will beed to pick out the right signal in the multiplexer that is in the HSIOM Matrix box.

When you scroll down a little bit further in the Architecture TRM, the next diagram is a more detailed description of the GPIO.  Notice that there are a bunch of configuration register bits which setup different parts of the I/O like slew rate, interrupts, drive mode etc.  Notice that the multiplexer that is connected to “out”
and “out_en” has a bunch of different possible signals.  Including “GPIO_PRTx_OUT[OUTy]” which is a register bit which is can be used for “digital write”.  For instance GPIO_PRT0_OUT[2] would be P0_2.  The other interesting thing going on here is you can see that there are really three classes of signals attached to the mutiplexer

• The digital output pin
• Active signals – which work while the chip is not in deep sleep
• Deep Sleep signals – which work while the chip is in deep sleep.

On the output side you can see the two pullup and pulldown resistors, as well as the two transistors which pullup and pull down.  All of these can be configured to be connected… or not.

And finally at the bottom of the I/O you can see the analog signals.

 

If you look a little bit further down in the Architecture TRM you will find this table which describes how each of the actual pins on the multiplexer work.

PSoC 6 Register TRM

If you want to start to make specific configurations for specific pins you will need to look into the PSoC 6 Register TRM.  In that document you will find that the

Register TRM

Register TRM

PSoC 6 Datasheet

But what are all of the active and deep sleep signals?  Well if you look in the PSoC 6 data sheet you can find all of those connections.  For instance on P0.1 active signal 8 is the SCB 0 SPI Select signal 2.

PSoC 6 PDL

But really all of these register reads and writes are not really that fun.  So, Cypress provides other, less painful ways of getting things going.  Specifically,

• void Cy_GPIO_SetHSIOM(GPIO_PRT_Type* base, uint32_t pinNum, en_hsiom_sel_t value)

or

• Cy_GPIO_Pin_Init(GPIO_PRT_Type *base, uint32_t pinNum, const cy_stc_gpio_pin_config_t *config)

When you call both of these function you need to provide the value for the multipler either directly in the Cy_GPIO_SetHSIOM or indirectly in the Cy_GPIO_Pin_Init case where you provide it as a member of the cy_stc_gpio_pin_config_t *config structure called “hsiom”

Depending on which package you have selected you will have a file like gpio_psoc6_01_124_bga.h which will have both the generic definitions for the HSIOM multiplexer select (like this)

/* HSIOM Connections */
typedef enum
{
/* Generic HSIOM connections */
HSIOM_SEL_GPIO                  =  0,       /* GPIO controls 'out' */
HSIOM_SEL_GPIO_DSI              =  1,       /* GPIO controls 'out', DSI controls 'output enable' */
HSIOM_SEL_DSI_DSI               =  2,       /* DSI controls 'out' and 'output enable' */
HSIOM_SEL_DSI_GPIO              =  3,       /* DSI controls 'out', GPIO controls 'output enable' */
HSIOM_SEL_AMUXA                 =  4,       /* Analog mux bus A */
HSIOM_SEL_AMUXB                 =  5,       /* Analog mux bus B */
HSIOM_SEL_AMUXA_DSI             =  6,       /* Analog mux bus A, DSI control */
HSIOM_SEL_AMUXB_DSI             =  7,       /* Analog mux bus B, DSI control */
HSIOM_SEL_ACT_0                 =  8,       /* Active functionality 0 */
HSIOM_SEL_ACT_1                 =  9,       /* Active functionality 1 */
HSIOM_SEL_ACT_2                 = 10,       /* Active functionality 2 */
HSIOM_SEL_ACT_3                 = 11,       /* Active functionality 3 */
HSIOM_SEL_DS_0                  = 12,       /* DeepSleep functionality 0 */
HSIOM_SEL_DS_1                  = 13,       /* DeepSleep functionality 1 */
HSIOM_SEL_DS_2                  = 14,       /* DeepSleep functionality 2 */
HSIOM_SEL_DS_3                  = 15,       /* DeepSleep functionality 3 */
HSIOM_SEL_ACT_4                 = 16,       /* Active functionality 4 */
HSIOM_SEL_ACT_5                 = 17,       /* Active functionality 5 */
HSIOM_SEL_ACT_6                 = 18,       /* Active functionality 6 */
HSIOM_SEL_ACT_7                 = 19,       /* Active functionality 7 */
HSIOM_SEL_ACT_8                 = 20,       /* Active functionality 8 */
HSIOM_SEL_ACT_9                 = 21,       /* Active functionality 9 */
HSIOM_SEL_ACT_10                = 22,       /* Active functionality 10 */
HSIOM_SEL_ACT_11                = 23,       /* Active functionality 11 */
HSIOM_SEL_ACT_12                = 24,       /* Active functionality 12 */
HSIOM_SEL_ACT_13                = 25,       /* Active functionality 13 */
HSIOM_SEL_ACT_14                = 26,       /* Active functionality 14 */
HSIOM_SEL_ACT_15                = 27,       /* Active functionality 15 */
HSIOM_SEL_DS_4                  = 28,       /* DeepSleep functionality 4 */
HSIOM_SEL_DS_5                  = 29,       /* DeepSleep functionality 5 */
HSIOM_SEL_DS_6                  = 30,       /* DeepSleep functionality 6 */
HSIOM_SEL_DS_7                  = 31,       /* DeepSleep functionality 7 */

As well as the pin by pin definitions… like this for P0_2

    /* P0.2 */
P0_2_GPIO                       =  0,       /* GPIO controls 'out' */
P0_2_AMUXA                      =  4,       /* Analog mux bus A */
P0_2_AMUXB                      =  5,       /* Analog mux bus B */
P0_2_AMUXA_DSI                  =  6,       /* Analog mux bus A, DSI control */
P0_2_AMUXB_DSI                  =  7,       /* Analog mux bus B, DSI control */
P0_2_TCPWM0_LINE1               =  8,       /* Digital Active - tcpwm[0].line[1]:0 */
P0_2_TCPWM1_LINE1               =  9,       /* Digital Active - tcpwm[1].line[1]:0 */
P0_2_CSD_CSD_TX                 = 10,       /* Digital Active - csd.csd_tx:2 */
P0_2_CSD_CSD_TX_N               = 11,       /* Digital Active - csd.csd_tx_n:2 */
P0_2_LCD_COM2                   = 12,       /* Digital Deep Sleep - lcd.com[2]:0 */
P0_2_LCD_SEG2                   = 13,       /* Digital Deep Sleep - lcd.seg[2]:0 */
P0_2_SCB0_UART_RX               = 18,       /* Digital Active - scb[0].uart_rx:0 */
P0_2_SCB0_I2C_SCL               = 19,       /* Digital Active - scb[0].i2c_scl:0 */
P0_2_SCB0_SPI_MOSI              = 20,       /* Digital Active - scb[0].spi_mosi:0 */

If you look at the Cy_GPIO_Pin_Init function you will see that on line 96 it sets the register which picks the correct pin mux.

cy_en_gpio_status_t Cy_GPIO_Pin_Init(GPIO_PRT_Type *base, uint32_t pinNum, const cy_stc_gpio_pin_config_t *config)
{
cy_en_gpio_status_t status = CY_GPIO_BAD_PARAM;
if ((NULL != base) && (NULL != config))
{
uint32_t maskCfgOut;
uint32_t tempReg;
CY_ASSERT_L2(CY_GPIO_IS_PIN_VALID(pinNum));
CY_ASSERT_L2(CY_GPIO_IS_VALUE_VALID(config->outVal));
CY_ASSERT_L2(CY_GPIO_IS_DM_VALID(config->driveMode));
CY_ASSERT_L2(CY_GPIO_IS_HSIOM_VALID(config->hsiom));  
CY_ASSERT_L2(CY_GPIO_IS_INT_EDGE_VALID(config->intEdge)); 
CY_ASSERT_L2(CY_GPIO_IS_VALUE_VALID(config->intMask));
CY_ASSERT_L2(CY_GPIO_IS_VALUE_VALID(config->vtrip));
CY_ASSERT_L2(CY_GPIO_IS_VALUE_VALID(config->slewRate));
CY_ASSERT_L2(CY_GPIO_IS_DRIVE_SEL_VALID(config->driveSel));
CY_ASSERT_L2(CY_GPIO_IS_VALUE_VALID(config->vregEn));
CY_ASSERT_L2(CY_GPIO_IS_VALUE_VALID(config->ibufMode));
CY_ASSERT_L2(CY_GPIO_IS_VALUE_VALID(config->vtripSel));
CY_ASSERT_L2(CY_GPIO_IS_VREF_SEL_VALID(config->vrefSel));
CY_ASSERT_L2(CY_GPIO_IS_VOH_SEL_VALID(config->vohSel));
Cy_GPIO_Write(base, pinNum, config->outVal);
Cy_GPIO_SetDrivemode(base, pinNum, config->driveMode);
Cy_GPIO_SetHSIOM(base, pinNum, config->hsiom);
Cy_GPIO_SetInterruptEdge(base, pinNum, config->intEdge);
Cy_GPIO_SetInterruptMask(base, pinNum, config->intMask);
Cy_GPIO_SetVtrip(base, pinNum, config->vtrip);
/* Slew rate and Driver strength */
maskCfgOut = (CY_GPIO_CFG_OUT_SLOW_MASK << pinNum) 
| (CY_GPIO_CFG_OUT_DRIVE_SEL_MASK << ((uint32_t)(pinNum << 1U) + CY_GPIO_CFG_OUT_DRIVE_OFFSET));
tempReg = GPIO_PRT_CFG_OUT(base) & ~(maskCfgOut);
GPIO_PRT_CFG_OUT(base) = tempReg | ((config->slewRate & CY_GPIO_CFG_OUT_SLOW_MASK) << pinNum)
| ((config->driveSel & CY_GPIO_CFG_OUT_DRIVE_SEL_MASK) << ((uint32_t)(pinNum << 1U) + CY_GPIO_CFG_OUT_DRIVE_OFFSET));
/* SIO specific configuration */
tempReg = GPIO_PRT_CFG_SIO(base) & ~(CY_GPIO_SIO_PIN_MASK);
GPIO_PRT_CFG_SIO(base) = tempReg | (((config->vregEn & CY_GPIO_VREG_EN_MASK)
| ((config->ibufMode & CY_GPIO_IBUF_MASK) << CY_GPIO_IBUF_SHIFT)
| ((config->vtripSel & CY_GPIO_VTRIP_SEL_MASK) << CY_GPIO_VTRIP_SEL_SHIFT)
| ((config->vrefSel & CY_GPIO_VREF_SEL_MASK)  << CY_GPIO_VREF_SEL_SHIFT)
| ((config->vohSel & CY_GPIO_VOH_SEL_MASK) << CY_GPIO_VOH_SEL_SHIFT))
<< ((pinNum & CY_GPIO_SIO_ODD_PIN_MASK) << CY_GPIO_CFG_SIO_OFFSET));
status = CY_GPIO_SUCCESS;
}
return(status);
}

And finally the Cy_GPIO_SetHSIOM actually writes to the register.

__STATIC_INLINE void Cy_GPIO_SetHSIOM(GPIO_PRT_Type* base, uint32_t pinNum, en_hsiom_sel_t value)
{
uint32_t portNum;
uint32_t tempReg;
HSIOM_PRT_V1_Type* portAddrHSIOM;
CY_ASSERT_L2(CY_GPIO_IS_PIN_VALID(pinNum));
CY_ASSERT_L2(CY_GPIO_IS_HSIOM_VALID(value));
portNum = ((uint32_t)(base) - CY_GPIO_BASE) / GPIO_PRT_SECTION_SIZE;
portAddrHSIOM = (HSIOM_PRT_V1_Type*)(CY_HSIOM_BASE + (HSIOM_PRT_SECTION_SIZE * portNum));
if(pinNum < CY_GPIO_PRT_HALF)
{
tempReg = HSIOM_PRT_PORT_SEL0(portAddrHSIOM) & ~(CY_GPIO_HSIOM_MASK << (pinNum << CY_GPIO_HSIOM_OFFSET));
HSIOM_PRT_PORT_SEL0(portAddrHSIOM) = tempReg | ((value & CY_GPIO_HSIOM_MASK) << (pinNum << CY_GPIO_HSIOM_OFFSET));
}
else
{
pinNum -= CY_GPIO_PRT_HALF;
tempReg = HSIOM_PRT_PORT_SEL1(portAddrHSIOM) & ~(CY_GPIO_HSIOM_MASK << (pinNum << CY_GPIO_HSIOM_OFFSET));
HSIOM_PRT_PORT_SEL1(portAddrHSIOM) = tempReg | ((value & CY_GPIO_HSIOM_MASK) << (pinNum << CY_GPIO_HSIOM_OFFSET));
}
}

PSoC 6 SPI

Finally, it may seem obvious, but there is a limited set of connections to each GPIO in PSoC 6.  This means that any given SCB can only connect its SPI pins to a specific set of pins on the chip.  But, what are they?  You can either look at the data sheet, or you can search the file which you will find the pin definitions which will all be in the form of Px_y_SCBz_SPI_MOSI and this will give you a complete map.

Summary

In this series of articles I have been implementing a one-wire sensor library to work with PSoC 6.  In this article I will test the library by reading the temperature from the DS18B20 sensor.

Story

After three articles crawling through one-wire documents and firmware we are down to the real question.  Will it actually read the temperature?  Each device on a one-wire bus is addressed by a unique 64-bit value which is programmed at the factory.  Before you can talk to a device you need to read the rom value.  The question is how do you find the ROM value when you have multiple devices connected on the bus?  There are two ways

1. Follow a rather complicated discovery process (next article)
2. If there is only 1 device on the bus you can follow a short cut.

Well, lets start with the simple method.

Read ROM

The data sheet is pretty clear about how to read the ROM code when you only have one device.  Basically, you send a 0x33, then you read 8 bytes.  Here is a clip from the data sheet.

I will add a command to my ntshell command line.  The command is “readrom” it will

1. Send the reset
2. Wait 1MS (I don’t think you have to do this, but this was a bug work around)
3. Send the 0x33
4. Then read 8 bytes.
5. And print out the result (lines

OneWireBus_ROMCode rom;
static int usrcmd_readrom(int argc, char **argv)
{
owb_ret_t rval;
printf("Sending reset\n");
bool result;
rval = owb_reset(&bus,&result);
if(rval != OWB_STATUS_OK)
{
printf("Reset failed\n");
return 0;
}
CyDelay(1);
printf("Sending 0x33\n");
rval = owb_write_byte(&bus,0x33);
if(rval != OWB_STATUS_OK)
{
printf("Write 0x33 failed\n");
return 0;
}
// read 64-bit rom
printf("Reading 8 bytes\n");
rval = owb_read_bytes(&bus,rom.romAddr,8);
if(rval != OWB_STATUS_OK)
{
printf("read 8 bytes failed\n");
return 0;
}
// 
printf("Rom = ");
for(int i=0;i<8;i++)
{
printf("%02X ",rom.romAddr[i]);
}
printf("\n");
return 0;
}

When I test it, things seem to be working.

Read Temperature

Now that we know the ROM Code, which is used as the address, how do we get the temperature.  To do this you should follow this procedure.

1. Do a Match ROM
2. Send the ROM address
3. Send a Convert Temperature
4. Wait for the right amount of time
5. Send a Read Scratch Pad
6. Read 9 Bytes
7. Convert the values

The Match ROM command 0x55 + the ROM code selects your device to be acted on.

When you send a convert T 0x44 your device will start the internal process of reading the temperature and storing it in the scratch pad.  The amount of time this take depends on what resolution you have configured.

The scratchpad is a 9-byte register inside of the chip which contains the most recently read temperature plus some settings.

To read the scratchpad you need to send a 0xBE, then read 9-bytes.  Notice that the 9th byte is a CRC for the first 8 bytes,  if you are concerned you can follow the CRC procedure documented in the datasheet to calculate a CRC to verify a match.  For this example, lets skip that.

In order to convert the temperature you need to know the resolution.  Bit-6 and Bit-5 of the configuration register tells you this.  This is a writable register so you can change the resolution which you might do to speed up the reading time.

Here is the whole code together as a new command.

static int usrcmd_readtemp(int argc, char **argv)
{
uint8_t scratchpad[9];
bool result;
// send reset
// send match rom 0x55
// send rom address
// send trigger 0x44
// delay 1 second
// send reset
// send match rom 0x55
// send read scratchpad BEh
// read 9 bytes of scratch pad
owb_reset(&bus,&result);
owb_write_byte(&bus,0x55);
owb_write_bytes(&bus,rom.romAddr,8);
owb_write_byte(&bus,0x44);
vTaskDelay(1000);
owb_reset(&bus,&result);
owb_write_byte(&bus,0x55);
owb_write_bytes(&bus,rom.romAddr,8);
owb_write_byte(&bus,0xbe);
owb_read_bytes(&bus,scratchpad,9);
printf("Scratchpad =");
for(int i=0;i<9;i++)
{
printf("%02X ",scratchpad[i]);
}
printf("\n");
int16_t tempbits = scratchpad[0] | (scratchpad[1] << 8);
uint32_t resolution=2^12;
float temperature=0.0;
switch(scratchpad[5] >>5 & 0x03)
{
case 0:
resolution = 2^9;
break;
case 1:
resolution = 2^10;
break;
case 2:
resolution = 2^11;
break;
case 3:
resolution = 2^12;
break;
}
temperature = (float)tempbits / (float)resolution;
printf("Temperature = %f\n",temperature);
return 0;  
}

Now I build and program the development kit to setup the test.  The first step is to read the ROM with the command line “readrom”.  Then I tell it to try to read the temperature.  You can see the values in the scratch pad, plus my conversion to celsius.  Since I am in Kentucky I probably should have done Fahrenheit … oh well. 28.35C is 83.3F my office is pretty hot today.

Summary

In this article I will replace the stupid busy wait implementation of OneWire write and read bit with an interrupt based implementation.

Story

In the previous article, I implemented a OneWire bus library for PSoC 6.  Specifically, to read temperatures from the DS18B20 1-wire temperature sensor.  This implementation used the CyDelay to handle bit timing. Here is the write bit function.

owb_ret_t owb_write_bit(OneWireBus *bus,uint8_t val)
{
owb_ret_t rval = OWB_STATUS_OK;
cyhal_gpio_write(bus->pin,0);
if(val == 0)
{
CyDelayUs(60);
cyhal_gpio_write(bus->pin,1);
CyDelayUs(2);
}
else
{
CyDelayUs(1);
cyhal_gpio_write(bus->pin,1);
CyDelayUs(60);
}
return rval;
}

And the read bit function.

owb_ret_t owb_read_bit( OneWireBus *bus, uint8_t *bit)
{
owb_ret_t rval = OWB_STATUS_OK;
cyhal_gpio_write(bus->pin,0);
CyDelayUs(1);
cyhal_gpio_write(bus->pin,1);
CyDelayUs(5);
*bit = cyhal_gpio_read(bus->pin);
CyDelayUs(60);
return rval;
}

Both of these functions APPEAR to work perfectly.  Here is a write of 0xFF

However, both of these implementations are subject to fail if an interrupt from the RTOS occurs during the delay period.  You could easily end up with a delay that is too long by enough that the sensor attached to the bus won’t work.  Moreover, I have always hated busy wait loops as the processor could be doing something useful.  So let’s replace this with something better.

This is a late edit to the article, but as I read the documentation for the “owb” library I found this note in Dave Antliff’s documentation

Im not exactly sure what a “RMT” is in the world of ESP32, but I gotta imagine that it is a hardware timer.

Implement an HW Timer and Interrupt Scheme

Both the read and write operation require that the master

• Write a 0
• Wait for some time
• Write a 1
• Wait for some time (then optionally read)
• Wait for some time end

The PSoC 6 TCPWM can be used to generate accurate interrupts at specific times in the future.   This hardware is abstracted using the Cypress HAL which will let you configure

• The input frequency to the timer
• The counter in the timer
• A “compare” value to trigger an interrupt with event type CYHAL_TIMER_IRQ_CAPTURE_COMPARE
• A “period” value to trigger an interrupt with the event type CYHAL_TIMER_IRQ_TERMINAL_COUNT

If you are confused about the TCPWM hardware you are not alone, it can do a mind blowing amount of different things.  However in this simple case we have it set to

1. Input frequency 1 Mhz (aka 1uS per count)
2. Start at 0
3. Trigger an event CYHAL_TIMER_IRQ_CAPTURE_COMPARE at the compare value
4. Tigger an event CYHAL_TIMER_IRQ_TERMINAL_COUNT at the period
5. Stop counting
6. Reset back to 0

If you look the code below on lines 23-30 the configuration of the timer is set.  Remember from the data sheet that a “1” is a 1uS 0 followed by a 60uS 1 and a 0 is a 60uS 0 followed by a 1uS 1.  I use the “compare” to be the trigger from 0–>1.  Notice lines 5-9 in the code below.

On lines 40-41 I tell the HAL that I am interested in getting an event interrupt.

Line 43 initiates the write with a write of 0.  Then line 45 starts the timer going.

To “end” the operation I use a semaphore to wait until the interrupt is triggered by the Terminal Count (aka Period).

void write_bit_event_callback(void *callback_arg, cyhal_timer_event_t event)
{
OneWireBus *bus = (OneWireBus *)callback_arg;
if(event & CYHAL_TIMER_IRQ_CAPTURE_COMPARE)
{
cyhal_gpio_write(bus->pin,1);
}
if(event & CYHAL_TIMER_IRQ_TERMINAL_COUNT)
{
BaseType_t xHigherPriorityTaskWoken;
xHigherPriorityTaskWoken = pdFALSE;
xSemaphoreGiveFromISR(bus->signalSemaphore,&xHigherPriorityTaskWoken);
portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}
}
owb_ret_t owb_write_bit(OneWireBus *bus,uint8_t val)
{
owb_ret_t rval;
cyhal_timer_cfg_t cfgBit = {
.is_continuous = false,
.direction = CYHAL_TIMER_DIR_UP,
.is_compare = true,
.compare_value = 1,
.period = 70,
.value = 0,
};
if(val == 0)
cfgBit.compare_value = 65;
else
cfgBit.compare_value = 1;
cyhal_timer_configure(&bus->bitTimer,&cfgBit);
cyhal_timer_reset(&bus->bitTimer);
cyhal_timer_register_callback(&bus->bitTimer,write_bit_event_callback,bus);
cyhal_timer_enable_event(&bus->bitTimer,CYHAL_TIMER_IRQ_TERMINAL_COUNT|CYHAL_TIMER_IRQ_CAPTURE_COMPARE,5,true);
cyhal_gpio_write(bus->pin,0);
cyhal_timer_start(&bus->bitTimer);
BaseType_t rsem = xSemaphoreTake(bus->signalSemaphore,1); 
if(rsem == pdTRUE)
rval = OWB_STATUS_OK;
else
rval = OWB_STATUS_ERROR;
return rval;
}

Fixing the Write Bug

When I programmed this code I got some weird stuff.  Suck.  So to debug it, I put in a command line to let me “wbyte ff” (or whatever byte value).  At the top of usrcmd.c you need to declare the usrcmd_wbyte function and add it to the command table (notice that I chopped out everything around it)

static int usrcmd_wbyte(int argc, char **argv);
static const cmd_table_t cmdlist[] = {
{ "wbyte","write byte", usrcmd_wbyte},
};

Then make a function will will take an argument (the value you want to write).  Notice that the input is a 2 digit hex number.  Yes I known sscanf is dangerous (but in this case I use it only as a debugging tool.)

static int usrcmd_wbyte(int argc, char **argv)
{
if(argc != 2)
{
printf("Invalid argument write  %d\n",argc);
return 0;
}
owb_ret_t ret=OWB_STATUS_OK;
int val;
sscanf(argv[1],"%02x",&val);
printf("Write Byte Val = %02X\n",val);
ret = owb_write_byte(&bus,(uint8_t)val);
if(ret == OWB_STATUS_OK)
printf("Write byte succeeded\n");
else
printf("Write byte failed\n");
return 0;
}

When I run the code I seem to get the write byte function working sometimes and failing sometimes.  What the hell?

Now, the pain starts.  To debug, I get out the oscilloscope and have a look.  Here is a write of 0xFF which should be 8 short 0 pulses.  But notice that only three get written.  OK, that must mean that the semaphore is timing out. How can that be?

To try to debug that I update a pin to toggle with the semaphore (and git rid of the exit case).

    cyhal_gpio_write(CYBSP_D5,1);
BaseType_t rsem = xSemaphoreTake(bus->signalSemaphore,1); 
cyhal_gpio_write(CYBSP_D5,0);

Now I get this (on the debug pin)… notice a very short timeout… then longer ones followed by another partially shorter timeout.

The problem is the semaphore timeout is set to 1.  Should be at least 1 ms right?  Why is that a problem as 1ms is way more than the 60-ish uS you need to wait?

BaseType_t rsem = xSemaphoreTake(bus->signalSemaphore,1);

Classic off by 1 error.  The 1 means expire at the NEXT SysTick, which will happen NO MORE than 1ms from now. Change it to 2.

    BaseType_t rsem = xSemaphoreTake(bus->signalSemaphore,2); 

Now, all the bits come out at a steady rate.

And it works… sometimes…

Deep Sleep

Other times I end up with this picture.  Notice that the space between the start of one bit and the start of the next bit (from a-b on the scope) is 361.6 uS (don’t forget the 0.6 uS).

Why are the interrupts getting delayed?  The answer is the chip is in deep sleep (or going to deep sleep) when the interrupt from the timer happens.  And when the deep sleep is happening, it takes a bit of time to go to deep sleep, then to wake up.  To fix this go into the system configurator and change the Deep Sleep Latency.

Change the timeout to 3

Now it works.. here is a write of 0xFE

Implement the Read Bit

Now that the write bit is working, move the read bit function to the same scheme.  Notice that I use the compare to trigger the read of the pin.  In the read code I probably should have done a critical section from the start of the 0 to the start of the timer so that an interrupt doesn’t occur before the timer gets started.

void read_bit_event_callback(void *callback_arg, cyhal_timer_event_t event)
{
OneWireBus *bus = (OneWireBus *)callback_arg;
if(event & CYHAL_TIMER_IRQ_CAPTURE_COMPARE)
{
bus->scratchBitValue = cyhal_gpio_read(bus->pin);
}
if(event & CYHAL_TIMER_IRQ_TERMINAL_COUNT)
{
BaseType_t xHigherPriorityTaskWoken;
xHigherPriorityTaskWoken = pdFALSE;
xSemaphoreGiveFromISR(bus->signalSemaphore,&xHigherPriorityTaskWoken);
portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}
}
owb_ret_t owb_read_bit( OneWireBus *bus, uint8_t *bit)
{
owb_ret_t rval;
cyhal_timer_cfg_t cfgBit = {
.is_continuous = false,
.direction = CYHAL_TIMER_DIR_UP,
.is_compare = true,
.compare_value = 10,
.period = 61,
.value = 0
};
cyhal_timer_configure(&bus->bitTimer,&cfgBit);
cyhal_timer_register_callback(&bus->bitTimer,read_bit_event_callback,bus);
cyhal_timer_enable_event(&bus->bitTimer,CYHAL_TIMER_IRQ_TERMINAL_COUNT|CYHAL_TIMER_IRQ_CAPTURE_COMPARE,5,true);
// Pull a 0
cyhal_gpio_write(bus->pin,0);
CyDelayUs(1);
cyhal_gpio_write(bus->pin,1);
cyhal_timer_reset(&bus->bitTimer);
cyhal_timer_start(&bus->bitTimer);
BaseType_t rsem = xSemaphoreTake(bus->signalSemaphore,2); // Then entire write cycle is 61uS so 2ms would be a major failure
*bit = bus->scratchBitValue;
if(rsem == pdTRUE)
rval = OWB_STATUS_OK;
else
rval = OWB_STATUS_ERROR;
return rval;
}

In fact as I look at this code, I decide that I had better to fix the critical section.  Here is the updated read code.

    void taskENTER_CRITICAL();
cyhal_gpio_write(bus->pin,0);     // Pull a 0
CyDelayUs(1);
cyhal_gpio_write(bus->pin,1);
cyhal_timer_start(&bus->bitTimer);
void taskEXIT_CRITICAL( );

And the updated write code

    taskENTER_CRITICAL();
cyhal_gpio_write(bus->pin,0);
cyhal_timer_start(&bus->bitTimer);
taskEXIT_CRITICAL();

In the next article I’ll show you code to actually read the temperature.

 

Summary

In this article I will explain how to implement (badly) the one wire bus read & write functions using the PSoC 6 SDK.  This is one of many articles that are part of a series discussing the implementation:

Story

In the previous article, I built a test framework inside of a PSoC 6 FreeRTOS project.  This includes a command line shell which will enable me to execute functions based on typed commands.  This means I can use the CLI shell to debug my interface.  To get going testing, I bought a DS18B20 temperature sensor from Mouser.

Then wired it like this:

Here is a picture of the test jig.  It looks like I used 4200 ohms instead of 4400 ohms, oh well it seems to work.

Init

Init seems like a good place to start.  To have a one wire bus you need to have a GPIO to read/drive.  So, that will be the only argument to the initialization function.  In the implementation I will use a common semaphore to handle blocking functions (line 13).  On lines 15-17 I initialize a timer to handle the requirements of reset, read and writes (more on this later).  At the end on line 20 I initialize the GPIO.

#include "owb.h"
#include <stdint.h>
#include "cyhal.h"
#include "cybsp.h"
#include "task.h"
#include <stdbool.h>
#include <stdio.h>
owb_ret_t owb_init(OneWireBus *bus)
{
cy_rslt_t rslt;
bus->signalSemaphore = xSemaphoreCreateBinary();
rslt = cyhal_timer_init(&bus->bitTimer,NC,0);
CY_ASSERT(rslt == CY_RSLT_SUCCESS);
rslt = cyhal_timer_set_frequency(&bus->bitTimer,1000000);
CY_ASSERT(rslt == CY_RSLT_SUCCESS);
rslt = cyhal_gpio_init(bus->pin,CYHAL_GPIO_DIR_BIDIRECTIONAL,CYHAL_GPIO_DRIVE_OPENDRAINDRIVESLOW,true);
CY_ASSERT(rslt == CY_RSLT_SUCCESS);
return OWB_STATUS_OK;    
}

In the usrcmd.c I need to add includes for the new stuff.

#include "cybsp.h"
#include "owb.h"

The next step is to add the “init” command to usrcmd.c  This is accomplished by adding a function header for usrcmd_init and adding it to the table of legal commands.

static int usrcmd_init(int argc, char **argv);
typedef struct {
char *cmd;
char *desc;
USRCMDFUNC func;
} cmd_table_t;
static const cmd_table_t cmdlist[] = {
{ "help", "This is a description text string for help command.", usrcmd_help },
{ "info", "This is a description text string for info command.", usrcmd_info },
{ "clear", "Clear the screen", usrcmd_clear },
{ "printargs","print the list of arguments", usrcmd_printargs},
{ "init","Initialize the 1-wire bus", usrcmd_init},
};

Then you need to add the usrcmd_init function to call the owb init.

static OneWireBus bus;
static int usrcmd_init(int argc, char **argv)
{
bus.pin = CYBSP_D4;
owb_init(&bus);
printf("Initialized D4\n");
return 0;
}

Now test it.  All good.

Reset

In order to reset the bus you follow this process

1. Pull down the bus for trstl=480uS
2. Let the bus go back to 1 (remember that it is restive pull-up)
3. Wait another trsth=480uS
4. If there is a slave device on the bus it will pull down the bus at some point to indicate a “presence detect”

From the data sheet you can see that the low& high times = 480uS.  At some point during the high period the slave will pull the bus down for 15->60uS

In order to implement the reset I will modify the owb.c file.  To meet the timing requirements I will use a cyhal_timer.  The cyhal_timer is implemented in the Cypress PDL at a Cy_TCPWM_Timer which is then implemented in the hardware as a timer counter.  In this configuration the timer has:

• A Counter (an up or down counter)
• A Compare (a register which can be compared with the counter to trigger events)
• A Period (a register which is compared to the counter to reset the counter back to 0).   This event is also called the “terminal count”

For this implementation I will setup a timer with

1. Input clock 1Mz (aka 1uS per count)
2. An up counter
3. Starts at 0
4. Compare value = 480 (means trigger an interrupt at 480uS)
5. Period = 960 (means trigger an interrupt at 480uS)
6. One shot (stop counting when you get to period (aka Terminal Count))

The code will

1. Configure the timer (line 41-52)
2. Pull a 0 onto the bus (line 54)
3. Start the timer (line 56)
4. At the compare value 480uS reset the bus to 1 using the event handler (line 20) and setup the GPIO trigger a fall event interrupt (line 21-22)
5. At the period release the semaphore (27-30)
6. After the compare value if the GPIO pulls down, use the GPIO interrupt to record the presence of a device (line 10)

/////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Reset
/////////////////////////////////////////////////////////////////////////////////////////////////////////////
static void reset_gpio_event_callback(void *callback_arg, cyhal_gpio_event_t event)
{
OneWireBus *bus = (OneWireBus *)callback_arg;
if(event & CYHAL_GPIO_IRQ_FALL)
{
bus->detect = true;
}
}
static void reset_timer_event_callback(void *callback_arg, cyhal_timer_event_t event)
{
OneWireBus *bus = (OneWireBus *)callback_arg;
if(event & CYHAL_TIMER_IRQ_CAPTURE_COMPARE)
{
cyhal_gpio_write(bus->pin,1);
cyhal_gpio_register_callback(bus->pin, reset_gpio_event_callback,(void *)bus);
cyhal_gpio_enable_event(bus->pin,CYHAL_GPIO_IRQ_FALL,5,true);
}
if(event & CYHAL_TIMER_IRQ_TERMINAL_COUNT)
{
BaseType_t xHigherPriorityTaskWoken;
xHigherPriorityTaskWoken = pdFALSE;
xSemaphoreGiveFromISR(bus->signalSemaphore,&xHigherPriorityTaskWoken);
portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}
}
owb_ret_t owb_reset(OneWireBus *bus, bool *result)
{
owb_ret_t rval = OWB_STATUS_OK;
bus->detect = false;
cyhal_timer_cfg_t cfgBit = {
.is_continuous = false,
.direction = CYHAL_TIMER_DIR_UP,
.is_compare = true,
.compare_value = 480,
.period = 960,
.value = 0
};
cyhal_timer_configure(&bus->bitTimer,&cfgBit);
cyhal_timer_reset(&bus->bitTimer);
cyhal_timer_register_callback(&bus->bitTimer,reset_timer_event_callback,bus); 
cyhal_timer_enable_event(&bus->bitTimer,CYHAL_TIMER_IRQ_ALL,5,true);
cyhal_gpio_write(bus->pin,0);
cyhal_timer_start(&bus->bitTimer);
xSemaphoreTake(bus->signalSemaphore,2); // worst case is really 960uS
cyhal_gpio_enable_event(bus->pin,CYHAL_GPIO_IRQ_FALL,5,true);
return rval;
}

Once I have the owb_init code I add the init command to usrcmd.c.

static int usrcmd_reset(int argc, char **argv)
{
bool result;
owb_reset(&bus,&result);
if(bus.detect)
{
printf("Reset Succeeded\n");
}
else
printf("Reset Failed\n");
return 0;
}

When I run it, I get this nice picture from the oscilliscope.

Write

In the ds18b20.c file I see that the author has three functions of interest.  In the implementation owb_write_bytes will call owb_write byte and owb_write_byte will call owb_write bit.

owb_ret_t owb_write_bit( OneWireBus *bus, uint8_t val);
owb_ret_t owb_write_byte( OneWireBus *bus, uint8_t val);
owb_ret_t owb_write_bytes( OneWireBus *bus, uint8_t *buffer, uint32_t length);

The one wire protocol has the following steps.

In order to write a “0” you need to

1. Pull down the bus (write a 0)
2. Wait 60uS
3. Write a 1
4. Wait 1uS (to allow the next “slot” to start

In order to write a “1” you need to

1. Pull down the bus (write a 0)
2. Wait 1 uS
3. Write a 1
4. Wait 60uS (to allow the next “slot” to start)

Notice that the minimum write slot is 60uS and the maximum is 120uS.  Here is a picture from the data sheet.

For the first implementation of owb_write_bit I will use a simple “CyDelayUs”  to implement the delays (this is a bad idea, but is a ‘cheap’ way to get going).

owb_ret_t owb_write_bit(OneWireBus *bus,uint8_t val)
{
owb_ret_t rval = OWB_STATUS_OK;
cyhal_gpio_write(bus->pin,0);
if(val == 0)
{
CyDelayUs(60);
cyhal_gpio_write(bus->pin,1);
CyDelayUs(2);
}
else
{
CyDelayUs(1);
cyhal_gpio_write(bus->pin,1);
CyDelayUs(60);
}
return rval;
}

The write byte function just loops through the 8-bit and uses the owb_write_bit function.  Notice that it is least significant bit first.

owb_ret_t owb_write_byte( OneWireBus *bus, uint8_t val)
{
owb_ret_t ret = OWB_STATUS_OK;
for(int i=0;i<8;i++)
{
ret = owb_write_bit(bus,(val>>i) & 0x01);
if(ret != OWB_STATUS_OK)
return ret;        
}
return OWB_STATUS_OK;
}

And write_bytes (multiple) just loops through the buffer calling the write_byte function.

owb_ret_t owb_write_bytes( OneWireBus *bus, uint8_t *buffer, uint32_t length)
{
owb_ret_t ret = OWB_STATUS_OK;
for(int i=0;i<length;i++)
{
ret = owb_write_byte(bus,buffer[i]);
if(ret != OWB_STATUS_OK)
return ret;
}
return OWB_STATUS_OK;
}

Now that I have the three write functions I will add a new command to usrcmd.c  This function lets the user type a command like “wbyte a1” where he/she can input a 2-character hex command.  Yes, I use the sscanf function which is unsafe… but cheap for a test rig.

static int usrcmd_wbyte(int argc, char **argv)
{
if(argc != 2)
{
printf("Invalid argument write  %d\n",argc);
return 0;
}
owb_ret_t ret=OWB_STATUS_OK;
int val;
sscanf(argv[1],"%02x",&val);
printf("Write Byte Val = %02X\n",val);
ret = owb_write_byte(&bus,(uint8_t)val);
if(ret == OWB_STATUS_OK)
printf("Write byte succeeded\n");
else
printf("Write byte failed\n");
return 0;
}

When I program and launch the project I end up here.

OK that is easy enough to fix, I just ran out of stack in the ntshell thread.

    xTaskCreate(ntShellTask, "nt shell task", configMINIMAL_STACK_SIZE*3,0 /* args */ ,0 /* priority */, 0);

Now when I run it I am off to the races.

Here is an example of “wbyte ff”

What about “owb_write_rom_code”?  I don’t know what it does, but Ill figure it out as I integrate the rest of the library.

Read

When I examine the ds18b20.c file I find these three read functions, which mirror the write functions.

owb_ret_t owb_read_bit( OneWireBus *bus, uint8_t *bit);
owb_ret_t owb_read_byte( OneWireBus *bus, uint8_t *byte);
owb_ret_t owb_read_bytes( OneWireBus *bus, uint8_t *buffer, uint32_t length);

To read a bit you follow a a very similar process to the write.

1. Write a 0 on the bus
2. Wait 1uS
3. Write a 1 on the bus (release the bus)
4. Wait 5uS
5. Read (the slave will pull a 0 or a 1 onto the bus)
6. Wait 55uS to the end of the slot

Here is a picture

The code uses a really bad busy-wait delay (but it is a good starting place to figure out what is happening)

owb_ret_t owb_read_bit( OneWireBus *bus, uint8_t *bit)
{
owb_ret_t rval = OWB_STATUS_OK;
cyhal_gpio_write(bus->pin,0);
CyDelayUs(1);
cyhal_gpio_write(bus->pin,1);
CyDelayUs(5);
*bit = cyhal_gpio_read(bus->pin);
CyDelayUs(55);
return rval;
}

To read a byte, just read 8 bits using the owb_read_bit function

owb_ret_t owb_read_byte( OneWireBus *bus, uint8_t *byte)
{
uint8_t bit;
owb_ret_t ret = OWB_STATUS_OK;
*byte = 0;
for(int i=0;i<8;i++)
{
ret = owb_read_bit(bus,&bit);
if(ret != OWB_STATUS_OK)
return ret;
*byte = *byte | (bit<<i);
}
return OWB_STATUS_OK;
}

To read an array of bytes, use a loop of read_byte

owb_ret_t owb_read_bytes( OneWireBus *bus, uint8_t *buffer, uint32_t count)
{
owb_ret_t ret = OWB_STATUS_OK;
for(int i=0;i<count;i++)
{
ret = owb_read_byte(bus,&buffer[i]);
if(ret != OWB_STATUS_OK)
return ret;       
}
return ret;
}

Now that you have a read and a write, update the usrcmd.c to add a “rbyte” command to the CLI

static int usrcmd_rbyte(int argc, char **argv)
{
owb_ret_t ret=OWB_STATUS_OK;
uint8_t val;
ret = owb_read_byte(&bus,&val);
if(ret == OWB_STATUS_OK)
printf("Read byte succeeded %02x\n",val);
else
printf("Read byte failed\n");
return 0;
}

When I program the kit I can send a 0x33 (which will make the sensor respond more on this later), then read the first byte of the ROM

When you look at the scope picture (from right to left) you can see 10110110 which sure enough is B6.  The thin gaps are 1’s and the wide gaps are 0’s

In the next article Ill deal with the stupid CyDelay’s