Thank you for the reply. My concern was that the method has the N generic
parameter in it. Does the compiler just figure that out and so the usage is as
simple as something like:
#----------- circBuffer.nim
import ringbuffer
var myBuf*: RingBuffer[N: 8, T: uint8]
proc someProcess*() =
#some stuff
myBuf.add(0x03)
#----------- main.nim
import circBuffer
proc main =
while true:
circBuffer.someProcess()
circBuffer.myBuf.add(0x04)
Stefan,
I think I can access all the registers. I'm in the early stages. I did start
off with that repo, but have modified it quite a bit. There was a problem with
the header file for the device and it was making zero initialized pointers to
registers, I think. The bss section had a bunch of symbols that were meant to
be the same as #defined pointers to memory locations. I haven't committed it or
anything yet as I'm not very far along. Basically I got it to compile, read the
assembly to see that it was doing what I wanted, particularly in regards to an
interrupt routine, and then loaded it onto the board and made sure nothing
exploded. There's not even a blinking light yet. The assembly looks good except
that the entry into my main routine has several steps. It goes from a main
routine, which calls a NimMain() routine, which then calls my main,
main_818410831058, which loops in place. That seems unnecessary to me, but not
a huge deal I guess.
I am using the MSPGCC compiler, which I think is intentionally neutered as they
want you to buy their compiler. The assembly looks good though. Accessing the
P2IV register looks correct in the assembly. I don't know how to force Nim to
tell the C compiler to make a jump table, which is what I would do. There are
compiler intrinsics for that sort of thing, so I could use the FFI. The number
of options is limited and a case statement would only have to handle powers of
2.
As for garbage collection... at my workplace we don't use any dynamic memory
allocation. Everything is statically allocated. We don't make products that are
classified as "safety critical" but they are high reliability devices and there
is liability if a device doesn't work when it's supposed to. Static allocation
makes sense for many of the embedded systems that I work on at least.
Everything is bare metal. It seems like the concerns in the embedded world are
quite different from those of the PC world. That's alright though. I'll slog
away at it with some help from kind people like you and then there will be more
information out there for the masses. I might even try and resurrect my blog
haha. Also, allocating memory on a heap is non-deterministic I think in terms
of time. That makes it harder to reason about systems in which I literally have
to count cycles sometimes to meet execution deadlines.
Also, I was talking to a coworker about the nature of special function
registers. In C, the macros for registers in the header files expand to
dereferences of pointers to volatile memory. Nim has the volatileLoad and
volatileStore functions instead. I'm not sure how I feel about that. I think I
like it better actually. Time will tell.
Maybe I just don't know about it, but the option of using the language features
that use the heap like seq but in a statically allocated memory way would be
nice. It would just prevent the memory allocated for the seq from being resized.
