 |
NetBurner 3.5.7
PDF Version |
|
NetBurner 3.5.7
PDF Version |
Previously device configuration was accomplished with IPSetup, a windows based program. In 3.x there are a number of ways to configure the device that are independent of the host computer type. The primary method is through the device's own configuration web server. In this way the device can be configured by a web browser on any platform. There is also a serial interface configuration method.
discover.netburner.com. You will see a list of devices on your network. 
A sample JSON object is shown below:
If you were writing a web interface and need only the data under Ethernet in the tree, it can be accessed by: http://10.1.1.71:20034/UI.html?CONFIG/SYS/NETIF/Ethernet
To obtain just the IP address: http://10.1.1.71:20034/UI.html?CONFIG/SYS/NETIF/Ethernet/IPv4/ActiveAddr
The following examples are recommended to begin evaluating the platform. They are located in the \nburn\examples directory.
\Configuration\Web\BasicWebConfigOne of the features of NetBurner 3.0 is that each device is configured though its own configuration web interface. Data sent and received through the network interface has three options for security:
Each NetBurner device generates a default certificate and private key, which is stored in its internal flash memory, which can be used to secure the connection as a self-signed certificate. You can also use the device’s private key to create your own externally self-signed certificate, or have a certificate issued by a recognized third party. The externally signed certificate can then be installed by overwriting the device's default key.
Each device has a location to insert a shorting jumper to reset the module in the event of a catastrophic software problem, such as downloading an application image that corrupts flash memory or crashes. This recovery procedure will erase all of flash memory and download a recovery image. A new private key and certificate will then be generated. In such a case, any external self-signed or third party certificates will no longer be valid since the private key will have changed. A new certificate will have to be created from the new private key.
You will notice there is an Update Application on the web page. Application are now uploaded using the web interface. Alternatively, there is a windows executable that can be run from the command line in \nburn\pcbin\nbupdate.exe. Application images are now .bin files, they are no longer .s19 files. If building in NBEclipse the .bin file will be located in your workspace project's release folder. The format using nbupdate.exe is as follows: nbupdate <application .bin file> <device IP>
Summary of new and improved features:
-j to use multiple cores.
Improvements include:
IntializeStack(), GetDhcpIfNecessary, EnableAutoUpdate(), etc have been replaced with a single call: init() which is declared in the header file init.h. You will need to remove header files such as: ucos.h is now nbrtos.h. Any RTOS function calls that had UCOS in related names have been modified to reflect this.UCOS_ENTER_CRITICAL has been replaced with NBRTOS_ENTER_CRITICAL. The OSCritInit/Enter/Leave/... family has been deprecated in favor of OS_CRIT member functions. See RTOS Critical Sections for details.StartHTTP() function is now StartHttp() and StartHttps().WORD, DWORD, etc have been replaced with uint16_t, int16_t, uint32_t, int32_t, etc.extern const char pDHCPOfferName. It is now set by assigning a name to the configuration tree JSON object element: CONFIG:SYS:NETIF:Ethernet:DeviceName.EthernetIP() have been removed. Please refer to the ShowInterfaces example for methods to obtain runtime interface data.
In 2.x, three different mechanisms were commonly used to protect shared data: the UCOS_ENTER_CRITICAL / UCOS_EXIT_CRITICAL macros, the OSCritInit / OSCritEnter / OSCritLeave family of free functions operating on an OS_CRIT struct, and (less commonly) OSCritLockAndEnter / OSCritLeaveAndUnlock. All three have a 3.x equivalent, but they are not interchangeable with each other and should not be collapsed into a single mapping during porting.
UCOS_ENTER_CRITICAL() / UCOS_EXIT_CRITICAL() have been renamed to NBRTOS_ENTER_CRITICAL() / NBRTOS_EXIT_CRITICAL(). These remain interrupt-disable macros: they protect against both ISRs and task switches, must be very short-lived, and must not call any RTOS service or any function that could block. Use them only for brief, ISR-shared sequences such as a few register or shared-variable accesses.
NBRTOS_ENTER_CRITICAL is not a replacement for OSCritEnter. The two protect against different things (interrupts vs. other tasks). Replacing every OSCritEnter with NBRTOS_ENTER_CRITICAL will appear to work, but will disable interrupts for the full duration of the protected code, which can hurt interrupt latency or lead to deadlocks if the protected code calls any RTOS service.The OSCritInit / OSCritEnter / OSCritEnterNoWait / OSCritLeave / OSCritLockAndEnter / OSCritLeaveAndUnlock free functions have been marked [[deprecated]]. They have not been removed – each is still available as a thin inline wrapper that simply forwards to the corresponding OS_CRIT member function – but new and ported code should call the member functions directly. The change is purely a syntactic update from C-style free functions to C++ member functions; the underlying behavior is unchanged.
The mapping is:
OS_CRIT constructor calls Init() automatically (see nbrtos.h), so an explicit myCrit.Init(); is only required when re-initializing an object or when constructing in a context where the default constructor does not run.Both pairs claim the critical section so that no other task can enter it. The difference is what happens to the scheduler while the section is held:
Enter() / Leave() claim the critical section only. The owning task can still be preempted by higher-priority tasks. Other tasks that try to claim the same OS_CRIT will block until the owner calls Leave(). This is the right choice for the great majority of use cases, and is the direct equivalent of the 2.x OSCritEnter / OSCritLeave calls.LockAndEnter() / LeaveAndUnlock() claim the critical section and lock the scheduler. While the section is held, no task switch occurs at all – even higher-priority tasks will not run. Use this only when you need to guarantee that the protected sequence runs to completion against all other tasks (not only against tasks that share this OS_CRIT), and only for short sequences. This is the direct equivalent of the 2.x OSCritLockAndEnter / OSCritLeaveAndUnlock calls.NBRTOS_ENTER_CRITICAL() / NBRTOS_EXIT_CRITICAL() instead, or in addition.The two pairs must be matched: every Enter() requires a Leave(), and every LockAndEnter() requires a LeaveAndUnlock(). Do not mix them on the same claim.
3.x also provides OSCriticalSectionObj, a small RAII wrapper that calls Enter() in its constructor and Leave() in its destructor. This is not required for porting, but eliminates the risk of an unmatched Enter() / Leave() pair (for example, when an early return or exception skips the Leave() call):
A corresponding OSLockAndCritObj wrapper exists for the LockAndEnter() / LeaveAndUnlock() pair. See the \nburn\examples\RTOS\OSCrit example for a full demonstration.
Applicable Platforms:
MCF52xx platforms have a singe I2C peripheral, therefore the I2C driver API knew which signal pins to use and the set of functions to send/receive data only had to consider a single peripheral. ARM based platforms have many I2C peripherals, so a different type of driver/API is required. For example, with just a single I2C peripheral, an I2CSend() function is all that is needed. If there are many I2C peripherals, the driver must be able to send on any of them. This applies to all I2C functions: read, write, status, error detection, etc.
The most robust and scalable implementation is to use I2C peripheral C++ objects. You do not need to be a C++ programmer to use these objects in your application, other than to understand the format to call a member function of the object instead of a global C function call. For example, if in C you had a global function named GetI2CStatus(), it would now be a member function of a specific I2C object/peripheral and the call would be MyI2CObject.GetI2CStatus(). This method enables your application to handle multiple I2C peripherals, and the status function knows which peripheral to use because it operates on the object. Note that since the status function is called as a member function of the object, it is common to take that into consideration in the member function name, so it would likely be MyI2CObject.GetStatus().
In this way you can easily handle multiple I2C peripherals: MyI2CObject1, MyI2CObject2, MyI2CObject3, etc. Your application code does not need to manage and continuously check for which peripheral is being used, such as having a C style array of I2C peripherals.
The I2C driver for MCF52xx devices in the NNDK 2.x tools has the interface listed below. Note that there is a bit of C++ even in the old driver in terms of the function prototypes. You are likely calling some of these functions without any parameters, or with less than all the parameters listed. In C++ default parameters are specified in the function prototype with the '=' sign. So you can call I2CInit() with no parameters in your application, and the default parameters in the function prototype will be used.
The I2C implementation in the 3.x tools for ARM platform uses the I2CDevice Class. For example, on the MODM7AE70, an I2C object to select an I2C peripheral to interface with an EEPROM can be declared as (code taken from the I2C Pic Kit example):
The declaration of the I2CDevice creates an I2C object for I2C peripheral module 0 at the specified EEPROM I2C address. Creating the object also handles the initialization, so the equivalent of I2CInit() is not needed. Once we have created the object, all we need to do is call the member functions to control it in the format: EepromDevice.<member function>. For example, to send/write a single byte value of 0x60 to address 0x01 of the EEPROM: EepromDevice.writeReg8(0x01, 0x60);. Note that in ARM terms, the I2C addresses are referred to as registers. writeReg8() refers to 8-bits.
You will also note that the return values use the C++ operator "::". Whereas the 2.x driver returned an unsigned 8-bit value (BYTE), the 3.x driver returns a typed value of Result_t. Using typed values will result in more robust application code since the compiler can detect when a return value is used incorrectly. the "I2C::" result types are (be sure to view the latest information in the 3.x NetBurner API manual):
The corresponding functions to the MCF52xx I2CDevice driver are below. This is the recommended driver.
If you wish to have more manual control over the I2C transactions, you can create an I2C object instead of an I2CDevice object:
In NNDK 3.x there is also a third option. ARM refers to the I2C as a two-wire interface, or a wire interface in general. A WireIntf class is available for even more manual control. It was written for those familiar with Arduino drivers, but can be used for more detailed control in general. Please refer to the NNDK 3.x documentation for details.