Μετακινηση απο PIC σε ARM

[keto]

Καλησπερα,
ειμαι φοιτητης και εδω και 2 χρονια ασχολουμαι με τους PIC18,32 και θελω να περασω στους ARM και συγκεκριμενα τους STM32.Εχω ψαξει πολυ στο google για tutorials για να αρχισω απο καπου.Θα ηθελα να μου πει καποιος που εχει ασχοληθει πως ακριβως γραφεις firmware για αυτους.Δηλαδη στους PIC που ειμαι απλα ανοιγεις το datasheet του μικροελενχτη διαβασεις πχ για την UART,θετεις τους καταλληλους καταχωρητες και τις συναρτισεις που θες και το τρεχεις(χρησιμοποιω xc8 σαν compiler).Στους STM σε ολα τα tutorials χρησιμοποιουν το RTOS και τις συναρτησεις του χωρις να μπλεκουν με καταχωρητες κλπ.Ετσι δουλευουν οι STM32?Δεν μπορει καποιος να χρησιμοποιεισει καταχωρητες οπως στους PIC με εναν compiler επιπεδου xc8 και οχι υψηλου επιπεδου συναρτισεις μεσω του RTOS?Εγω θελω να αρχισω με κατι που ειναι κοντα στην λογικη των PIC για να μου ερθει πιο ευκολα,ο μονος τροπος στους STM32 ειναι να μαθεις τις συναρτισεις του RTOS?Θα πει καποιος μπορεις να γραψεις και απλη assembly αλλα δεν θελω τοσο χαμηλο επιπεδο,θελω κατι ενδιαμεσο σε assembly και RTOS οπως στους PIC.

[kioan]

Υπάρχουν 3 βασικοί δρόμοι που μπορείς να ακολουθήσεις:

• CMSIS (Cortex Microcontroller Software Interface Standard)
• SPL (Standard Peripheral Library)
• HAL (Hardware Abstraction Layer)

Μια περιγραφή για το τι σημαίνουν τα παρακάτω, μπορείς να βρεις εδώ.


Αυτό που θέλεις εσύ, τον προγραμματισμό σε επίπεδο καταχωρητών κλπ είναι το CMSIS. Τα άλλα δύο εισάγουν abstraction layers αποκρύπτοντας τις λεπτομέρειες του επεξεργαστή (αλλά κάνουν τον κώδικά σου πιο εύκολα μεταφέρσιμο από μια οικογένεια επεξεργαστών σε κάποια άλλη).

[keto]

Υπάρχουν 3 βασικοί δρόμοι που μπορείς να ακολουθήσεις:

• CMSIS (Cortex Microcontroller Software Interface Standard)
• SPL (Standard Peripheral Library)
• HAL (Hardware Abstraction Layer)

Μια περιγραφή για το τι σημαίνουν τα παρακάτω, μπορείς να βρεις εδώ.


Αυτό που θέλεις εσύ, τον προγραμματισμό σε επίπεδο καταχωρητών κλπ είναι το CMSIS. Τα άλλα δύο εισάγουν abstraction layers αποκρύπτοντας τις λεπτομέρειες του επεξεργαστή (αλλά κάνουν τον κώδικά σου πιο εύκολα μεταφέρσιμο από μια οικογένεια επεξεργαστών σε κάποια άλλη).

Eυχαριστω για την πληροφορια,εγω ειχα δει μονο την HAL που δεν μ αρεσε.Την SPL βλεπω την απερριψε ST οποτε ο μονος δρομος ειναι να παω στην CMSIS να δω και αυτην.Υπαρχει καποια εταιρεια που να βγαζει υλικο με ARM αλλα να εχει καλυτερο documentation και καποιον compiler με τα θελω που περιεγραψα πιο πανω και να ειναι αξιοπιστη για να κινηθω προς αυτην(αν και βλεπω πως ολοι που ασχολουνται με ARM ,τους STM χρησιμοποιουν)

[picdev]

στους arm κάθε εταιρεία φτιάχνει τα δικά τους περιφερειακά , οι spl δεν υπάρχουν πλέον οπότε πας αναγκαστηκά σε HAL.

Οι stm32 έχουν μεγάλη κοινότητα και γενικά ειναι μονόδρομος, επίδης έχουν κάνει κορυφαίες συνεργασίες για GUI, έχουν αγοράσει το true studio που ειναι πολύ καλο εργαλείο ανάπτυξης.

https://atollic.com/truestudio/


όπως επίσης και με το touch gfx

https://www.touchgfx.com/product/stm32-gui/

Επειδή όπως λες έγινε μεγάλη φασαρία με τους HAL , αφού ειναι πιο abscract απο τους SPL , έχουν βγάλει και τους LL.
https://www.st.com/content/ccc/resou...DM00105879.pdf

οι hal δεν ειναι απαραίτητα κάτι κακό αφού μπορείς εύκολα να κάνεις αλλαγή απο τον έναν επεξεργαστή στον άλλον, κανένας mcu δεν θα κυκλοφορεί για πάντα,αλλά σίγουρα θες παραπάνω μνήμη και πόρους.
οπότε καλό ειναι στο software που γράφεις να διαχωρίζεις τους drivers για τα peripheral με το πρόγραμμα σου, ώστε το intergration να γινεται εύκολα.

οι stm32 ειναι η καλύτερη επιλογή πιστεύω λόγω των συνεργασιών και αυτά που προσφέρει δωρεάν

[SProg]

HAL. Ξεχνα ASM, αυτα μονο στα προπτυχιακα ή αν γραφεις δικους σου Drivers (προφανως και οχι)

[picdev]

και με C κανονικά γράφεις drivers και σετάρεις bit, δεν χρειάζεται ASM

[SProg]

Είσαι ένα επίπεδο πάνω στη C, εξ ορισμού με τη C εκτελείς περισσότερες εντολές. Ιδανικός C compiler δεν υπάρχει.

Αν εννοεις πως με τους συγχρονους compilers δεν έχει νοήμα η ASM τότε συμφωνώ (και πάλι πλην σπάνιων εξαιρεσεων).

[keto]

Aρα με HAL παιζουν οι περισσοτεροι?

[mtzag]

Γενικα να ξερεις οσο περναει ο καιρος οι mcus θα γινοται ποιο γρηγοροι με περισσοτερους πορους κτλπ
οποτε τα διαφορα optimizations δεν χουνε τοσο νοημα(αυτα θα τα κανουνε στο μελλον ολο και καλυτερα οι compilers)
οσο εχει η μεταφερσιμοτητα του κωδικα και το ποσο ποιο απλος ειναι.
Οποτε τα frameworks που εισαγουνε abstraction layers επιταχυνουνε την διαδικασια αναπτυξεις χωρις να σε μπλεκουνε με ανουσιες λεπτομεριες.
Το ιδιο εγινε και στους υπολογιστες με τη java.
Οσο περναει ο καιρος οδηγουμαστε σε γλωσες/frameworks υψηλοτερου επιπεδου..
Η asm εχει καταργηθει στην πραξη για αναπτυξη εδω και πολλα χρονια αλλα δεν θα καταργηθει ποτε για το reverse engineering.
Στο reverse engineering θα ειναι παντα η μονη και μοναδικη λυση.

[picdev]

ιδανικός compiler για τη C είναι ο GCC , άλλωστε όλοι με αυτό δουλεύουν