64K is still quite a lot! Embedded Programming Microthread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

«‹›53 »

Hunter2 Thompson: Feb 3, 2005; Ramrod XTreme

Too add to muon's post, srec_cat (part of the srecord suite) is an excellent tool that can merge, convert and manipulate dozens of firmware images.

# ? Oct 17, 2015 01:50

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 00:22

carticket: Jun 28, 2005; white and gold.

Slanderer posted:

Anyone know how I can convince the IAR compiler to load two different applications onto the same processor with a debugger? Specifically, I have a boot loader application and a main application, which I manage as separate IAR projects, and load individually. For reasons not worth going into, the debugger is the only way to load either application right now, and I would like to ensure that people don't accidentally forget to update the bootloader by forcing it to be downloaded by the debugger every time. Anyone know if this is possible?

I don't remember what file types IAR is able to load & download, but if you grab the J-Flash tool from SEGGER (just the software, which doesn't require a license) you can open a variety of files, merge them and save as a variety. There will hopefully be a combination that you can then use IAR to flash.

# ? Oct 17, 2015 23:11

Pan Et Circenses: Nov 2, 2009

Slanderer posted:

Anyone know how I can convince the IAR compiler to load two different applications onto the same processor with a debugger? Specifically, I have a boot loader application and a main application, which I manage as separate IAR projects, and load individually. For reasons not worth going into, the debugger is the only way to load either application right now, and I would like to ensure that people don't accidentally forget to update the bootloader by forcing it to be downloaded by the debugger every time. Anyone know if this is possible?

Is this what you're looking for?

# ? Oct 18, 2015 05:15

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

As a followup to my post about Octo-ber, we had 25 submissions, and some goons and I streamed playing through all of them. Check out the chip-8 thread for a link and some development postmortems if you're interested.

# ? Nov 9, 2015 04:45

travelling wave: Nov 25, 2013

Does anyone know why people define bit flags like this:

code:

#define FLAG1 1
#define FLAG2 2

reg = (1 << FLAG1) | (1 << FLAG2);

rather than like this:

code:

#define FLAG1 (1 << 1)
#define FLAG2 (1 << 2)

reg = FLAG1 | FLAG2;

I see both a lot, but I can't think of a single reason to prefer the first.

# ? Nov 29, 2015 12:19

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

travelling wave posted:

Does anyone know why people define bit flags like this:
code:
#define FLAG1 1
#define FLAG2 2

reg = (1 << FLAG1) | (1 << FLAG2);
rather than like this:
code:
#define FLAG1 (1 << 1)
#define FLAG2 (1 << 2)

reg = FLAG1 | FLAG2;
I see both a lot, but I can't think of a single reason to prefer the first.

you could then use an enum with autoincrement

code:

enum Flags {
ENABLE_FART = 1,
ENABLE_BUTT
}

# ? Nov 29, 2015 14:08

travelling wave: Nov 25, 2013

Malcolm XML posted:

you could then use an enum with autoincrement
code:
enum Flags {
ENABLE_FART = 1,
ENABLE_BUTT
}

You could, but I don't see why you would want to. Flag definitions are the kind of code you write once and never touch again so the auto-increment is marginally useful at best. It just seems like it's forcing the end user add boilerplate in exchange for making the header files oh-so-slightly easier to write.

# ? Nov 29, 2015 15:25

Pan Et Circenses: Nov 2, 2009

travelling wave posted:

Does anyone know why people define bit flags like this:

It's frequently useful to have easy access to the bit position as well as the mask. The former gives you both, the latter doesn't. In many systems where the designer has really been thorough, you'll get both definitions.

Just as an example, Kinetis processors have a fancy bit-banding system they call the "bit manipulation engine" that can perform a number of useful atomic operations on individual bits in peripheral registers. These bit manipulation commands use the bit number, not its mask.

# ? Nov 29, 2015 16:16

carticket: Jun 28, 2005; white and gold.

Pan Et Circenses posted:

It's frequently useful to have easy access to the bit position as well as the mask. The former gives you both, the latter doesn't. In many systems where the designer has really been thorough, you'll get both definitions.

