Comments (3)
I won't lie -- I'm not happy with the make/build system for the code in the book. There are two competing tensions: a) it's nice to have each chapter's code self-contained and b) it creates a lot of redundancy to have each chapter self-contained.
There's also an existing gotcha -- because of the way the CPU speed is incorporated in the Makefiles, it needs a "make distclean" when it's changed or else the already-compiled USART.o will come in with the wrong speed. But because you can always pass F_CPU as a command-line option, I don't know an ironclad way around this except to recompile everything all of the time, which is probably the right thing to do.
F_CPU aside, I think the Makefile is the same (or varies in the .c filename, which is autodetected from the directory name) anyway. This probably makes the Makefile.inc idea even more reasonable -- toss that in the library folder and be done with it.
And because of that fact, I think it'd be very easy to restructure the way you're thinking. Or maybe split the makefile up into a programming-logic section and a flash-programming section, leaving the main defines (chip, CPU, baud) in each directory?
Have at it and submit a pull request! I'll open up a development branch and hack away as well. I'm going on vacation for a couple weeks, but will have time to review stuff afterwards.
Thanks!
from avr-programming.
hexagon5un writes:
I won't lie -- I'm not happy with the make/build system for the code
in the book. There are two competing tensions: a) it's nice to have
each chapter's code self-contained and b) it creates a lot of
redundancy to have each chapter self-contained.
Totally understand, and that's why I wanted to know if the work was
welcome before embarking on it.
There's also an existing gotcha -- because of the way the CPU speed is
incorporated in the Makefiles, it needs a "make distclean" when it's
changed or else the already-compiled USART.o will come in with the
wrong speed. But because you can always pass F_CPU as a command-line
option, I don't know an ironclad way around this except to recompile
everything all of the time, which is probably the right thing to do.
Well, its pretty conventional with C makefiles that if you change
CFLAGS, you're going to have to 'make clean' to get good results.
So I wouldn't stress too much over this one.
F_CPU aside, I think the Makefile is the same (or varies in the .c
filename, which is autodetected from the directory name) anyway. This
probably makes the Makefile.inc idea even more reasonable -- toss that
in the library folder and be done with it.And because of that fact, I think it'd be very easy to restructure the
way you're thinking. Or maybe split the makefile up into a
programming-logic section and a flash-programming section, leaving the
main defines (chip, CPU, baud) in each directory?Have at it and submit a pull request! I'll open up a development
branch and hack away as well. I'm going on vacation for a couple
weeks, but will have time to review stuff afterwards.
Ok, great. I'll try to work out something that seems natural. I'm hearing
that you'd prefer per-directory configuration of basics (baud and CPU etc),
no objections there.
Does it make sense to assign this ticket to me?
from avr-programming.
Pull request is in!
from avr-programming.
Related Issues (20)
- pwmOnAnyPin: Incorrect register bit access
- Chapter 8 Interrupt code and serialScope do not match together
- Unclear statement Chapter 10: only 3 LEDs for hardware PWM when ATmega168PA has 6 HOT 1
- issue building makefile on ubuntu HOT 4
- Windows 10. avr-gcc and avrdude want different MCU strings
- USART.c ATmega16A fix.
- file not found error on first make attempt HOT 3
- When changing Makefile new hex is not generated
- question about makefile
- python code updated to python 3 HOT 4
- download zip fails with a 0kb download
- Lost the ability to receive bytes via USART by Chapter 9! HOT 1
- Issue with Serial Connection on Arduino HOT 2
- littlehacks.org - looks like it's down HOT 2
- compiler warnings atmel328p HOT 1
- avr 328p, crystal and leds HOT 1
- Magical number 3000 in servoWorkout.c (chapter 11)
- magical number 3000 in servoWorkout.c (chapter 11)
- examples 11-1 vs 11-2, prescaling and count speed HOT 1
- Some thoughts
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from avr-programming.