Before going into the GUI as boot we should show the logo or something

(from irc admin channel we also need easter egg win95 logo aswell)

This should be the default app to run on the GUI
It's main function will be menu list to launch other apps

It could also show useful info like time, battery if we don't have them shown in every screen.

After any other app exits we go back to this one.
A long press of the BUTTON_CLICK should always return to this.

Related to emfcamp/Schedule#7

The wiki says: "For now, the code waits for a key on the usbserial debug before doing anything, open the serial monitor in Arduino, set the line endings to ‘Newline’ and press enter."

Before I did this, the device had already rebooted after the firmware was reflashed; after I did this, nothing seemed to happen. Is this last step in fact still necessary, or can it be removed from the wiki?

Forces badge to stay in Discover mode and displays all nearby GWs and their RSSI. Not important for EMF itself, but could potentially be really useful during setup.

Responsible from showing a radio notification text up on screen.

Allow user to set an avatar that is displayed on the 'front screen' with their name.

Set on a website maybe? That way the processing to something badge compatible can be done off-badge.

This is important if we want people to write their own tasks that can live alongside our code.

• How to set up the Arduino IDE
• How to do a flash with the current code
• How to use the debug serial console
• A simple blink task that can be started/stopped as an example
• A quick overview over what will work and what won't (e.g. don't use serial or digital write directly, use one of our wrappers.)
• Document all our wrappers
  • Buttons (how to be notified of button pushes?)
  • LEDs
  • Data (schedule, weather, ....)
  • Debug stuff (logging, etc...)
  • Display
  • Flash storage
  • Radio (if we even expose that)

Mange the two RGB LEDs
Mostly port in the stuff from frRGB.ino

Radios on the badge have sleep mode (ATSM2) set by default.

We need todo some tests around this as we need to make sure when putting the radio to sleep we give it enough time to send the last outgoing message.
In arduino terms
Serial.print(PACKET);
Serial.flush();
delay(XXX);
pinMode(SRF_SLEEP, INPUT);
We should test this to see how long XXX needs to be for our packet to be sent.

There also needs to be a delay after waking the radio before we can send it a packet to it, again in arduino terms
pinMode(SRF_SLEEP, OUTPUT);
delay(XXX);
Serial.print(packet);
I've used a delay of 400 before but would like us to test see if we can get it lower

In RTOS we would of course use vTaskDelay

Expose external flash as a mass storage device over USB, and allow writing/deleting of files. Use FAT for universal support, and allow special-cased files like config.txt or firmware.img. Possibly expose RAM as an overlay, and current firmware/config as read-only FS? Deal sensibly with erase.

Should be simple just show the badge short ID and possible the register link
And an exit button

List of all the sponsor

The various libraries we are using have a range of licenses, some of these require license information to be made available, this is usually expected to be within the application. We should have a task that displays the required license text.

As a fallback we should print them on a leaflet to go with the badge, but this is a definite second option.

I've seen several people having trouble with this. I don't know if they flash the TX LED because they are transmitting or because they detected a fault, but they all blink it.

Piezo sounder has two possible uses.
First is simple notification beeps that might be triggered by an app or incoming radio notification.

Second is playback of simple tunes

Piezo is on a DAC pin which we suspect might not work, so either use software PWM or redirect the hardware PWMH3 pin from LED1_BLUE

Should investigate rapid DAC changes using DMA/PDC xfer to emulate PWM

Handle time sync messages and time to display on the gui

I think we can break down the badge firmware into the following RTOS Tasks, I've tried to give a quick summary of what I think each task might cover

• TiLDA
  • Main application logic and director thread, takes input from everywhere and triggers everything else (might not be needed)
• GUI/Display
  • Responsible for managing the frame buffer, drawing the widgets, flipping it based on IMU and calling EPD to ask for a full or partial update
• IMU
  • Setup IMU on power up, manage IMU interrupts and updating global available orientation data. Configure IMU in and out of sleep states
• Radio
  • Handle all radio traffic and protocol exchanges, update state as required, (may trigger screen update)
• Buttons
  • React to user interaction, from joystick, A&B, left & right context, light buttons. (may trigger screen update, start IR, change RGB State, )
• RGB
  • manage PWM out put to RGB LED's including torch mode
