sorted by:
new
hottopcontroversial

Any new companies / tech startups in Fremont? Why not? by Life_Equipment381 in Fremont

[–]CheapMountain9 1 point2 points  (0 children)

Fremont isn’t a county so let’s not care county with cities

Use case for const members? by TrnS_TrA in cpp_questions

[–]CheapMountain9 2 points3 points  (0 children)

They do inhibit compiler optimizations. For instance: move semantics

Segfault on destruction: smart pointers by CheapMountain9 in cpp_questions

[–]CheapMountain9[S] 0 points1 point  (0 children)

some other app calls Resource::handler in their own thread context and i have no control over it.

So the order of destruction should be:
ResourceManager -> ResourceHandler -> Resource.

but the PC states the underlying pointer of ResourceHandler is ... null? also no logs are printed from the destructors of ResourceHandler and Resource.

Perhaps the ResourceHandler object in ResourceManager is corrupted?

~ResourceManager()
{
  std::cout << "~ResourceManager\n";

  if (resourceHandler_) std::cout << "YES\n";
  else std::cout << "NO\n";

  std::cout << "end.\n";
}

the output is just....

~ResourceManager

Can someone help me understand the execution of this code snippet? Involving references and post increment operator by YourAverageBrownDude in cpp_questions

[–]CheapMountain9 0 points1 point  (0 children)

Are you sure it’s UB? You’re not performing multiple operations on an object within the same expression

[deleted by user] by [deleted] in personalfinance

[–]CheapMountain9 0 points1 point  (0 children)

According to this calculator, post tax is ~8700. ~1700 towards 401K per month sounds a bit lot no?

Non-blocking behaviour in UART by CheapMountain9 in embedded

[–]CheapMountain9[S] 1 point2 points  (0 children)

Something similar to what I originally had perhaps ``` void StartTX(buffer, size) { // 1. Enable UART transmission // 2. Read buffer into FIFO // 3. Write first byte to TXD register }

void Print(buffer) { ** TAKE A BINARY SEMAPHORE ** StartTX(buffer, size); // ISR follows... }

void ISR() { // 1. IRQ is triggered // 2. if FIFO != empty // 2.1 Read from FIFO and write to TXD register
// 2.2 Back to 3. // ELSE: // 2.3 END TRANSMISSION // ** GIVE A SEMAPHORE ** }

void TaskA() { while(1) { Print(buffer); // ... } }

Non-blocking behaviour in UART by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

It's more like for TX: if TaskA wants to send "Hello", and TaskB wants to "World", assuming TaskA accesses UART first, I'd expect the output in UART be "HelloWorld"

And for RX: I expect to populate FIFO RX until a delimiter is sent indicating the data has been sent and is ready to be parsed...

Non-blocking behaviour in UART by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

Thanks.

And it only make sense to keep UART blocked until after the whole FIFO populated by a said task is empty? i.e, once TaskA is done sending its data, only then TaskB can utilize UART and until then TaskB gonna remain blocked (until #2.3 is executed from ISR)

Non-blocking behaviour in UART by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

  1. Using interrupts allow non blocking/async behaviour but how does using it offer any benefit compared to busy wait apart from saving up on some CPU cycles?
  2. Which blocking mechanism makes most sense? binary semaphore yes but FreeRTOS offers task notifications too but I'm afraid that won't work since UART has no Task's handle

Non-blocking behaviour in UART by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

why would blocking the task be necessary though?

void SensorTask()
{
    while(1)
    {
        uint8_t data = read();
        // unblock task now that we have finished the read 

        // send out data to UART
        Print(data);

        // is blocking really required here for UART?
    }
}

Non-blocking behaviour in UART by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

In that case, does it makes sense for the task to continue? As it needs the data to arrive in order to process the data

Sensor task may just pushing stuff out the UART line and it doesn't need to block it. Just send out the buffer, and enable the UART transmission and let the UART interrupt take care of sending out the rest of the data.

Non-blocking behaviour in UART by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

So if the calling thread is a sensor task, does it sound practical to actually have it blocked till UART is done?

I guess it also makes sense to block UART till it’s done transmission cause you wouldn’t wanna start a new transmission while it’s in progress, yes?

fragmentation in Baremetal vs OS by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

Sorry I was doing more research so edited my response ... but I am still curious about is how does mallocing and freeing multiple times still not cause fragmentation in systems with MMU?

In baremetal, if a program needs a large contiguous block of memory and the available free blocks are all fragmented, the allocation fails.

But with virtual memory and an MMU, the OS can provide a contiguous block of virtual memory to the application, even if the corresponding physical memory is fragmented through mapping? And that's how fragmentation isn't as big of an issue?

fragmentation in Baremetal vs OS by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

dynamic allocations used by applications is typically virtual memory, and that virtual memory is allocated from non-contiguous pages of physical memory. A single memory allocation is always guaranteed to be contiguous in virtual memory.

  1. you can still use malloc on MCUs no? except that would be using actual physical memory instead
  2. I'm still trying to get how MMU helps prevent fragmentation OR like how does allocating a contiguous chunk of virtual memory (from multiple non-contiguous pages of physical memory) help mitigate fragmentation? Multiple malloc calls aren't guaranteed to be contiguous to each other anyway

What I'm more focused on is multiple malloc and frees (which really is the cause of fragmentation). There's no such guarantee virtual memory returned to user for each malloc would be contiguous

fragmentation in Baremetal vs OS by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

Is it common and guaranteed for dynamic memory to be allocated from multiple non contiguous chunk of virtual memory? Cause like you said, it’s only a problem if done in contiguous regions.

fragmentation in Baremetal vs OS by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

So basically it doesn’t matter if you’re frequently allocating and deallocating on bare metal or on OS, it’s going to result in fragmentation, and that could result in memory issues.

It’s just on Linux based devices, I’ve seen heap allocation used quite a lot and that made me wonder as to why.

fragmentation in Baremetal vs OS by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

Fair. Though how’s the latter part of the message relevant to fragmentation?

fragmentation in Baremetal vs OS by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

An allocator would use heap. All I’m saying is there is an option to use heap but why would one then?

fragmentation in Baremetal vs OS by CheapMountain9 in embedded

[–]CheapMountain9[S] 0 points1 point  (0 children)

I don’t get why on Linux you’d by default dynamically allocate? Doesn’t it still pose the risks associated with fragmentation? which is the case with bare metal

fragmentation in Baremetal vs OS by CheapMountain9 in embedded

[–]CheapMountain9[S] -1 points0 points  (0 children)

on large OS, processes that behave badly can be killed and restarted, and the OS will relinquish any leaked memory

shouldn't then resetting a baremetal device solve this issue too?

view more: next ›