If you are not confident with using a transistor (the perfect solution in this case) then you could use a relay. Some smaller relays can be driven from an I/O pin and used for switching VCC to your 5v booster on/off, bigger relays sadly need a transistor anyway such as those commonly used in automotive electrical systems.
Decent guide on using a transistor here though: https://learn.adafruit.com/adafruit-arduino-lesson-13-dc-motors/transistors That is in the context of a DC motor connected to an arduino uno but could just as easily be your LMR61428 connected to the launchpad.
Ok, my totally reworked version of RobG's G2553 example.
A number of changes have occurred here to Rob's core code:
1. Some minor bugs in the Sn_IMR macros in w5500.h were fixed (although I don't use them)
2. A "piecemeal I/O" infrastructure has been added-
BSS bloated by 32 bytes as we now track a local copy of the RX_RD and TX_WR variables, since these variables can be written to but not read back; reading back their values actually gives us the original values, until Sn_CR_RECV or Sn_CR_SEND respectively are submitted; the whole idea behind this "piecemeal I/O" is that we're not doing this, we don't want the buffers to change yet.
u_int _tx_wr_cache, _rx_rd_cache; /* Used for "piecemeal" writes & reads when
* we update TX_WR or RX_RD but the WizNet still
* gives us the old value until we perform a CR
* command action on the socket.
A pair of functions update this value for a specified socket:
void refreshTXBufferCache(u_char s);
void refreshRXBufferCache(u_char s);
For the most part you don't have to worry about it, as I've peppered those calls inside the existing stuff like socket() et al. But do know that if you submit an Sn_CR_SEND or Sn_CR_RECV yourself, you may want to update the internal "state" of those cached variables if you happen to be using the Piecemeal I/O functions.
The piecemeal I/O functions consist of:
void writeToTXBufferPiecemeal(u_char s, u_char* array, u_int length);
void fillTXBufferPiecemeal(u_char s, u_char value, u_int length);
void readFromRXBufferPiecemeal(u_char s, u_char* array, u_int length);
void flushRXBufferPiecemeal(u_char s, u_int length);
u_int getTXVirtualFreeSize(u_char s);
u_int getVirtualRXReceived(u_char s);
writeToTXBufferPiecemeal writes the specified array of length bytes to the buffer, updates TX_WR both on the chip and in the local cache, but does not send the data just yet. It always starts writing from the current value of the "local cached copy" of TX_WR, so that you can continuously append to the buffer without committing the packet.
fillTXBufferPiecemeal is similar, but it writes a single byte length # of times. I added a fillMemoryArray() call likewise to support that.
readFromRXBufferPiecemeal is as you'd expect... it reads those bytes, updates Sn_RX_RD and a local cached copy of it. Further reads from that use the local cached copy of RX_RD as the address to start from.
flushRXBufferPiecemeal merely advances RX_RD without reading; advancing the "local cached copy" likewise.
getTXVirtualFreeSize computes the "amount of free space available" using the chip's copy of TX_RD and our local cached copy of TX_WR.
getVirtualRXReceived computes the "amount of unread data" using the chip's copy of RX_WR and our local cached copy of RX_RD.
Also to make it feel more unix-y, I've added these:
u_int ntohs(u_char *array);
void htons(u_int val, u_char *array);
which are used extensively within the DHCP code.
There is a printf-style debugging infrastructure used extensively throughout the dhcplib code, and you can use it in your own software as well.
See wizdebug.c and wizdebug.h. It has a hierarchical "debug level" of aliases called wiznet_debugN_printf() where N goes from 1 to 6, and if the WIZNET_DEBUG #define is less than N, that function is #define'd away as a simple ";", with WIZNET_DEBUG 0 removing it entirely.
/* Debug levels:
* 1 - Basic information from libraries
* 2 - Error reporting from libraries
* 3 - Gratuitous information from libraries
* 4 - Pedantic information from libraries
* 5 - Extraneous detail from base socket library
* 6 - Low-level I/O dump from SPI transfer functions
* Each debug level includes information from all levels below.
#define WIZNET_DEBUG 4
void wiznet_debug_printf(char *format, ...);
void wiznet_debug_putc(unsigned int);
void wiznet_debug_puts(const char *);
#if WIZNET_DEBUG > 0
#define wiznet_debug1_printf(...) wiznet_debug_printf(__VA_ARGS__)
#define wiznet_debug1_printf(...) ;
#if WIZNET_DEBUG > 1
#define wiznet_debug2_printf(...) wiznet_debug_printf(__VA_ARGS__)
#define wiznet_debug2_printf(...) ;
#if WIZNET_DEBUG > 2
#define wiznet_debug3_printf(...) wiznet_debug_printf(__VA_ARGS__)
#define wiznet_debug3_printf(...) ;
(etc and so forth)
You may want to inspect wiznet_debug_init() in wizdebug.c to make sure it supports your UART or other peripheral correctly. Likewise, the source is all there, you can change it to spit the data out over SPI or I2C or whatever if you'd like.
The printf function is based on @@oPossum 's code... minor addition is a "%h" type exists to print 8-bit hex only, whereas "%x" does 16-bit hex.
The '\n' char is expanded to '\r\n' for UART use; see the bottom of wiznet_debug_printf() for that code, which can be changed.
Also note that none of this has been tested on CCS yet, so I'll be looking for folks to try it out.
Ok... DHCP library.
dhcplib.h has a tunable:
/* User-tunable options. */
#define DHCP_LOOP_COUNT_TIMEOUT 500
The main while() loop in dhcp_loop_configure() does a _delay_cycles(250000) if nothing else is happening, and it will time out after DHCP_LOOP_COUNT_TIMEOUT iterations.
The dhcp library has one simple function for the user to call:
int dhcp_loop_configure(uint8_t *); // Perform DHCP configuration, optionally reporting back DNS server
The uint8_t * pointer argument is a user-supplied buffer where 4 bytes will be written containing the first DNS server entry reported by the DHCP server; if this argument is NULL ( (uint8_t *)0x0000 ), the DNS server info will be ignored.
If this function returns -1 (0 = success, -1 = error), an extern global called "dhcplib_errno" may be analyzed to discover the cause; a function:
char *dhcp_strerror(int); // Return descriptive string of dhcplib_errno value
has been provided to interpret this, passing a "char *" casted pointer to a const char string declared inside dhcplib.c.
If dhcp_loop_configure returns successful (return value = 0), then your IP, subnetmask and gateway will be automatically configured in the WizNet's system registers.
Also, the code currently has socket #7 hardcoded as a #define in dhcplib.h