|
csammis posted:
The msp abi provides all the functions that a real core would provide. Even something like shift left by a constant is routed through a function that jumps into a chain of shift left by 1 bit at the right point. Divli is division by a long integer. Even if it's outside hard_delay, are you using / or % anywhere else? You might have to pull the std lib in to get the mspabi, but removing the division would tell if that's the root issue.
|
#
?
Jan 20, 2016 19:24
|
|
|
|
| # ? May 12, 2024 14:56 |
|
|
Yep there's a division operator in the code, and removing that does clear up the .text section. Looks like the mspgcc compiler was only bringing in _udivmodsi4 and _divmodsi4 to handle that instruction. I guess the TI toolchain's ABI is all-or-nothing and the mspgcc toolchain is more stripped-down? The .data section is still overflowing. mspgcc is only bringing in the global objects in my code (the 0x36 bytes of space from main.o). The TI toolchain is bringing in that and then 128 more bytes of...something called impure_ptr. Any ideas what this represents? Googling is mostly yielding "HOW DO I MAKE IT GO AWAY" and not "what is it" which is what I'd really like to learn  code:
|
|
#
?
Jan 20, 2016 20:34
|
|
|
impure_ptr is newlib's pointer to C library state in struct _reent. An RTOS can reassign that pointer to your thread's local version in the context switching hook, allowing the elimination of reentrancy issues with the standard library. Chews up RAM, though, because each thread needs stdio buffers and other things laying around. The non-reentrant functions in the standard library expand to the reentrant versions that get passed the same shared state. Check out reent.h to see how they do it, though it's pretty cluttered with macros.
|
|
#
?
Jan 20, 2016 21:44
|
|
|
Microchip bought Atmel last week. We are back to PICs. But really, please don't mess with my AVRs.
|
|
#
?
Jan 22, 2016 00:21
|
|
|
Popete posted:Microchip bought Atmel last week. We are back to PICs. I've never met a PIC that I liked, mostly because the tools were terrible (software tools, and hardware tools). Debugging them is a bear.
|
|
#
?
Jan 22, 2016 01:14
|
|
|
The tools have gotten miles better in the last couple years. They're actually pretty good now. Debugging still sucks, unless you have a $150 ICD
|
|
#
?
Jan 22, 2016 05:03
|
|
|
ante posted:The tools have gotten miles better in the last couple years. They're actually pretty good now. We have the ICD3s at work and it still sucks. I haven't used MPLAB X, though.
|
|
#
?
Jan 22, 2016 07:17
|
|
|
Mr. Powers posted:I haven't used MPLAB X, though. Do iiiiiit.
|
|
#
?
Jan 22, 2016 07:20
|
|
|
I don't have any projects with PICs in them right now. All Cortex-M, and we use IAR, which would be really hard to beat.
|
|
#
?
Jan 22, 2016 14:26
|
|
|
I haven't been able to figure out the appeal of IAR, but I'm sure I must be missing something, and I do use it regularly at work for one of our platforms that exclusively supports it. What's the advantage of it compared to one of the GCC based tools with a much more modern IDE, like TrueSTUDIO or Crossworks? Keil I can understand not using because, oddly enough, everything I've seen indicates their compiler produces inferior code in size and efficiency. Also, I really like the idea of PICs, but even with MPLAB X and their better debug probe, I haven't found the experience of developing on one anywhere near as clean and pleasant as ARM with one of the above-mentioned IDEs and a J-Link.
|
|
#
?
Jan 23, 2016 05:28
|
|
|
IAR has improved their editor in the more recent versions, so at least they recognized that they were way behind in that regard. Their compiler does a pretty good job generating tight code, and its a nice integrated environment that you can use on a number of architectures. I think their debugger is fantastic when paired with good hardware (Segger J-Link), and is still great, if slower, when paired with things like OpenSDA hardware. Back on PICs, I guess I just haven't had many jobs where they are the part that makes sense. Power and size are big drivers for us, which you might think a PIC would show up a lot for, but then we also do a lot in the micro, so we need small and low power with more RAM and Flash than you can get in most low power parts. I do love the Kinetis KL series. The KL27 draws like 8 mA if everything is turned on at 48 MHz, and you can scale it down to a few hundred microamps at 4 MHz (no USB at that point, though). Crystal-less USB and ROM bootloaders are dandy, too. The series is nice, though, because they have the 0 series that really give the PICs a run for their money. Edit: added note about IAR: it was picked and we had licences before I started many years ago. I probably would have opted for something GCC based if I were deciding, but I try to be frugal even when it's not my money. I am pretty happy with it, and at this point wouldn't want to change. The IAR Eclipse plugin gives you a modern IDE, but there are some quirks to it. carticket fucked around with this message at 07:24 on Jan 23, 2016 |
|
#
?
Jan 23, 2016 07:21
|
|
|
I quite like PICs, though the side-effect of having so many hardware variants is that their testing of the silicon isn't as thorough as it should be. There are instances where the <main selling feature of a particular variant> is revealed in the errata notes to in fact, not work.
|
|
#
?
Jan 23, 2016 13:23
|
|
|
MPLAB X is a much better IDE but I didn't really like what they did with the debugger interface, especially the memory and fuse viewer/editor.
|
|
#
?
Jan 23, 2016 14:28
|
|
|
Speaking of the Cortex M, I'd like to get some experience on that line for a job I'm interested in. Any recommendations on dev boards for the M3?
|
|
#
?
Jan 23, 2016 19:12
|
|
|
muon posted:Speaking of the Cortex M, I'd like to get some experience on that line for a job I'm interested in. Any recommendations on dev boards for the M3? STM32 Discovery boards are super cheap. If you want M4 or M0/M0+, I'd suggest the Freescale/NXP Freedom boards which are also super cheap.
|
|
#
?
Jan 23, 2016 19:15
|
|
|
I've hardly used any PICs, as a young Embedded guy I basically hear about PICs as the go to chip forever but now there are a ton of great options. I've basically convinced my boss to advocate using AVRs pretty much exclusively when we need a micro. I love Atmels documentation and the parts are super simple to get up and running. Funny though, I did run into an odd naming thing with their new XMega chips. Apparently they took the acronym PMIC and repurposed it to be "Programmable Multilevel Interrupt Controller". I was really confused when I couldn't get my ISR to fire until I found a thread online talking about needing to enable Interrupt levels in the PMIC.
|
|
#
?
Jan 25, 2016 23:30
|
|
|
PICs are an odd thing. I can't really figure where they belong in the modern market now that ARM is what it is, aside from extreme low end stuff like the PIC10 (won't find a 6-pin arm in a SOT-23 package anywhere I've ever seen). They do have a lot of very specialized DSP options though, so there might be something there which I just never had a specific use for. Every time I look I find an ARM that's cheaper, lower power, and more powerful than the equivalent PICs. I will say though that I just keep a ton of PIC10 around to extremely simple glue logic in prototypes. Mr. Powers posted:STM32 Discovery boards are super cheap. If you want M4 or M0/M0+, I'd suggest the Freescale/NXP Freedom boards which are also super cheap. Second both of these. Also I've recently been playing with the Silicon Labs EFM (used to be Energy Micro) processors and I really like them a lot, even more than ST or Kinetis parts so far, both of which I've used extensively. It's just a very well thought out processor. They have low cost dev boards too and seem to hit every mark perfectly (price, low power, functionality).
|
|
#
?
Jan 26, 2016 05:58
|
|
|
EnergyMicro was lacking in compact packages last I saw. That and for most things we do they were too low on RAM.
|
|
#
?
Jan 26, 2016 06:11
|
|
|
Well, they definitely had packages small enough for met to fit in a keychain I designed just fine, but not a huge selection of WLCSP or other ridiculously tiny packages that you'd need for super high density stuff (although they do have some). They are lower on RAM on average than something like STM32, if you're doing something beefy that needs all that, and they don't have the high memory with a small package like ST does. Most of the projects I get involved in I either need only a few KB, or I need a few megs of RAM. What I've really been happy with though are the peripherals. They just do what I want, and have a lot of good analog stuff for sensors. That may be coming from getting burned repeatedly by the absolutely terrible peripherals on the low end Kinetis though...
|
|
#
?
Jan 27, 2016 04:14
|
|
|
The newest KL parts have nice peripherals, just few, and the drivers have bugs.
|
|
#
?
Jan 27, 2016 05:18
|
|
|
Processor expert last time I used it was buggy as hell. It was extremely annoying anytime I ran PE I had to go back and make the same driver code changes in order to get it to even build.
|
|
#
?
Jan 27, 2016 17:03
|
|
|
Yeah, I just don't use that. Newer versions of the KSDK are really easy to just use directly and not deal with generated code. That doesn't excuse the bugs in their driver code, though.
|
|
#
?
Jan 27, 2016 17:20
|
|
|
Is there a better thread to ask about BLE? I need to get 8 bytes of device-specific information from my firmware to a mobile client. Because the BLE stack is finicky, stuffing it into the Device Information Service / Serial Number String is causing headaches because it has to pair. I want to broadcast the information in the advertisement packet, or failing that into a scan response. I'm not seeing space in the adv packet itself, is scan response my best bet?
|
|
#
?
Jan 27, 2016 23:25
|
|
|
I used to know a lot about BLE but I've forgotten a bunch! As you probably know, advertising and scan response packets' payloads are a series of structures (called advertising data) with the following format: code:https://www.bluetooth.com/specifications/assigned-numbers/Generic-Access-Profile Any of these types can be put into either advertising or scan response packets, but it makes sense to put the "high priority" stuff in the advertising packet. The maximum size of the payload of a BLE advertising/scan response packet is 31 bytes. Depending on what you've already got in your advertising packet (perhaps a 128-bit UUID?), you might need to put your 8 bytes of data into a scan response packet. AFAIK, the type of advertising data to use is "Manufacturer Specific Data". Unfortunately, your company will need to register with the Bluetooth SIG to get a company ID, which is required to use this type... stupid. Fortunately, I think it's free to register.
|
|
#
?
Jan 28, 2016 03:20
|
|
|
meatpotato posted:I used to know a lot about BLE but I've forgotten a bunch! This is great information, thanks! I've been avoiding BLE in depth, but can't afford that luxury any more.
|
|
#
?
Jan 28, 2016 18:45
|
|
|
Wtf, I have an entire 4 KB of RAM on this PIC18 but Microchip decided that there isn't enough to bother implementing malloc. I guess I'll just let this big-rear end buffer that I don't need outside of one function call to sit around in global space with its thumb up its rear end when it's not needed
|
|
#
?
Jan 29, 2016 14:29
|
|
|
https://www.youtube.com/watch?v=WAu2V8GakE4 (tongue firmly in cheek)
|
|
#
?
Jan 29, 2016 14:31
|
|
|
I actually wrote malloc years ago as an excercise. I don't have the source anymore though. However it might be a moot point since I'm not sure I'm going to be using a whole lot of RAM outside of this one place. But lack of necessity has never stopped me from doing something pointless and impractical before. While I'm at it maybe I should hook up an SPI SRAM chip and implement paging  Edit: This one PIC18 line (PIC18F26J50 et al.) was some weird testbed for a bunch of stuff that Microchip wanted to try out. For instance it was one of the first PIC lines to have selectable digital peripheral pins. It has an SPI DMA feature that has never been seen on 8-bit parts since that would actually make paging not entirely painful BattleMaster fucked around with this message at 14:40 on Jan 29, 2016 |
|
#
?
Jan 29, 2016 14:36
|
|
|
Well, if you need a big buffer and you want to malloc it, that means you need a giant heap, which if you aren't using for other things that are mutually exclusive then you just end up eating that memory anyway.
|
|
#
?
Jan 29, 2016 16:56
|
|
|
Yeah that's true. I think I'm more annoyed by the fact that the function is defined, doesn't compile with a cryptic error, and it turns out they decided you never, ever need it on an 8-bit micro.
|
|
#
?
Jan 29, 2016 18:31
|
|
|
But how would you know where something is in RAM on a reboot if it's dynamically allocated? 
|
|
#
?
Jan 29, 2016 18:59
|
|
|
malloc() is easy, free() is hard.
|
|
#
?
Jan 30, 2016 03:23
|
|
|
Has anyone used non-Altera EPCS devices with their FPGAs? Cyclone IV E in particular? I scrubbed through the instruction sets of my proposed alternate, and I think it will work (meets AC timing, etc.) as a configuration device, but will not work with the stock Altera Serial Flash Loader (SFL) as the Silicon ID will not match. AFAIK though, the FPGA's silicon doesn't perform any kind of ID check and just tries to go read data from whatever serial memory is attached. I'll probably have to write my own loader that gets chunked on there via JTAG, and then uses a virtual JTAG interface to program the SPI memory (so the same way the SFL does it), but wondered if anyone here has tried it yet. I've got a DE0-Nano board on the way that I'm going to rework my memory onto, and see if it still boots.
|
|
#
?
Feb 5, 2016 10:49
|
|
|
I think we just use the Micron M25P series with our Spartan 6's, and I've used an MT25P with a Lattice ECP5. I'm pretty sure we did something similar on older Cyclone III products, but I can't say for certain. Unless Altera is an outlier, they all pretty much comply with the standard SPI flash interface.
|
|
#
?
Feb 8, 2016 08:49
|
|
|
I actually do a roll-your-own malloc() in a lot of my projects. There's no free() that goes with it - I just use the allocator a bunch of times during initialization, and then never call it during normal operation. It's a nice tradeoff because it gives most of the flexibility and power of run-time memory allocation, without the overhead of a 'real' malloc. And since I don't actually want dynamically allocated memory after initialization, I don't need a free(). code:
|
|
#
?
Feb 8, 2016 17:54
|
|
|
My solution was a bit simpler. I created a couple of big scratchpads that are used by different functions that never call each other and are never called by interrupts so there's no risk of them stepping on each other. I could have made them local so they're on the stack but stack operations are pretty nightmarish on PIC18s without the advanced instruction mode that isn't enabled in the free compiler.(and on top of that the buffers are bigger than the stack frame the hardware supports)
|
|
#
?
Feb 8, 2016 20:09
|
|
|
I'm having issues trying to piece out what happened after a watchdog event (X). I think I'm XY'ing this pretty hard, so please feel free to suggest some other method for solving this. Working with an Atmel SAMG, IDE is Atmel Studio 7. I need to specify a variable that will not be re-initialized to 0 or any other value on reset (Y). The watchdog is set up as an ISR. I can pause there and verify that it has access to the stack and pull variables into RAM. I'm calling NVIC_SystemReset at the end of that. Values are still in RAM after reset. And promptly cleared out by the reset handler. My first declaration was: code:code:Looking through the linker output, there aren't any RAM locations/variables left untouched by the reset handler. There's the relocate segment, which starts at the base of RAM and ends at the zero section, then the zero segment, then the stack. There's no clear place announcing "Put terrible un-initialized values here". How do I put something outside those segments, but still in RAM?
|
|
#
?
Feb 10, 2016 20:23
|
|
|
JawnV6 posted:I'm having issues trying to piece out what happened after a watchdog event (X). I think I'm XY'ing this pretty hard, so please feel free to suggest some other method for solving this. Working with an Atmel SAMG, IDE is Atmel Studio 7. The .noinit section is what you want - it should be located into its own section in RAM, and be readable/writable but not touched during startup. If it's being linked into flash then your linker script is screwy (link to it here so we can take a look) and if it's being trashed by the startup code that is also screwy (same deal, link to it here).
|
|
#
?
Feb 10, 2016 21:35
|
|
|
I'm not familiar with your specific IDE, but in the past I've done similar things to keep warm-boot-persistent data alive. You may need to get down into the guts of your memory section layout and make sure that the section you want to place your data in isn't munged by startup code as EpicCodeMonkey mentioned. I've created completely new sections in the past so I didn't have to change my startup code (I'm not great at asm), then initialized the data in a call before the main loop. Usually I place some kind of sentinel magic series of bytes at the beginning of the memory section so I can tell it's not clobbered and update a checksum at the end of the section every time I write to that memory. In the check before the main loop if either of the magic number or checksum checks fail, I zero the section out. (Hopefully) this means the system just cold booted.
|
|
#
?
Feb 10, 2016 22:04
|
|
|
|
| # ? May 12, 2024 14:56 |
|
|
EpicCodeMonkey posted:The .noinit section is what you want - it should be located into its own section in RAM, and be readable/writable but not touched during startup. If it's being linked into flash then your linker script is screwy (link to it here so we can take a look) and if it's being trashed by the startup code that is also screwy (same deal, link to it here). I'm smuggling it through the signature flash area because I need to kick off this long running test soon, when I get to trying the proper solution I'll post the full script here. I've been meaning to ask, are you alright after that $3.6b check cleared? meatpotato posted:I've created completely new sections in the past so I didn't have to change my startup code (I'm not great at asm), then initialized the data in a call before the main loop. Usually I place some kind of sentinel magic series of bytes at the beginning of the memory section so I can tell it's not clobbered and update a checksum at the end of the section every time I write to that memory. I'll use a magic number check in the finalized thing, especially when I'm solving for a boot loader instead of "what peripheral hangs near 0 degrees" Thanks to both of you for the help!
|
|
#
?
Feb 10, 2016 22:37
|
|