Just as an example, Kinetis processors have a fancy bit-banding system they call the "bit manipulation engine" that can perform a number of useful atomic operations on individual bits in peripheral registers. These bit manipulation commands use the bit number, not its mask.

I'm pretty sure this is a feature of most Cortex Ms. I know ST has it in at least the F2 line.

# ? Nov 29, 2015 17:58

yippee cahier: Mar 28, 2005

Thanks for reminding me to port the bit access macros given to me by Atmel to use the bit-banding region of memory.

As far as bit positions are concerned, I don't really mind either way. Whatever looks less cluttered, I guess, but either way means I'm not going to see some code later that tests for "& 0x40" so I'm happy.

In case anyone else is on ARM or suitable platform, look into the ctz builtin for decoding masks in one instruction.

# ? Nov 30, 2015 03:42

Pan Et Circenses: Nov 2, 2009

Mr. Powers posted:

I'm pretty sure this is a feature of most Cortex Ms. I know ST has it in at least the F2 line.

The ones on the Kinetis are somewhat more sophisticated than usual. Normally you just get bitwise read/write, but Kinetis gives you all the basic logical operators as well as bit insert/clear and stuff like that in atomic forms (basically hardware-atomic BFI/BFC instructions). It's quite nice really. Too bad I've found the peripherals on the lower power models really lacking, because they do some things nicely.

sund posted:

In case anyone else is on ARM or suitable platform, look into the ctz builtin for decoding masks in one instruction.

Keep in mind that you're still using two instructions to get the value in memory: LDR -> CTZ, rather than just the LDR if you're loading the value directly. This kind of thing can really make a difference when you're trying to run at 30 uA average draw in 8k of flash.

# ? Nov 30, 2015 07:10

carticket: Jun 28, 2005; white and gold.

Pan Et Circenses posted:

The ones on the Kinetis are somewhat more sophisticated than usual. Normally you just get bitwise read/write, but Kinetis gives you all the basic logical operators as well as bit insert/clear and stuff like that in atomic forms (basically hardware-atomic BFI/BFC instructions). It's quite nice really. Too bad I've found the peripherals on the lower power models really lacking, because they do some things nicely.

Keep in mind that you're still using two instructions to get the value in memory: LDR -> CTZ, rather than just the LDR if you're loading the value directly. This kind of thing can really make a difference when you're trying to run at 30 uA average draw in 8k of flash.

The KL28 is in the works and there is some info from roadmaps that I assume was leaked out on Google. It should help with the peripheral crunch that the rest of the series suffers from. I do really wish the KL03 had a second UART, though.

# ? Dec 1, 2015 06:50

Le0: Mar 18, 2009; Rotten investigator!

Hey guys I need your help if possible.

I'd like to replace the trap table on my system (Sparc V8), the thing is that the trap table is part of the startup files from gcc (locore_mvt.o), I have the source so ideally what I'd like to do is simply to replace this file by my own.
I found the -nostartupfiles flag for gcc but I'd prefer to just replace the one file because this removes all the other files as well.

Can I do some linker script shenanigans or something else to tell gcc to replace the locore_mvt.S file by my own?

EDIT: I managed to do it through the specs file, I provided my own to gcc and it works now

Le0 fucked around with this message at 14:06 on Dec 2, 2015

# ? Dec 2, 2015 10:47

minidracula: Dec 22, 2007; boo woo boo

It's premature, but I'm starting to really like STM32 parts, and the low-cost Discovery boards.

Has anyone here messed with or used the F3 line? Similarly, anyone have any trip reports on messing with/using ChibiOS (ideally on an STM32 part, but in general/on other parts is fine too)?

# ? Dec 3, 2015 00:16

carticket: Jun 28, 2005; white and gold.

minidracula posted:

It's premature, but I'm starting to really like STM32 parts, and the low-cost Discovery boards.

Has anyone here messed with or used the F3 line? Similarly, anyone have any trip reports on messing with/using ChibiOS (ideally on an STM32 part, but in general/on other parts is fine too)?

