Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idee #71

Closed
f1ixx opened this issue Mar 20, 2024 · 5 comments
Closed

Idee #71

f1ixx opened this issue Mar 20, 2024 · 5 comments

Comments

@f1ixx
Copy link

f1ixx commented Mar 20, 2024

Bonjour

Je ne sais pas ou poster et ne veux pas surcharger votre mail.
Pour gagne quelques bytes, j'ai modifier ca dans ma version F4HWN :
1-Ca compile pas directement. Ca deborde de 380 bytes.
Desactive le VOX (je m'en sers jamais)
Ca compile et j'ai 391 bytes de libre.

2-Comme dit dans une video, la version est, pour ma part, celle de Armel F4HWN.
J'ai donc supprime les references d'origine (Egzumer v.0.22).
Modif dans : welcom.c et .h et version.c et .h
et dans le Makefile (forcement)
Je compile et j'ai 459 bytes de libre.

3-La "lampe". Alors perso, ON/OFF suffit amplement et encore. Ca bouffe
de la batterie qui n'est pas formidable. Mais je garde juste ON/OFF.
Modif dans : app/flashlight.c et .h et app/app.c
Je compile et j'ai 671 bytes de libre.

Alors je sais pas si le calcule d'octets "sauver" est correct et sera identique pour vous et surtout
si ce genre d'idee est la bonne voie.

Et oui je valide la perte de la FM-Radio, on a le baofeng pour ca ;-).
Avec l'UV-K5, on discute.

Si pas bonne idee, archivez/effacez/ou_autre cette issue. Merci

Encore un grand MERCI pour votre travaille et les avancements de ce Firmware.

Boris

@armel
Copy link
Owner

armel commented Mar 20, 2024

Bonsoir Boris,

De mon coté, j'avais mesuré ceci :

Flashlight pèse environ 244 octets
Audio bar pèse environ 356 octets
FM Broadcast pèse environ... 4 052 octets

Ces 3 fonctionnalités n'ont, de mon point de vue, qu'un intérêt limité (voir nul) dans le cadre d'une activité radio amateur. Bon Flashlight peut éventuellement dépanner (dans l'obscurité). Maintenant, la FM Broadcast... Quant à l'audio bar, ok c'est sympa, mais qui s'en préoccupe, surtout quand on a le pocket dans la main et que l'on module.

À noter que si j'enlève les 3 en même temps, je gagne 4 644 octets. Je pense néanmoins qu'il conviendrait de garder au moins le ON/OFF de la lampe, comme tu l'as fait. Bref, il est possible de gagner 4 500 octets environ.

Vox pèse environ 772 octets. Mais là, pour le coup, on touche à une fonctionnalité clairement utilisée par certains, dans le cadre de notre activité radio amateur. Donc je ne trouverais pas légitime de l'enlever.

En complément, on peut très certainement grater encore quelques dizaines d'octets ici ou là. Par exemple, Jocelyn m'a suggéré de tenter une modification hier, qui a permis de gagner 46 octets. Je sais aussi que des bouts de code complet pourrait être totalement repris de A à Z, même si parfois, simplifier le code ne se traduit pas automatiquement par un gain en mémoire (les subtilités du compilateur...).

Mais dans les faits, ce serait tout de même plus simple si nous avions carrément 1 Mo de mémoire Flash, comme sur certains pocket bas de gamme (genre Radiodity GD77).

73'

Armel F4HWN.

@f1ixx
Copy link
Author

f1ixx commented Mar 21, 2024

Bonsoir

Oui, 1Mo serait bien mieux. Mais on a fait tourner MS/Dos sur 640Ko ;-)
Mais c'est sur qu'un peu plus de place serait interessant, le double serait
a mon avis deja pas mal.

Pour le VOX, oui, c'est utile a certain(e). J'ai juste desactive de tout facon au cas ou.

La version 3.0 sera donc sur la reecriture complete du source :-D
Histoire de passer des nuits blanches.

Apres avoir balade et farouille, certaine fonction son alambicaire pour ma petite tete.
Le system de scan, scan spectral sont impresionnante a suivre et comme j'ai deja
dit, je suis absolument pas de la partie et il me manque beaucoup de chose.

Pour le compilateur, oui j'ai des choses etranges parfois. Je supprime du code, des
variables ou modifi et je perds de la place. La je me l'explique pas.
J'ai aussi quelque test a faire pour voir quel est la meilleur solution sur
certaine fonction.

Bref, je vais encore faire joujou a regarde et tester.

Merci
73's

Boris

@f1ixx
Copy link
Author

f1ixx commented Mar 23, 2024

Bonjour Armel

Dans la serie : idee qui sert qu'a moi, ma modif du jour. Qui me saire de temps en temps.
Lorsqu'on fait :

  • appuie de [F #] puis [1 Band] : on monte de bande.
  • appuie LONG sur [1 Band] : on monte de bande.

Dans app/main.c, vers la ligne : 140 on a le : gTxVfo->Band += 1;
j'ai ajouter :

#ifdef ENABLE_BAND_CHANGE
	if (beep)
            {
		gTxVfo->Band -= 1;
                if (gTxVfo->Band == 255)
                     gTxVfo->Band = BAND_N_ELEM-1;
            }
            else
#endif
            {
		gTxVfo->Band += 1;
            }

Compiler ca me prend 16 octets.
Maintenant :

  • appuie de [F #] puis [1 Band] : on descent de bande.
  • appuie LONG sur [1 Band] : on monte de bande.

Merci pour le petit live et les explications (faudrait faire des cours ;-)
73's

@armel
Copy link
Owner

armel commented Mar 27, 2024

Bonsoir Boris,

Je pense que cette modif va dépendre étroitement des bandes déverrouillées dans les menus cachés.
Donc, avis partagé en l'état :)

73'

Armel F4HWN.

@f1ixx
Copy link
Author

f1ixx commented Mar 27, 2024

Bonjour Armel

J'ai pas regarde plus loin pour le moment.
Le teste semble etre bon sur mes essais.
L'expert, c'est vous.

Et comme dit plus haut ou dans d'autre issues : juste une idee.

Merci du retour
73'
Boris

@armel armel closed this as completed Apr 2, 2024
@armel armel transferred this issue from armel/uv-k5-firmware-custom-feat-F4HWN May 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants