#Flipper alarm

80 messages · Page 1 of 1 (latest)

strong gorge
#

I am attempting to make a flipper alarm that uses the alert feture with the clock

import time
import pygame
import pyvib

def zero_flipper(num):
  # Convert the input number to a string and split it into a list of digits
  digits = [int(d) for d in str(num)]
  
  # Flip all of the 0s to 1s
  flipped_digits = [d if d != 0 else 1 for d in digits]
  
  # Join the digits back together and return the result as an integer
  return int("".join(map(str, flipped_digits)))

def set_alarm(hour, minute):
  # Calculate the number of seconds until the alarm time
  current_time = time.localtime()
  alarm_time = time.mktime((current_time.tm_year, current_time.tm_mon, current_time.tm_mday, hour, minute, 0, 0, 0, 0))
  time_difference = alarm_time - time.time()
  
  # Sleep for the specified number of seconds
  time.sleep(time_difference)
  
  # Start the sound and vibration
  sound.play()
  pyvib.vibrate(5000)
  
  # Wait for the sound and vibration to finish
  time.sleep(5)
  
  # Stop the sound and vibration
  sound.stop()
  pyvib.stop()
  
  # Flip the digits in the alarm time
  flipped_time = zero_flipper(alarm_time)
  print(f"The zero flipper alarm went off at {flipped_time}.")

# Initialize pygame and pyvib
pygame.init()
pyvib.init()

# Load the sound file
sound = pygame.mixer.Sound("alarm.wav")

# Set the alarm for 10:00 AM
set_alarm(10, 0)

this is what i have so far
not sure what to do from here

weak pagoda
barren flicker
#

you can interact with the flipper over a serial port

#

so you can actually do stuff in flipper, from python

#

the catch is that FZ must be connected over usb to something that runs python

#

that can also be a phone running termux for example

weak pagoda
#

Yes

subtle dagger
weak pagoda
subtle dagger
weak pagoda
subtle dagger
#

I don't mind C and C++, but I feel like the natural audience for this device uses python already for most of their tasks.

#

like I said I am sure I am missing something here, some python shortcomings that the team saw wisdom in heading another direction.

barren flicker
#

this is basically a STM32 with FreeRTOS and some userspace code thrown at it

#

you can _

#

prooobably run micropython on it, eventually

#

but you're not gonna get anything like pygame on micropython

subtle dagger
barren flicker
#

it is neither compiled, nor does it let you do pointer magic

#

that, in my books, is low level

#

let's call them what they are, interpreted or JIT

#

JIT code takes significantly more resources to run than just precompiled stuff

#

the problem (and let's call it, the reason) is that a lot of the stuff flipper does needs a RTOS and microsecond timing

#

like for example, the LFRFID, the 125khz loop is done entirely in software

#

you're not gonna pull 8us accuracy from a JIT language

#

some other stuff to, like the screen refresh or parsing CC11xx buffers also needs pretty precise timing

#

it might get python eventually (and I hope so, too)

#

but the low level stuff will need to be done in C anyway

#

I tend to think of this as "I'm happy I bought it now when the software side is incomplete and limited, than 5 years later when it runs micropython and some other cool toys nicely"

weak pagoda
#

Not as high level as scratch, but high level

weak pagoda
#

Possibly in a new device, maybe, but currently no

#

They can't even run full BT radio stack, and its only lite

#

So if they somehow break down the stacks, it's either microPython or custom full BT radio stack

#

Latter is better cause more functionality

#

Former only simplifies existing functionality

#

I rather learn a lower level language than lose out on functionality imo

#

Since C/C++ are easy enough to learn

#

I'm coming from a background in Python/JS

barren flicker
#

I wouldn't say scratch is high level, it just compiles so visuals into code you can't access, and has some nice libs

#

python has amazing libs too, like scipy, which you will never be able to use on FZ

#

micropython can and probably will fit in a STM32WB55, remember, micropython was originally devved for F103 (bluepill)

#

F103, compared to WB55: 64K flash, 20K ram, 72Mhz vs 1MB of flash, 256k of ram but 64MHz

#

the problem is: do you want it as a baremetal app that outputs to the hardware tx/rx pins? that's how micropython is used, in a REPL prompt over serial

#

do you also want to redevelop drivers for every hardware flipper has?

#

or do you want it as a nice, high level integration as a .fap that can run arbitrary scripts and interact with FZ hardware through its native (furi_lib_*) drivers

#

if your answer is the second choice, you need significant developer time to port micropython to the FZ environment

#

you can probably compile a vanilla micropython and it will run off the STM32 usart just fine

#

i'll put a beer on that

#

you will just have to replace flipper zero software with your newly compiled micropython software

#

as for the BT stack - WB55 is special in the land of STM32

#

it has a separate processor (perhaps you've seen references to copro in the code, that's a coprocessor) which does exclusively 2.4GHz stuff.

#

it doesn't take space from the main processor, where flipper firmware is installed, nor ram, nor anything. it's literally another device, dedicated just for this

#

a full (4.0, pre BLE) is extremely heavy. you used to have dedicated chips to run one of these babies, and each chip had its own set of quirks, to interact with other chips

#

that's why BLE came up (beyond low energy requirements) to unify and allow arbitrary data communication without such a heavy set of specs

#

there's no maker-accessible embedded hardware in the world that can run a full BT, non BLE stack

#

you do that on a computer, like your pc or pi

#

as for C/C++, first advice is to stop calling them that, they are not the same and behave quite differently. you either do one, or the other

#

and my advice is to either learn one or the other, not both, and especially not at the same time

#

for FZ i'd really suggest against C++, since everything is written in C

#

i've been on and off as an embedded dev for about half my life, and can proudly say I still don't fully know C, and still find surprising stuff and odd behaviours

#

you should be afraid of C, honestly, and approach cautiously, and embrace the fuckup. C changes every few years now, since 2011 they've been quite a few iterations. don't do anything but C99 until you can handle fancy pointer arithmetic and pointers to pointers to random stuff without causing memory leaks or segfaults

#

I still am, honestly, heh

#

and once you get into threading, things start to get really fun. at that point you should have a very firm grasp on OOP design patterns (like producer-consumer) since you'll need to implement them in a non-OOP way

#

for example, if one thread free()s a pointer and expects to exit cleanly, but it gets interrupted by another thread which uses that pointer (which is now NULL) you will crash FZ, get a null_pointer_dereference error and that's about it as far as debugging goes.

#

python saves you a lot of these headaches by not letting you use pointers, and discouraging threads in favor of smp or async/await

#

and js (the frontend stuff anyway) doesn't even care about threads, and has bg workers and async/await everywhere

#

you will not get such luxuries easiily

#

</rant>

upbeat bronze
upbeat bronze
#

btw @barren flicker u know that python is written in C lmao 💀💀

barren flicker
#

all I'm saying is that if you know python, once you go to C, you need to take care of many more things you were probably unaware in python and took for granted

#

and yes, python has a ton of C bindings, and can also be embedded as an interpreter in your C programs

#

still waiting for decent threading ha

weak pagoda
vast wing
strong gorge
#

I live!

#

I am a noob on this stuff but there is a clock that exists in the flipper and an alarm already that you have to activate manually. maybe we get the two app codes and combine them:)