![](/media/cache/profiles/37f5bdb3a2a1159584d0a30e9a1e71bf.jpg.50x50_q85.jpg)
Send the data of GR-PEACH_HVC-P2_sample to the cloud.
Dependencies: AsciiFont GR-PEACH_video GraphicsFramework LCD_shield_config R_BSP USBHost_custom easy-connect-gr-peach
Fork of mbed-os-example-client by
Note at the time of sample import
Please not check the "Update all libraries to the latest version" at the time of import.
Warning!
When exporting and using it, increase the following stack size.
mbed-os/features/FEATURE_LWIP/lwip-interface/lwipopts.h
#define TCPIP_THREAD_STACKSIZE 1024 -> #define TCPIP_THREAD_STACKSIZE 2048
Overview
This is a sample to send the analysis result of GR-PEACH_HVC-P2_sample to the cloud using mbed-client. Please refer to following for operation of HVC-P2.
Import programGR-PEACH_HVC-P2_sample
Sample to operate omron HVC-P2 on GR-PEACH.
Required hardware
- GR-PEACH ( https://developer.mbed.org/platforms/Renesas-GR-PEACH/ )
- HVC-P2( https://developer.mbed.org/teams/Renesas/code/GR-PEACH_HVC-P2_sample/ )
- LCD Shield ( https://developer.mbed.org/teams/Renesas/wiki/LCD-shield )
- BP3595 ( https://developer.mbed.org/components/BP3595-for-GR-PEACH/ )
- Ethernet cable and connection to the internet
Application setup
Client credentials
To register the application to mbed Device Connector, you need to create and set the client side certificate.
- Go to https://connector.mbed.com/ and log in with your mbed account
- On mbed Device Connector, go to https://connector.mbed.com/#credentials and click the Get my device security credentials button to get new credentials for your device.
- Replace the contents in security.h of this example with content copied above.
Ethernet settings
This sample uses Ethernet as the default connection type. To change the connection type, set WIFI_BP3595 in mbed_app.json:
mbed_app.json
"network-interface":{ "help": "Options are ETHERNET, WIFI_ESP8266, WIFI_BP3595", "value": "ETHERNET" },
To specify MAC address, add fllowing function to main.cpp. (When using Wifi, setting of MAC address is not necessary.)
Specify MAC address
// set mac address void mbed_mac_address(char *mac) { mac[0] = 0x00; mac[1] = 0x02; mac[2] = 0xF7; mac[3] = 0xF0; mac[4] = 0x00; mac[5] = 0x00; }
Wifi settings
This example can use BP3595 Wifi Interface for managing the wireless connectivity. To run this example using Wifi, you need:
- A BP3595 Wifi module ( https://developer.mbed.org/components/BP3595-for-GR-PEACH/ )
- Mount BP3595 onto GR-PEACH
- Close GR-PEACH's JP21 (https://developer.mbed.org/teams/Renesas/wiki/Jumper-settings-of-GR-PEACH)
- In the mbed_app.json file, change
mbed_app.json
"network-interface":{ "help": "Options are ETHERNET, WIFI_ESP8266, WIFI_BP3595", "value": "WIFI_BP3595" },
Provide your Wifi SSID and password here and leave \" in the beginning and end of your SSID and password as shown in the example below:
mbed_app.json
"wifi-ssid": { "help": "WiFi SSID", "value": "\"SSID\"" }, "wifi-password": { "help": "WIFI Password", "value": "\"Password\"" }
Specify the security type for connection to be used. When the security type is WPA2, you need to specify
NSAPI_SECURITY_WAP as follows:
mbed_app.json
"wifi-security":{ "help": "Options are NSAPI_SECURITY_WEP, NSAPI_SECURITY_WPA, NSAPI_SECURITY_WPA2, NSAPI_SECURITY_WPA_WPA2", "value": "NSAPI_SECURITY_WEP" },
By default, NSAPI_SECURITY_WPA_WPA2 is specified here.
Application resources
This example exposes four resources listed below:
- 3202/0/5700. Recognition result from HVC-P2 (GET).
- 3201/0/5850. Blink function, blinks LED when executed (POST).
- 3201/0/5853. Blink pattern, used by the blink function to determine how to blink. In the format of 1000:500:1000:500:1000:500 (PUT).
- 3201/0/5855. Blink color, used by the blink function. Any of red, green, blue, cyan, yellow and magenta is acceptable (PUT).
For more info on how to get notifications when resource 1 changes, or how to use resource 2, 3 and 4, please look at
Import programGR-PEACH_mbed-connector-ZXingSample-node
Node.js based Web Application for mbed Device Connector specific to GR-PEACH_mbed-os-client-ZXingSample
# This is a Web Application for GR-PEACH_mbed-os-client-ZXingSample, but it can also be used for this sample.
Diff: README.md
- Revision:
- 12:7da135488950
- Parent:
- 9:dcc4b552c03a
- Child:
- 13:c44e318674db
--- a/README.md Wed Aug 03 13:15:15 2016 +0100 +++ b/README.md Thu Aug 04 18:15:18 2016 +0100 @@ -275,15 +275,24 @@ For information on how to get notifications when resource 1 changes, or how to use resources 2 and 3, take a look at the [mbed Device Connector Quick Start](https://github.com/ARMmbed/mbed-connector-api-node-quickstart). +## Important Note (Multi-platform support) -## Known Issues +mbed-OS provides the developer with total control of the device. However some defaults are always loaded if the user does not provide proper information regarding them. This becomes evident when a user switches among platforms. On some platforms a particular pin might be reserved for a particular functionality (depending upon the MCU) which thus cannot be used generally. A good example of such phenomenon is the use of atmel-rf-sheild with [Nucleo F401RE platform](https://developer.mbed.org/platforms/ST-Nucleo-F401RE/). +If user do not provide particular pin configuration for the atmel-rf-driver (sometimes a desired behaviour) the driver falls back to a default Arduino form factor, see [atmel-rf-driver pin assignment](https://github.com/ARMmbed/atmel-rf-driver/blob/master/source/driverAtmelRFInterface.h). This fallback mechanism works on most of the platforms, however in the above mentioned case, there is a catch. Fall back mechanism sets the GPIO pin D5 as a designated Reset pin for SPI (SPI_RST) in the radio driver. Whereas this particular pin is assigned by the MCU to debugging in Nucleo F401RE. This will result in hard fault ofcourse. The solution is to map the conflicting pins to a free GPIO pin. For example, the user can add *"atmel-rf.spi-rst": "D4"* to his/her mbed_app.json file. This will set the SPI_RST pin to D4 of the GPIO. -If you are using MESH_THREAD as the network interface, once your client device joins the Thread Border Router and you hard reset the client device using reset button, the client device will not be able to join the network again and you will see a warning: - -``` -[WARN][mleS]: dropping packet because mle frame counter is not higher +```json +{ + "target_overrides": { + "*": { + "target.features_add": ["IPV6", "COMMON_PAL"], + "atmel-rf.spi-rst": "D4" + } + } +} ``` -Border router will start dropping packets because of MLE frame counter mismatch. For more information about MLE frame counter feature see the [MLE-05 RFC](https://tools.ietf.org/id/draft-kelsey-intarea-mesh-link-establishment-05.html#rfc.section.7.6). -After 240 seconds, the default link timeout triggers the Border router to unregister the lost end device and the BR drops all the counters for that particular device. -Now your should should be able to join the network again. +Desired work flow in such situations (if it may arise) should be: + +1. Checking the platform pinmap from [mbed Platforms](https://developer.mbed.org/platforms/). +2. Making sure that the desired GPIO pin is free by looking at the data sheet of the particular MCU. Most of the data sheets are available on [mbed Platforms](https://developer.mbed.org/platforms/). +3. If necessary, change the pin or pins by using the mbed-OS config mechanism. You can get more informations about the configuration system in the [documentation](https://github.com/ARMmbed/mbed-os/blob/master/docs/config_system.md) \ No newline at end of file