I tried ChibiOS on a work project that thankfully got cancelled. It was a bad decision. I was using it on a not-directly-supported Cortex M3, so I had to do some porting, but nothing in the kernel. It is oddly missing some features (trylock with timeout on mutex) and if you got a lot of interrupts (sending a file via UART) it was crashing. It also didn't make good use of the NVIC's interrupts (PendSV and SVCall). It did have incredibly small OS objects compared to FreeRTOS though, which was why I picked it.

I have a whole document I wrote about why it was a bad decision to use it instead of just trying harder to use less memory and FreeRTOS, so when I get to work I'll check and see if I forgot anything.

# ? Dec 3, 2015 14:12

Hunter2 Thompson: Feb 3, 2005; Ramrod XTreme

minidracula posted:

It's premature, but I'm starting to really like STM32 parts, and the low-cost Discovery boards.

Has anyone here messed with or used the F3 line? Similarly, anyone have any trip reports on messing with/using ChibiOS (ideally on an STM32 part, but in general/on other parts is fine too)?

I'm pretty new-ish in this area, but gently caress the ST HAL drivers and their garbage documentation. The docs are sparse and probably poorly translated from Italian. They really suck. I'm sure there are things that suck worse, but like I said, I'm new at this and haven't experienced true horror yet. Most of my experiences with ARM Cortex-M is from using Nordic stuff, which is great.

The ST chips themselves are decent and fairly economical. However, you must figure out how to use the peripherals on your own if you don't want to use their bloated, buggy HAL garbage.

# ? Dec 3, 2015 17:26

Luigi Thirty: Apr 30, 2006; Emergency confection port.

