I dug into the makefiles for the SDK whilst fiddling around and noticed that the toolchain is built with the --disable-linux flag.
Is there a way I can correctly include unistd.h with the SDK as-built via “make tools” or is there more work involved like compiling glibc for the toolchain? Is it even possible?
I’m VERY new to C so please excuse any silly questions My ultimate goal right now is to learn more about using standard C libraries to control digital output via GPIO (driving a resistor ladder DAC a la http://www.instructables.com/id/Arduino-Audio-Output/)
C and UNIX have such a tight history that discerning what’s part of the C standard library and what’s part of the C POSIX libraries can get a little tricky. unistd.h is part of the latter (I’m not even sure it’s mentioned in K&R?) and provides OS APIs which exist to hide the hardware implementation from the application developer, and as the HiFive1 doesn’t run any POSIX compliant OS there’s not much in unistd.h which would be very useful (n.b., there are a few things like a NULL definition, which can come in handy).
In the embedded scope you create delays either by carefully calculated loops (ug) or structuring your code around events which can be driven by hardware timers. See the GPIO demo program distributed with the Freedom E SDK for an example and there’s a lot of helpful information in the manual.
Finally, there’s always the Arduino IDE. I don’t know how complete it is for the HiFive1 but that may also be a good place to start easing into embeded delays and interrupts.
There’s nothing silly about any of these questions.
[quote=“seasharp, post:1, topic:591”]My ultimate goal right now is to learn more about using standard C libraries to control digital output via GPIO (driving a resistor ladder DAC a la http://www.instructables.com/id/Arduino-Audio-Output/)
[/quote]
Cool. If it’s analog translation you’re ultimately interested in the FE310 is also pretty generous with hardware PWM which can used with a smoothing capacitor to generate varying levels from a single IO pin.
This makes sense to me, thanks for clarifying. I guess my next question is, how can I verify that I have the right libraries/headers in my (make? gcc?) path? I’ve also dug through the riscv-toolchain git submodule and I can’t seem to easily suss it out. Is this something easily derived from the included makefiles?
I have a slight aversion to learning the Arduino IDE that might be misguided since I’m under the impression that the libs are not exactly portable, ie if I were to start writing C for a chip that is not on an Arduino-compatible board I’d be out of my depth. Is there any truth to this?
I’ll add that to my short list of concepts to prod, thanks again!
Yep, see the top-level Makefile and bsp/env/common.mk.
There’s nothing stopping you from looking into the Arduino libraries to understand how they actually work so it’s really a question of personal motivation and your ultimate aims.
Besides, once you start targeting such small devices the notion of portability has already gone out the window anyway, they simply don’t have the available resources for extra layers of abstraction.
My ultimate goal right now is to learn more about using standard C libraries to control digital output via GPIO (driving a resistor ladder DAC a la http://www.instructables.com/id/Arduino-Audio-Output/)