• PMIC
  • Look after PMIC lines states, charging, monitor battery level and OTG voltage generation (if not don't by USB host drivers)
• Flash
  • deal with reading and writing to flash chip, work with config area, file system
• USB
  • handle USB serial and MSD tasks
• IR
  • send and receive IR data
• Sound
  • Sound play back from buffer or sound track
• Sleep
  • This is likely to be done via the IDLE hook, managed going into and out of the various levels of sleep states Sleep mode, Wait mode, Backup mode. Including saving config and state information, hibernation file before entering backup mode

Possible FreeRTOS compatible HAL drivers needed to support our firmware
some of these we might be ok just to use the Arduino API versions

• Gpio
• ADC
• SPI
• I2C
• Serial
• PWM
• USB Device Stack
  • CDC Serial
  • MSD

Using the schedule info from the flash store, load and display the schedule

If we get time ability to select/show notification request on items

If we can implement a dual press function on light this can be a task other wise it will have to be app based

Basic need is to TX the badges short ID
Possible extension would be ID plus some key
Send should be repeated for X time

(Need to file a redmine issue to cover RX on based stations using a few spare badges modified up with IR_RX part also need an issue for separate IR RX firmware)

The way it currently looks we will a few different types of infrastructure software. They need to be written. I would advocate HTTPs for all communication channels.

DK/base station services

There will be various base stations for the radios around the camp site. These will be basically raspberry pi's with at least two srf usb sticks. I would like them to be as simple as possible, being basically stateless and just asking the main service what to send next and passing received messages on. Since they might be in less-secure locations I wouldn't want them to do any signing of messages.

Tasks:

• Broadcast channel id in random intervals on a discovery channel. Badges will listen to that discover channel and pick the strongest signal to connect to.
• Ask the main service for new content to send on the main channel. Sometime the DK might be told to remain silent
• Forward any messages received to the main service

Main service

This services will be hosted on a vm somewhere. It's coordinating which DK is sending what data at which time.

Task:

• Keep track of which badges are connected to which DK
• Schedule send/receive windows
• Keep track of messages that need to be sent to badges and whether or not an ACK has been received yet
• Tell DK what messages to send (this can be a direct message to a badge, content updates, broadcasts like the current time or a nop message)
• Forward messages to backend services

Content update services

Regularly update the content like weather forecast, schedules, etc. I guess a good place to store those is in a DB table.

Backend services

Small tasks like "badge id negotiation service" or "talk notification service". If we get super fancy we could allow others to plug their own services in.

Dedicate part of the flash to storing keys, user prefs, schedule, etc. Only erase when necessary. There's probably a load of libraries for this.

It's only a minor update

Main application logic and director thread, takes input from everywhere and triggers everything else, a lot of this will be handling radio message content.
So things like verified radio massages would be passed this to be processed.
Task should generate outgoing messages other than basic ACK's that might be handled by radio task

Incoming notification would trigger notification app
Schedule updates would be sorted and passed to flash to store
Metrics request reply would be generated here
Other outing message like possible voting system and high scores should come form the app back to this task.
Passing updated clue for the treasure hunt app

Just trying the HelloWorldApp as part of the getting started on the wiki and it garbles and/or blanks the display after flashing up something momentarily. The task is running OK (the LEDs work from buttons). I see that in the wiki there is mention of a move to make calls to GUITask rather than GLCD. Is that the case? I shall try it next but I'm putting this up to assist other starters like myself.

To allow rapid deployment and eventually OTA patches. If based on #3, something needs to trigger a file going to RAM instead of flash.

At 2012 there was a sign on the front of each DK with a number for NOC you could text and asks for a power/net connection to be done.

If we could do it with the badge it would be an App with list of DK's which you select then have either connect or disconnect option.

Message gets sent back to NOC who dispatch someone as needed.

Radio task should handle message interactions with the master TX and DK, including scheduling of periodic wake's, packet format, multiple packet messages, signing, channel hoping.

Brightness via the LCD_BACKLIGHT PWM pin and contrast via one of the GLCD functions

Manage the IMU power states, full DMP or accell only.
Periodically read IMU and update globals with information for orientation and movement
Investigate pedometer
Possible callback functions register for orientation data, e.g. orientation changes we should let gui task know it needs to re render screen, if it's displaying anything

Found this section in the docs that might be usefull for writing data to flash

• 22.4.4 In Application Programming (IAP) Feature

also there is this

https://github.com/cmaglie/Flash

Monitor battery voltage
Monitor charge status
Pass information to GUI
Possible take action for low battery

Get basic read and write working of DMA SPI
write is 4k, so use the NAND fifo for a buffer

Allocate some space for config storage, schedule storage and other
Provide a possible gloat config object for other task/apps to read write from ram, written out to flash periodically or on request.
Schedule updates should be written to flash as received over radio.

Other space for images, sounds, user apps, time permitting.

feature request: For next time could we have the badge firmware version somewhere nice and obvious on the main menu -it'd make it slightly easier to diagnose which firmware has what issues as well as making it obvious to people if they're running the latest or not.

Setup buttons with Debounce and interrupts

Provide a way of notifying current running app of button press's
Pass on light directly
Longer Debounce for the home button to switch app back to home screen

Possible override Arduino core attach Interrupt functions

It won't work without the correct infrastructure anyway and EMF has proven that even the correct infrastructure won't get it very far ;)

Whoever picks this up can decide what's going to happen :)

Not sure if there are any changes but will take a look anyway.

When exiting the snake or tetris apps, the first joystick action malfunctions.

To reproduce:

• Reset your badge
• Enter the snake app
• Move around a bit
• Hold the joystick center to quit the app
• At the homescreen, hit up on the joystick

This should move up one item on the homescreen menu but instead loads a different app. The same happens with the tetris app, but not with the sponsors app.

The idle task should be use to mange house keeping that has no set run point and management of what level sleep sates we can enter in order to try and save battery power

I need to re read some FreeRTOS stuff before I spec this more.

SAM3X has three sates we can drop into
WFE, WFI And Deep sleep
WFE and WFI are common and drop things to a set low level
Deep sleep will be for at night and wake from it is like a reset.

Should possible manage /adjust
IMU modes
radio wake period

Get the screen drive correctly display text passed to it from other tasks