|
Martytoof posted:Completely philosophical question: Entirely power draw. That, and if you really need some other component to operate slowly, you might need to pre-divide. Also, for all you MSP430-users out there: check out GRACE, the graphical peripheral setup tool included in CodeComposer. For anything where you only have to set things up once and then write other code, GRACE is great. Easy tutorials on how to get poo poo set up right for common use cases, it's all good. Also all buggy, but what can you do.
|
#
¿
Dec 20, 2012 22:41
|
|
|
|
| # ¿ Apr 29, 2024 06:25 |
|
|
Has anybody here ever used an avr xmega a series? Specifically, as a Spi slave, and specifically specifically as a spi space using DMA so you don't have to interrupt every byte? Interrupting every byte sucks. But the problem is the spi timing isn't guaranteed so there has to be a full DMA transaction per byte, a single shot burst transfer. And the DMAC disables a channel at the end of its transaction. So it seems like I'd have to interrupt every byte anyway to turn the DMA back on. Is there a way to get around this that anybody here knows?
|
|
#
¿
Aug 6, 2013 12:07
|
|
|
Yeah as long as your micro can rewrite its programming it's more than possible. Writing a custom boot loader is typically way easier than it sounds at first, too - you still get to write c and use all the hardware and interrupts and so on. That part of the code may have to live on a different section of flash is all. One more thing though - either relocate the heap for your boot loader code or don't use malloc in it, because the code you upload typically won't know the boot loader exists, and if the boot loader leaves a freelist or malloc structure somewhere the app code isn't expecting it can lead to some very annoying and hard to debug errors.
|
|
#
¿
Nov 1, 2013 16:06
|
|
|
A lot of chips will have gcc implementations. Some of the big debuggers and IDEs are based on them- like Atmel Studio for ARMs. All its toolchain is, is gcc and libavr. With all the weird and awful bugs that entails.
|
|
#
¿
Nov 15, 2013 04:05
|
|
|
SybilVimes posted:learning the quirks and oddities of a new system for every hardware platform. This is kind of the job description g an embedded dev though... Most of the time the only reason what we can't do isn't automated from uml is because chips are different and weird. It boils down to being good at reading data sheets and doing what they tell you, while having the knowledge and experience to call the data sheet/vendor/app note out on its bullshit.
|
|
#
¿
Nov 16, 2013 18:11
|
|
|
sund posted:What do you guys think of the mbed platform? I'd rather my low level peripheral driver turd polishing amounted to something more than some code with a funny API that will stagnate on my company SVN server. It seems pretty win/win/win for the company, me and the platform to adopt something like this at work instead of rolling our own everything. Personally, it comes off as maybe a little Arduino-like, but they could just be good at hiding the gritty details. Any experience besides laughing at the concept of an online compiler? I used it for a summer. It is laughably bad as an IDE, because it is shorty and slow and browser based so there's bad shortcuts and no debugging capability and honestly why else would you use an IDE? Having libraries to use is nice and all but they're also just glorified app notes and drivers of the sort you'd otherwise get from the vendors. There's no actual upside and dealing with the online ide is just way too lovely to make make up for it.
|
|
#
¿
Nov 18, 2013 03:22
|
|
|
Popete posted:I'm looking into options for a project I'm working on using an Atmega328. I'd like to have some sort of on board storage (NAND or NOR Flash maybe?) to store off data. Is this feasible for a small micro like the AVR Megas? What overhead and requirements am I looking at? If you guys have suggestions on interfaces or even devices to recommend that would be awesome. I don't need a lot of storage, but something persistent. What others have been telling you about using the flash as data storage is definitely true. Just to expand on it a bit - those chips have three distinct (and separately copy-protectable with fuses) regions of flash, the application region, app table region, and bootloader. The app table region lets you get away from having to deal with your code size as you continue development possibly expanding into your data and they meant it for things like sine tables, but it sounds like it'll do what you need. Word of warning though, it takes a really long time to execute a flash write. So don't do this anywhere remotely near things that are timing dependent. http://www.nongnu.org/avr-libc/user-manual/pgmspace.html should help you in your quest.
|
|
#
¿
Mar 4, 2015 13:52
|
|
|
The only thing that annoys me sometimes about protobufs is the variable length integer encoding which can get pretty annoying if you don't want to be doing dynamic framing, specifically because it's possible that the variable length encoding of a number can be larger than the number's native side - varints built from uint32s can be as small as one byte or as large as five, which is pretty annoying. Other than that they're really good though.
|
|
#
¿
May 27, 2017 17:08
|
|
|
I hate doing low power stuff on small boards. Where's this power going? Who knows and nobody wants to spend hours cutting traces and putting in a bypass to measure
|
|
#
¿
Jun 6, 2017 17:29
|
|
|
My current place uses kinetis studio and processor expert. This is the eclipse rebrand and codegen setup for NXP. It succeeded CodeWarrior which was also iirc a rebranded eclipse with processor expert. We're still using it even though after NXP was bought by Freescale they moved on to yet another setup which I assume is another rebranded eclipse. Meanwhile, processor expert doesn't allow you to do some things like enable the 48mhz oscillator to run USB independently from the main clock, has seven options for everything with half of them marked DEPRECATED, and is incredibly slow. Sometimes I hate my job. At least it's not Psoc or fpga tooling. We need to switch to plain old God Damned gcc, it's just a CM4
|
|
#
¿
Jun 8, 2017 01:18
|
|
|
Popete posted:Kinetis Processor Expert/CodeWarrior/Whatever the gently caress they call it now. It all sucks rear end, automated code generators are often more trouble then they are worth and they never properly deprecate or support old code. You'll upgrade your IDE one day and your project will be horribly broken because it forces you to use their new auto-generated libraries and you'll spend a week digging through the generated code/headers to find what is hosed now and you'll then forever have to remember to go in and make that fix every time you click the "generate code" button. This is my exact experience after being there for only about a month. Here are some of my least favorite parts of it, which are mixed between its eclipseness and its use of processor expert, in no particular order: KDS/ProcExp is incredibly unfriendly to collaboration: - Because Eclipse stores paths inside its project files, and because some files are stored in the kinetis local library inside the eclipse install, making many small modifications causes eclipse to change its project settings files. These have to be checked in to source control because more important things like build settings and what files are where are in them so you're constantly pointlessly churning these god damned project files - When you create new components or edit components in processor expert, it will autogenerate control files for you and physically put them in your source tree (these are files that are named after your component and contain boilerplate for enabling/disabling them, they're fine, whatever). But it will also add initialization and common files as essentially symlinks in your project to files that are stored in the Kinetis install, without copying them, and giving no indication of that fact. Their behavior is usually controlled by preproc macros generated elsewhere. And these have some important stuff in them that it's frequently necessary to look at because the docs are trash or nonexistent and you occasionally might want to modify - the vector table is defined here, the low power modes and clock generation is defined here, and it's good to look at what your options are doing. If you want, you can even edit this code! And it's edited, forever, in your eclipse install, applying to all projects that symlink in that file, and invisible to source control so nobody else has your changes. Have fun debugging why other people can't build when you're totally sure you checked everything in! KDS/ProcExp is incredibly unfriendly to build automation: - Basically all the above applies here, too: doing a build, especially if your build server runs linux and your devs run windows or vice versa, will often include rerunning processor expert's code generation, which changes a whole lot of files in the source tree, which is not something I'm comfortable with and is a pain to work around anyway - Eclipse does not have very good support in general for running headless builds and ProcessorExpert has even less; it used to have more with codewarrior but that's literally two rebranded eclipses from NXP ago ProcessorExpert is mediocre at best at code generation: - When you're making a configurator tool like this, you have two options you can take for it to be good: either you make drat sure it covers everything, or you document what it doesn't cover and expose well defined and supported places and hooks for users to write their own configuration. ProcExp takes the third way of covering about 95-98% of things (IME, YMMV, SMDFTB) but makes you think it has everything, leading to days of searching through slow mouse only unsearchable dialogs to find something like how to enable the internal 48MHz dedicated oscillator for the USB before realizing it just can't do it, and having to hack in configuration in and around what it's generated - It has two version of most components, which seem to work equally well but have differences in how they're called, like whether they take a pointer to some private data (which of course is always NULL) or not, and half of them say (Legacy) next to them. There's also some components that can only be configured as legacy components, like port settings for things like internal pull resistors. Finally, it's very difficult to search for solutions for these problems because when you search for processor expert the results you get are about 40% codewarrior, 40% people telling you this is deprecated and use the SDK, and then 20% actually useful. We're going to try and switch to the new route, which is a static SDK and (if we listen to them) something called MCUXpresso which is yet another rebranded eclipse, or (if we listen to me) biting the bullet and writing our build system in CMake so we are freed from this hell and able to do automated builds. This should be better but I'm suspicious because when you go to their website and try to get an SDK, you have to sign in and request an "SDK build" that involves specifying your host operating system. This better just be for analytics or I'll literally explode. tl;dr Tooling is the absolute worst part of embedded development.
|
|
#
¿
Jun 14, 2017 13:00
|
|
|
Mr. Powers posted:Kinetis talk: on the upside, the standalone KSDK is pretty good without generated code. Yeah and it almost adds to the frustration - we have a boot loader for the same product that uses the kinetis sdk and it's a comparative joy to work with, so simple. We're gonna switch the main project to it sooner or later because processor expert isn't really supported anymore and we already have an NXP soft device implementation that comes with its own CMSIS stack and a usb stack that also comes with its own sdk and CMSIS implementation and at least we'll be able to unify those. The really frustrating thing is that there's just no value add! This is a CM4 part, the code is already built using gcc, the only thing that using processor expert and kinetis adds is an inability to do easily replicated builds that don't pollute the source tree. I'm mostly mad at my predecessors for using this garbage in the first place.
|
|
#
¿
Jun 16, 2017 03:44
|
|
|
That part does look fine so I'd go deeper into how that uart_control function pointer is defined and all the rest of the behind the scenes stuff. At some point as a basic sanity check you could also hook a logic analyzer (you can get a $100 one from https://www.saleae.com/ that rocks) up to those uart lines and see what's happening on the physical level.
|
|
#
¿
Jun 16, 2017 13:10
|
|
|
I hate watchdog failures especially in RTOS systems. I hate dealing with them. God dammit. Some days this job makes me want to throw things
|
|
#
¿
Jun 20, 2017 22:34
|
|
|
The agony of building physical products: We had an ongoing issue with our bluetooth stack (an NRF52 that we communicate with in "serialization" mode, for those of you who've worked with it before). After a week of looking we narrowed it down to a specific device errata that has a workaround in the current software version for the device - but we're on software two major versions and multiple years out of date, and we want to ship this thing now, we can't spend a bunch of time updating this. No problem, we say, at least we'll add a bootloader to the NRF52 chip so we can do field upgrades (no, we did not have this capability before. This startup had some turnover recently.).Great! I did it and gave it to my boss and he said "oh make sure this can handle the case where the NRF52 chip doesn't have a bootloader on it because we've been running production for the past week and there's a couple thousand units already welded together."
|
|
#
¿
Jun 30, 2017 13:07
|
|
|
meatpotato posted:Can I ask which errata? #109 from this guy: http://infocenter.nordicsemi.com/pdf/nRF52832_Rev_1_Errata_v1.3.pdf Basically, the first byte of any DMA-driven SPI transaction might be corrupt depending on some timing issues related to waking up from sleep. This is pretty bad in general but in particular when in serialization mode where the only thing the code on the NRF52 does is translate SPI traffic into soft device calls.
|
|
#
¿
Jul 4, 2017 18:34
|
|
|
I did it, I made a cmake build system for our poo poo that 1) still works in our garbage eclipse variant 2) works cross platform 3) doesn't require said eclipse variant. hardware for a build server is on the way and it'll be a bit easier to build in tests now! And I don't have to use eclipse anymore! And me and my coworker are taking the time to go through and fix the ~250 build warnings! Things can get better!
|
|
#
¿
Jul 18, 2017 01:23
|
|
|
I'm using a kinetis at work. It's fine. Processorexpert is so drastically not fine that with the primary bringup done we've killed it and started just editing its hal manually. Plus side: it's dead. Minus side: doing any far reaching changes like adding more clock configs would require editing its heinous auto generated code. Guess I didn't need those 5 mA anyway
|
|
#
¿
Sep 27, 2017 00:00
|
|
|
CodeWarrior still exists but is no longer officially supported at least for most new micros. They wanted you to use Kinetis Development Studio, which is also a rebranded eclipse, with a (slightly different) flavor of processor expert for those. After they got acquired they switched again to something called MCUXpresso, which as far as I can tell is just a third rebranded eclipse, and now have a static API rather than a graphical configurator. Or maybe also some separate configurator tool. This is probably better because ProcessorExpert is 100% incompatible with modern software development but I'll probably never know because all our poo poo was done in PEx already. Atmel isn't really any better aside from having Atmel Studio which is I guess nice because it's a rebranded Visual Studio rather than rebranded Eclipse... but also who knows the degree to which Atmel is gonna continue to exist. Honestly I think mBed compatible Cortex-M4s should probably be the goto. They're cheap, they're ubiquitous, they're surprisingly capable of both doing a lot of poo poo and optimized low power modes...
|
|
#
¿
Sep 29, 2017 12:47
|
|
|
Mr. Powers posted:Just download/build against the Kinetis SDK and never look at processor expert again. Hopefully will do this soon. It's just kind of a hard pitch because it's essentially redoing bringup with all the bullshit that implies.
|
|
#
¿
Oct 1, 2017 16:42
|
|
|
Harik posted:Windows toolchain is avr-gcc under the hood. You could probably use the win10 bash4windows stuff and run makefiles nowadays and do the code in eclipse-CDT or whatever you prefer. Embedded Programming Microthread: Just blow your brains out
|
|
#
¿
Oct 25, 2017 12:54
|
|
|
It's intended for FIR filters, it's basically the next level of fused multiply-accumulate. Don't think they cared about many other use cases
|
|
#
¿
Nov 3, 2017 02:06
|
|
|
|
| # ¿ Apr 29, 2024 06:25 |
|
|
Private Speech posted:Yeah, those. Specifically the 256KB versions; it replaces a more expensive component, is ULP so power is not a huge issue and you get a whole MCU essentially for free. Why would you want to add programmable parts...
|
|
#
¿
May 28, 2018 15:43
|
|