I bought a box of Soviet surplus knockoff 8086s. (They're pin and binary compatible with normal 8086s.) I was thinking that it might be fun to build a little display case and board that has them hooked up to an LED on/off button. But then I realized that an 8086 single board computer would probably need parts that haven't been made in 25 years, which would be a problem. I don't think anyone would make a premade board like that either. Are there any kind of reasonable plans out there for such a single-board computer?

# ? Dec 3, 2015 18:41

Jerry Bindle: May 16, 2003

Luigi Thirty posted:

I bought a box of Soviet surplus knockoff 8086s. (They're pin and binary compatible with normal 8086s.) I was thinking that it might be fun to build a little display case and board that has them hooked up to an LED on/off button. But then I realized that an 8086 single board computer would probably need parts that haven't been made in 25 years, which would be a problem. I don't think anyone would make a premade board like that either. Are there any kind of reasonable plans out there for such a single-board computer?

You could instrument the 8086 with a modern MCU. I've never done it and haven't thought it through, but seems like you'd just need a 5V MCU with a parallel interface, and a whole lot of time to figure out how to correctly emulate that interface and implement the other control lines with GPIO.

I looked into trying to build a SBC when I was in college. The library had a bunch of books from the 70's and 80's on the topic which were very helpful, but I don't remember what they were called. In the end I gave up because I didn't have the money to afford wire-wrapping tools and the lab didn't have any either

Jerry Bindle fucked around with this message at 18:48 on Dec 3, 2015

# ? Dec 3, 2015 18:45

Colonel Taint: Mar 14, 2004

Luigi Thirty posted:

I bought a box of Soviet surplus knockoff 8086s. (They're pin and binary compatible with normal 8086s.) I was thinking that it might be fun to build a little display case and board that has them hooked up to an LED on/off button. But then I realized that an 8086 single board computer would probably need parts that haven't been made in 25 years, which would be a problem. I don't think anyone would make a premade board like that either. Are there any kind of reasonable plans out there for such a single-board computer?

I'm not an EE/CE, not at this level anyway, but this page outlines some of the other components needed for a basic 8086 system. After some quick googling, it seems most of the parts are available - some are even fellow Russian knock-offs. Would be an interesting project.

# ? Dec 3, 2015 19:22

Luigi Thirty: Apr 30, 2006; Emergency confection port.

Eesh, I think this might be more ambitious than I first thought it would be. I think I'll just settle for a display case. I do have one of those Edison boards sitting around but I think it would be a whole lot of complex work for a dumb little project. My day job isn't really reverse engineering CPU bus logic.

# ? Dec 3, 2015 20:11

JawnV6: Jul 4, 2004; So hot ...

meatpotato posted:

I'm pretty new-ish in this area, but gently caress the ST HAL drivers and their garbage documentation.

The Cube shall save us. All hail the Cube!

Actually, it's kinda awful and every time the ST reps visited I would tell them I hated the Cube. AS7 is going in the same direction, and I'm sure the tooling will eventually obviate manual HALs, but until then I'm still budgeting time to futz with picky parts.

Luigi Thirty posted:

My day job isn't really reverse engineering CPU bus logic.

Pity.

# ? Dec 3, 2015 20:24

Jerry Bindle: May 16, 2003

Thinking of applying to a firmware/applications engineering position at intel. I've been a "applications engineer" for about 5 years now but basically get to do gently caress all actual applications engineering, and I'd like to do some. I feel woe-fully underprepared to actually go for it. I tick a lot of the boxes in the postings I've seen, but my experience so far is heavily related to product development rather than applications.

What is a good dev board to use to get up to speed on intel based embedded apps?

# ? Dec 3, 2015 20:34

JawnV6: Jul 4, 2004; So hot ...

Barnyard Protein posted:

What is a good dev board to use to get up to speed on intel based embedded apps?

They're really pushing their Edison boards, what with the whole reality show. The minnow board is another option. If you're in the Bay I could give you mine. Shoot me an email at jawnv6@gmail or hit me up elsewhere.

# ? Dec 3, 2015 20:38

Luigi Thirty: Apr 30, 2006; Emergency confection port.

JawnV6 posted:

Pity.

I could write you an 8086 instruction set simulator in software though :v:

Luigi Thirty fucked around with this message at 20:52 on Dec 3, 2015

# ? Dec 3, 2015 20:48

Jerry Bindle: May 16, 2003

JawnV6 posted:

They're really pushing their Edison boards, what with the whole reality show. The minnow board is another option. If you're in the Bay I could give you mine. Shoot me an email at jawnv6@gmail or hit me up elsewhere.

Thanks for the offer, unfortunately I'm in the AZ desert for probably 2 more years. The Edison kit is basically a fully-fledged computer compared to the type of embedded work I have experience in. OTOH the job postings i'm looking at are looking for low-level stuff. Oh well, I'll buy the board to learn the stack and hold my breath

# ? Dec 3, 2015 20:59

carticket: Jun 28, 2005; white and gold.

minidracula posted:

It's premature, but I'm starting to really like STM32 parts, and the low-cost Discovery boards.

Has anyone here messed with or used the F3 line? Similarly, anyone have any trip reports on messing with/using ChibiOS (ideally on an STM32 part, but in general/on other parts is fine too)?

OK, so my complaints were as follows:

Didn't use CMSIS API
Rather than existing as a portable library, it kind of expects to take over most low level functionality (vector table, start up)
I was getting a crash from ISRs and not having the OS interrupt reschedule not be the last thing at the top level call. It was eventually destroying the stack. This was because they didn't use an interrupt scheme that scheduled a low priority interrupt to reschedule when fired like FreeRTOS does.
The OS depends on the HAL which depends on the OS abstraction layer which depends on the OS, so if you just want the RTOS without the HAL its a pain.
They implemented a bunch of things that aren't real-time, like FIFO scheduling rather than priority scheduling, which on its own isn't that bad, but the focus wasn't on real-time operation.
There also wasn't really a normal queue object as expected from other OS.
Mutex unlock could only unlock the last mutex that the calling task locked. It avoids some deadlock situations, and its not a terrible problem, just something I hadn't seen before.

So, it's not unusable, it was just difficult to use the way I wanted to. I considered forking FreeRTOS to be kinder on memory instead, but the project was killed before I got there. FreeRTOS has a focus on short critical sections and some features were long avoided due to potentially lengthy critical sections, and often this meant implementing things in such a way that used more memory. For me, memory usage was higher priority than hard real-time accuracy.

# ? Dec 3, 2015 21:27

Aurium: Oct 10, 2010

Mr. Powers posted:

OK, so my complaints were as follows:

Didn't use CMSIS API
Rather than existing as a portable library, it kind of expects to take over most low level functionality (vector table, start up)
I was getting a crash from ISRs and not having the OS interrupt reschedule not be the last thing at the top level call. It was eventually destroying the stack. This was because they didn't use an interrupt scheme that scheduled a low priority interrupt to reschedule when fired like FreeRTOS does.
The OS depends on the HAL which depends on the OS abstraction layer which depends on the OS, so if you just want the RTOS without the HAL its a pain.
They implemented a bunch of things that aren't real-time, like FIFO scheduling rather than priority scheduling, which on its own isn't that bad, but the focus wasn't on real-time operation.
There also wasn't really a normal queue object as expected from other OS.
Mutex unlock could only unlock the last mutex that the calling task locked. It avoids some deadlock situations, and its not a terrible problem, just something I hadn't seen before.

So, it's not unusable, it was just difficult to use the way I wanted to. I considered forking FreeRTOS to be kinder on memory instead, but the project was killed before I got there. FreeRTOS has a focus on short critical sections and some features were long avoided due to potentially lengthy critical sections, and often this meant implementing things in such a way that used more memory. For me, memory usage was higher priority than hard real-time accuracy.

Thanks for posting this. I've been thinking about working on a project that could use a rtos and it's hard to get a users perspective on the different options. Most of the things I find are more like "You could use this option, or you could use this other option" without really saying much of anything.

# ? Dec 5, 2015 02:25

carticket: Jun 28, 2005; white and gold.

I find FreeRTOS is the best option in most cases if you aren't paying, and is still a really good option if you are. Richard Barry doesn't try to overreach with it and the kernel is solid. The community support is really good, too. I think someone even made C++ bindings. I haven't had a problem purchasing third party middleware that works with FreeRTOS.

# ? Dec 5, 2015 03:13

Popete: Oct 6, 2009; This will make sure you don't suggest to the KDz
That he should grow greens instead of crushing on MCs; Grimey Drawer

So I'm being given the lead on the Atmel side of a new project at work. This will be my first chance at really taking over a project from the start and choosing my own path too implement.

We'll have an AVR micro working as a coprocessor to a main i.MX6 running Linux. This will be a mobile device of sorts and needs to support network upgrades. Does anyone have suggestions for how I can perform an upgrade to the Atmel chip from the i.MX6? The new i.MX6 and Atmel image I'll be in one monolithic image. I've only ever used the ISP interface to flash AVRs.

# ? Dec 6, 2015 08:31

travelling wave: Nov 25, 2013

Popete posted:

So I'm being given the lead on the Atmel side of a new project at work. This will be my first chance at really taking over a project from the start and choosing my own path too implement.

We'll have an AVR micro working as a coprocessor to a main i.MX6 running Linux. This will be a mobile device of sorts and needs to support network upgrades. Does anyone have suggestions for how I can perform an upgrade to the Atmel chip from the i.MX6? The new i.MX6 and Atmel image I'll be in one monolithic image. I've only ever used the ISP interface to flash AVRs.

The AVRISP interface is basically SPI with the AVR's reset line used as the chip select. If there's a spare SPI peripherial on the i.MX you could use that to upload new firmware. Alternatively, if the AVR can be pre-programmed you could use a bootloader to upload firmware over whatever interface you like.

# ? Dec 6, 2015 15:06

big shtick energy: May 27, 2004

Mr. Powers posted:

I find FreeRTOS is the best option in most cases if you aren't paying, and is still a really good option if you are. Richard Barry doesn't try to overreach with it and the kernel is solid. The community support is really good, too. I think someone even made C++ bindings. I haven't had a problem purchasing third party middleware that works with FreeRTOS.

Our companies next product uses freeRTOS on an STM32F4 with the HAL drivers from The Cube and it seems to work pretty well.

# ? Dec 7, 2015 19:27

Ika: Dec 30, 2004; Pure insanity

Is there some way of being clever in VHDL to determine at runtime which variable a switch statement branches on?

Currently I'm receiving multi-word commands over a bus, for the first word I need to switch on the command ID in the top bits of the bus value, and I store it in a local signal. Then for every additional word I switch on the local signal, to handle the Nth word of the command. I would like to do something like

code:

case (IsFirstWord ? rxdata(8 downto 1) : command(8 downto 1) is
when 0 =>
  case txselect is
    ....
  end case;

instead of what I have now, which splits up the logic for the commands into multiple locations.

code:

if txselect = '0' then
  case (rxdata(8 downto 1) is
  when 0 =>
    ....
  end case;
else -- txselect
  case (command(8 downto 1) is
  when 0 =>
    case txselect is -- >=1
      ....
    end case;
  end case;

I can't just store the full first word and parse it simultaniously with the second one, because I have to setup return data immediately.

Can I define some sort of signal alias which varies depending on a condition, or is there some way to use a variable which only is an alias and not a true var?

# ? Dec 21, 2015 11:42

carticket: Jun 28, 2005; white and gold.

As far as I know, a variable in VHDL is basically just an alias for whatever is assigned to it.

Are you sure there isn't a better way to do it if you rethink things? I would probably have a receive state machine with a command state and a payload state (with presumably a register for payload size) that has a counter.

# ? Dec 22, 2015 04:28

Ika: Dec 30, 2004; Pure insanity

I'm pretty sure there are better ways, I'm just starting to work with VHDL. I was told I have to write the payload is in the same clock cycle as the strobe signal is high, since it is read during the next cycle, which means I can't pipeline the command and use only one switch, which would vastly simplify things. I'm not sure how well the hardware compiler optimizes out unused code, otherwise I could dump the entire thing into a function that takes command ID and word ID as parameters, call that at two locations, and hope the compiler notices that the first location only needs the code for word ID == 0, and the second one only needs to use word ID != 0.

# ? Dec 22, 2015 13:28

carticket: Jun 28, 2005; white and gold.

You can use multiple switches without an extra clock cycle, it will just generate more complicated combinatorial logic for that register or whatever. Also, I believe most synthesizers are pretty smart removing unused logic, but if you write something the wrong way it doesn't actually appear unused.

# ? Dec 22, 2015 14:08

Ika: Dec 30, 2004; Pure insanity

Oh I know I can write multiple switches, that is what I am doing. I want to avoid having a switch for word 0 and a second one for the follow up words, because then the command parsing logic is split into two blocks. I wasn't sure if using a variable would work or if there was some other way of doing this without needing to use pipelining.

# ? Dec 22, 2015 15:47

JawnV6: Jul 4, 2004; So hot ...

Ika posted:

I'm not sure how well the hardware compiler optimizes out unused code, otherwise

It is far more aggressive at optimizing away unused code than any SW compiler you've ever used. I wouldn't use a word like "better" or "well" to describe it though.

Ika posted:

I could dump the entire thing into a function that takes command ID and word ID as parameters, call that at two locations, and hope the compiler notices that the first location only needs the code for word ID == 0, and the second one only needs to use word ID != 0.

I dunno what a "function" is in this context. But if you have two call sites with 0 for arg1 at the first and 0 for arg2 at the second, it really seems like you need 2 functions. Unless you're expecting to pass data between the calls or otherwise store state, in which case a function isn't going to help much besides obscuring what you're passing/storing.

# ? Dec 22, 2015 19:14

reading: Jul 27, 2013

Has anyone here worked with the Altera Cyclone V development board, the DE0-nano-SoC?

I cannot get most of their demo programs to run on the default linux install! Pretty ridiculous how poorly supported this stuff is. And hardly anything on the web, although I expect that for something esoteric like an FGPA dev board.

Is there an FPGA thread anywhere in the forums? I checked SH/SC.

# ? Dec 29, 2015 22:55

ante: Apr 9, 2005; SUNSHINE AND RAINBOWS

There's a Verilog thread that is very dead.

Yeah, FPGA toolchains suck. Like, a lot.

# ? Dec 29, 2015 23:14

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 00:22

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

reading posted:

Has anyone here worked with the Altera Cyclone V development board, the DE0-nano-SoC?

I cannot get most of their demo programs to run on the default linux install! Pretty ridiculous how poorly supported this stuff is. And hardly anything on the web, although I expect that for something esoteric like an FGPA dev board.

Is there an FPGA thread anywhere in the forums? I checked SH/SC.

yeah

i gave up when quartus shat the bed 4 times in an hour

if the only thing intel does w/ altera is make good fpga tools it'll be amazing

# ? Dec 29, 2015 23:19

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

«‹›53 »