[HN Gopher] From Zero to main(): Bare metal C
       ___________________________________________________________________
        
       From Zero to main(): Bare metal C
        
       Author : olalonde
       Score  : 114 points
       Date   : 2023-01-20 20:07 UTC (2 hours ago)
        
 (HTM) web link (interrupt.memfault.com)
 (TXT) w3m dump (interrupt.memfault.com)
        
       | travisgriggs wrote:
       | Ahh the SAMD21G18. Of all the chips to show up on HN today. This
       | chip I know not half as much as I'd like to and half as much I
       | wish I didn't have to.
       | 
       | We ported a rarely heard of RTOS to this chip (TNEO), and one of
       | the most difficult parts was running tickless with sleepable
       | states. The difficulty (discovered only by blood, sweat, tears,
       | wtf oscope moments, dumb luck, and a random comment found on some
       | obscure forum, definitely not in the data sheets) was that
       | accessing certain registers (in our case RTC.CNT) would cause the
       | chip to go in to a different clock domain temporarily and
       | suddenly take as much as 300 usecs to read. Just this line:
       | uint currentClock = RTC.CNT;
       | 
       | That's all it took. Whereas most store some register into some
       | local variable took nanoseconds, this one took a long long time.
       | 
       | My experience in this world of embedded chips, is that many of
       | the tutorials you read do not deal with power consumption really.
       | They assume that you're playing with a dev board. Or that your
       | application has copious amounts of power. But if you live in a
       | battery powered world, your entire game lies around navigating
       | between sleep and wake states on the chip.
        
         | watermelon59 wrote:
         | > My experience in this world of embedded chips, is that many
         | of the tutorials you read do not deal with power consumption
         | really. They assume that you're playing with a dev board. Or
         | that your application has copious amounts of power. But if you
         | live in a battery powered world, your entire game lies around
         | navigating between sleep and wake states on the chip.
         | 
         | This has been my experience so far trying to build my own
         | devices at home. They all assume I'll connect things to a USB
         | port or have a power adapter. Material on how to deal with
         | battery voltage dropping over time, determining battery level,
         | etc. is really scattered. Makes me wish I was an EE major
         | instead of CS.
        
           | tyhoff wrote:
           | You speak of such truths :D. It's a seriously under-
           | documented knowledge gap on the Internet. There are an
           | infinite number of Cortex-M4 MCU's but only a few I would
           | recommend hardware companies actually use, primarily due to
           | power consumption of production work-loads (sleeping and deep
           | sleep) and the software packages that are bundled, both of
           | which are generally not assessed before choosing hardware.
        
             | MrBuddyCasino wrote:
             | Curious, which ones are good & which ones are bad?
        
           | anigbrowl wrote:
           | * * *
        
           | bradrn wrote:
           | Do you have any recommendations as to any resources on this?
        
             | travisgriggs wrote:
             | So far... we've been pleased with our newer developments on
             | the NRF52832 using Zephyr. It's the same chip (I think)
             | that Apple used in their AirTags.
             | 
             | That said, we're still in that early-ish phase. Four-ish
             | years from now, there's probably going to be a post where I
             | start off with something like
             | 
             | "Ahh the Nordic NRF52832. Of all the chips to show up on HN
             | today. This chip I know not half as much as I'd like to and
             | half as much I wish I didn't have to..."
             | 
             | It's sort of a vicious cycle.
        
         | cozzyd wrote:
         | yeah we're using the SAMD21J18 for our controller board for an
         | experiment in Greenland and... had a huge pain on porting a
         | LoRAWAN stack to it due to clock domains affecting timing too
         | much. It didn't matter too much (since the message rate is so
         | low it doesn't really matter for power consumption) so I just
         | made the tolerances really big.
        
         | not_the_fda wrote:
         | I hate that chip. I had a client pick it for a project that
         | they wanted low power. You can't put the chip fully to sleep.
         | There is errata on the NVM controller that it doesn't always
         | wake from sleep so when the chip wakes it executes garbage. You
         | have to keep the NVM controller powered during sleep to recover
         | from sleep.
        
         | detrites wrote:
         | > But if you live in a battery powered world, your entire game
         | lies around navigating between sleep and wake states on the
         | chip.
         | 
         | Is this true of every chip, or are there eco-systems where it's
         | documented better, or less of an issue for other reasons?
        
       | badrabbit wrote:
       | > Thou shalt initialize thy static variables, else The Machine
       | shall set them to zero.
       | 
       | Isn't that last part a bad assumption since it could be arbitrary
       | values as well? Because people expecting a default zero value
       | might be surprised otherwise.
        
         | monocasa wrote:
         | In addition to what's been stated in the c standard below, the
         | way this works is these variables are included in the .bss
         | section, which means in a bare metal env you memset it to zero
         | at init about the same time you copy a fresh version of .data
         | over from flash.
        
         | shadowofneptune wrote:
         | > If an object that has automatic storage duration is not
         | initialized explicitly, its value is indeterminate. If an
         | object that has static storage duration is not initialized
         | explicitly, then:
         | 
         | * if it has pointer type, it is initialized to a null pointer;
         | 
         | * if it has arithmetic type, it is initialized to (positive or
         | unsigned) zero;
         | 
         | [end quote]
         | 
         | --C99 Standard, SS6.7.8
         | 
         | EDIT: That said, it can only relied upon to be zero at the
         | first call of the function.
        
           | InfiniteRand wrote:
           | I've seen a couple boards that purely ignore this, at least
           | for some TI targets their position is if they supply some
           | obscure linker option that makes it possible to initialize
           | static memory then they've satisfied the standard
        
       | keepquestioning wrote:
       | Bad news.
        
       | kaycebasques wrote:
       | Courtesy heads up for any hardware n00bs like myself who are
       | buying the parts to work through this series hands-on: some of
       | the required parts are hard to find. You should double-check that
       | your replacement parts will work.
       | https://news.ycombinator.com/item?id=33360830
        
         | 082349872349872 wrote:
         | Even as a pure software weenie it may be worth playing with
         | _gcc -nostdlib_ sometime, just to get a feel for what is done
         | for you in crt0 and libc.
        
           | galangalalgol wrote:
           | Had a class back in college where the first project was to
           | write a tiny stdlib in 68000 assembly, then we got to call it
           | from c to write a simple os. It was very illuminating.
        
       ___________________________________________________________________
       (page generated 2023-01-20 23:00 UTC)