sha2017-badge / firmware Goto Github PK

When flushing 3 times immediately after each other, the first flush will be instant, while the second 2 flushes will both take about 33 ticks.

Apparently flushing is somehow asynchronous. It would be neat if we could somehow detect the first flush is still in progress, and skip the second flush when the third flush comes in before the first flush has really finished.

Some files are no longer needed. Let's clean them up to avoid confusion.

Revert sleep (1) to sleep (calcultated time)
Make sleep wake on touch!

The vusb test in the initial bootloader is too low, as some laptops (eg Dell Inspiron 7537) are reported as vusb 5.501 or 5.506. Maybe increase to 5600 in the check

e.g. https://travis-ci.org/SHA2017-badge/Firmware/builds/236725156

make[1]: *** No rule to make target `/home/travis/build/SHA2017badge/Firmware/build/bootloader/bootloader.bin'.  Stop.

I want to build one badge on my own, but I would like to use St7735 based display. Ugfx has a driver for it. What should I do to make it work? Should I edit the files in components\ugfx-glue?

23:46:55 <@tsd> we can still optimize a lot of things
23:47:15 <@tsd> .. we currently have 4 deflaters, 3 crc32 checksum methods, 3 adler32 checksum methods, etc, etc..

Just fixed the mpr121 implementation, but probably want to check and fix the others as well.

Both in C Demo FW as in MicroPython ugfx.

I've currently commented out this code in badge_leds_disable() to work around the problem. Definitely not the best solution, but now the code still seems to work. (I assume that the port is successfuly configured as GPIO INPUT port, but I am not sure..)

// FIXME: freeing the HSPI seems to (de)configure the VSPI as well..
// ret = spi_bus_free(HSPI_HOST);
// assert( ret == ESP_OK );

(I have mention the issue in issue #59 and/or pull-request #62)

Woezel uses listdir . . probably easiest to rewrite that to use ilistdir

There's probably a bug in reading the gpio from the mpr121. The sdcard is not detected.

The MPR121_PIN_NUM_CHRGSTAT might also have the same issue.

It would be really nice with build in support for both types of LEDs. They seem to be able to be combined on one length of string, so you could - in theory - extend the onboard 6 RGBW LEDs with some RGB LEDs after that.

Example at https://github.com/sonyhome/FAB_LED#soldering-ws2812b--sk6812-rgbw

Should detect a badge being connected to one of the USB ports and flash it.

Should support flashing multiple badges in parallel.

The Voltage of the battery is measured and displayed with an offset of +0.4V (values from multimeter: 3.8V badge: 4,2V). Therefore the battery indicator also shows a wrong status for the battery.

Only used one (my) badge for testing

Currently, all file-handles are already created when we open the file-system.

By changing the FATFS structure, we can use pointer to FIL entries instead of FIL entries themselves.

So you know when your battery is safe

It might break 📟

content: (or something like this)

badge.vibrator_init()
badge.vibrator_activate(325)

The authenticated message layer (ed25519) does not provide a proper secure channel. In particular, replay protection is left to the sequence numbering at the FEC layer. These sequence numbers, however, reset with the special "serial=0" packet which is used to change encoding parameters. This allows an attacker to replay older packets and confuse the update process in various ways.

For example, it implies that an erasure code is used on something that is not an erasure channel (where bits are only detectably dropped). Without further authentication, this allows an attacker to corrupt the firmware image during download by injecting an earlier packet with an appropriate sequence number.

In addition, since the code accepts any packet with a sequence number greater than the last, replaying an old high-numbered packet allows an attacker to cheaply block out the following legitimate packets.

Relatedly, a missed "serial=0" packet will leave a client decoder in a confused state until another "serial=0" is received.

https://github.com/SHA2017-badge/Firmware/blob/master/components/ugfx/build_fonts.sh

I'm trying to install badge emulator on OS X 10.11.6 using instruction from https://wiki.sha2017.org/w/Projects:Badge/Emulator#macOS and getting these errors:

../../ugfx/src/gos/gos_linux.c:108:16: error: use of undeclared identifier 'CLOCK_MONOTONIC'
        clock_gettime(CLOCK_MONOTONIC, &ts);
                      ^
../../ugfx/src/gos/gos_linux.c:211:20: error: use of undeclared identifier 'CLOCK_REALTIME'
                                        clock_gettime(CLOCK_REALTIME, &tm);

It seems like the Emulator is missing Librarys. I tried to run my App, and it complains about the missing wifi module(using the network module seems to work though), and dialogs module.

• bd_ropart.c
• bd_emu.c
• blkidcache_mlvl.c
• blkidcache_noop.c
• defec_parity.c
• hldemux.c
• partemu.c
• ...

In this post you are mentioning

Featuring a brand new distribution technique designed by Sprite_TM, we can update badges without associating to the WiFi access points.

Can you describe with technical details what is meant here?

(to support scrolling over large pngs)

the line

  ptr = memchr(text + i, '\n', total_len);

will access memory after the text buffer as i is incremented but
total_len stays constant. the loop will only terminate when it hits an area
of memory of size total_len that incidentally contains no newline.

This is about the installer for the Hatchery.

For long app titles, two lines of text are rendered, but subsequently put in a one line high slot in the table of apps, showing half of each line.

For instance, category Utility contains on its first page the app "AltPWRLaptopCharger".

Power: Ref 4015c664 (wifiMonTask:402): can sleep for 300000 ms
Sleeping for 292000 ms.

For using extmod/uhashlib you need axtls for the sha1

I tried using the mbedtls/moduhashlib on unix which resulted in weird hashes!!

The toolchain from the xtensa-esp32-elf repository is for Linux only.

If you want to build on a mac, do the following:

• download the mac toolchain from this page

• rename the linux toolchain: mv xtensa-esp32-elf xtensa-esp32-elf-linux

• untar the mac toolchain: tar zxf ~/Downloads/xtensa-esp32-elf-osx-1.22.0-61-gab8375a-5.2.0.tar.gz

• install the CP2102 usbserial driver

• then in the sdkconfig file change this line:
  CONFIG_ESPTOOLPY_PORT="/dev/tty.SLAB_USBtoUART"

Free up more 8-bit addressable memory.

Experimental, untested byte getter and setter methods:

uint8_t
u32_get_byte(uint8_t *ptr)
{
    intptr_t _ptr = (intptr_t) ptr;
    uint32_t *ptr_u32 = (uint32_t *) (_ptr & ~3);
    return (*ptr_u32 >> ((_ptr & 3) << 3)) & 0xff
}

void
u32_set_byte(uint8_t *ptr, uint8_t value)
{
    intptr_t _ptr = (intptr_t) ptr;
    uint32_t *ptr_u32 = (uint32_t *) (_ptr & ~3);
    uint32_t u32 = *ptr_u32;
    u32 &= ~( 0xff << ((_ptr & 3) << 3) );
    u32 |= value << ((_ptr & 3) << 3);
    *ptr_u32 = u32;
}   

if defecInit is called after defecRecv processed a parameter packet
(serial=0) that specifies an invalid decoder algorithm, the parameters are
already in savedStatus so a subsequent defecInit will attempt to restore
the decoder but yield NULL, leading to a crash in

      currDecoder->init(currK, currN, maxLen);

this can happen if an invalid parameter packet is received before the system
enters deep sleep (-> defecInit after wakeup).

likewise, if the decoder parameters (k/n) are invalid, the unchecked call above will fail and subsequent decoder calls will access uninitialized memory or reuse stale values.

Would be nice to have an option to use the badge to control PL9823 LED's, which are quite similar to the WS2812

Currently stores in config.json via https://github.com/SHA2017-badge/micropython-esp32/blob/master/esp32/modules/database.py
Currently only stores name in https://badge.sha2017.org/files/521

Want to use NVS http://esp-idf.readthedocs.io/en/latest/api-reference/storage/nvs_flash.html

Current idea:

Start with 2 Namespaces badge and user

user will store name (and later more personal settings)

badge will store wifi.ssid, wifi.password and possibly type (like WPA2 ent etc)
badge can store mpr121.base.0 .. mpr121.base.7 too

TODO

• badge_nvs component
• move nvs_flash_init() to central badge_nvs_init() routine
• include badge_nvs_init() in badge_init() (before configurable things like badge_mpr121_init())
• micropython hooks for using it from there

Current order:

• enable power to sdcard
• mount sdcard with esp_vfs_fat_sdmmc_mount()
• read/write files
• unmount sdcard with esp_vfs_fat_sdmmc_unmount()
• disable power to sdcard

When doing a 2nd mount (power-on, mount, unmount, power-off, power-on, mount), the initialization fails with a timeout. It sounds like I have to initialize something extra.

Why is there no SDCard Support?

import machine, sdcard, os
Traceback (most recent call last):
File "", line 1, in
ImportError: no module named 'sdcard'

Mentioned in #206

The discussion is still valid, but wanted to merge the pull-request.

I think there should be a auto return to home if someone forgets his/hers/something badge in a battery consuming state and does not give any inputs for a couple of minutes

There are multiple badges that run Micropython like the Tilda Mk. Pi and the SHA2017 badge. Since Micropython seems to work well enough to have the potential to be used in many more camp badges I propose that we define an API which would allow apps to work on all current and future Micropython based badges.

Another thing is the appstore. I think we've got that working great using Woezel. Backporting woezel to the Tilda Mk. Pi badge seems like a great way to improve that badge.

Also API calls to interact with for example LEDs, speakers, buzzers and buttons could be defined in such a way that an app would not have to be changed to work on different hardware.

Last thing: maybe it's an idea to create a sort-of descriptor so that an app (and the appstore) knows if certain hw features are available?

It would be real nice with a way to disable sleep for the badge with a call from python, or somehow to ask the badge to wake up and trigger an event after a set time.

Something like:

badge.disable_sleep()
badge.wakeup_after(xxx) where xxx is a millisecond delay

Simply following the instructions on the wiki in a fresh environment yields:

root@Junix-laptop:~/sha2017/Firmware/micropython/unix# make
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
mkdir -p build/genhdr
Generating build/genhdr/mpversion.h
GEN build/genhdr/qstr.i.last
In file included from ../py/../extmod/modussl_mbedtls.c:36:0:
./esp_log.h:8:23: fatal error: sdkconfig.h: No such file or directory
#include "sdkconfig.h"
                      ^
compilation terminated.
In file included from esp_log.c:5:0:
esp_log.h:8:23: fatal error: sdkconfig.h: No such file or directory
#include "sdkconfig.h"
                      ^
compilation terminated.
../py/mkrules.mk:73: recipe for target 'build/genhdr/qstr.i.last' failed
make: *** [build/genhdr/qstr.i.last] Error 1
make: *** Deleting file 'build/genhdr/qstr.i.last'

Hi,

I am wondering if anybody succeeded using the SHA2017-badge/Firmware running on badge Rev1.0.* with the recent esp-idf (ESP-IDF Pre-release 3.0-rc1 as of today) and the updated toolchain (1.22.0-75-gbaf03c2-5.2.0).

To make the compilation complete I had to change WIFI_COUNTRY_EU to WIFI_COUNTRY_POLICY_AUTO in badge_first_run.c

Unfortunately the display does not work. The touch pad works. Setting Enable eink debug messages in menuconfig does not bring additional information:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:4468
load:0x40078000,len:0
load:0x40078000,len:12976
entry 0x40078d88
D (157) badge_eink_dev: init called
D (157) badge_eink_dev: init done
badge_eink_dev: EPD-Busy Int up
Button START handling
Selected 'mpr121 touch demo'

Do you have any ideas where to look for possible issues with operation the the display?

My badge works without any issues loaded back with original firmware. Congratulations on building this impressive project complete with the hardware!

It would be nice if the badge stayed awake when connected to an external power source. It is a bit of a hassle trying to develop apps and upload to test when the badge falls asleep.

the line

  strncpy(dest, text + i, len);

would copy an HTTP response line of arbitrary length into the fixed-size buffer dest if it weren't for the saving fact that the text buffer is of the same size as dest. the length argument to strncpy should be the size of dest.

similarly in line 195:

  strncpy(dest, dest + 16, len - 17);

in addition, the behavior of strncpy is undefined for overlapping arguments.