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

«‹›2 »

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

There's an ARM version of the TI Launchpad coming out shortly as well; notably, it's based on a Cortex M4 which has an fpu! http://www.ti.com/ww/en/launchpad_site/stellaris.html?DCMP=stellaris-launchpad&HQS=stellaris-launchpad-b

# ¿ Aug 12, 2012 15:55

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 17:47

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Also the OP should probably talk about PIC at greater length and mention 8051s which are still pretty common

# ¿ Aug 12, 2012 15:57

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Pham Nuwen posted:

Also, I'd like to point out that you don't need to spend $30 on an Arduino, depending on what you're doing. I built a 7-key USB chording keyset around an AVR chip (same as they use in an Arduino); aside from the $3 chip, IIRC I only needed a few resistors, a diode, and a crystal oscillator--total cost, probably $5-8.

And a serial programmer.

# ¿ Aug 12, 2012 16:41

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

hobbesmaster posted:

Speaking of rat shack, they actually have arduinos in their physical stores!

Some of them do. Others are just cell phones, as far as the eye can see

# ¿ Aug 13, 2012 01:35

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Arcsech posted:

Anybody here used Cypress PSoC? I'm working in an embedded project at an internship this summer, with a fair mix of analog and digital stuff using the PSoC 3, which is basically an 8051 with a small FPGA and some analog hardware (op amps, PGAs, and comparators come to mind, plus some really cool internal signal routing hardware) stapled on. It's pretty easy to use, not Arduino easy but more so than, say, the MSP430.

(Edit: disregarding the recent port of the Arduino stuff to MSP430, Energia)

Although once you start pushing the limits of the internal routing, wrestling with the software to get it to do what you want can be difficult and basically requires understanding the layout of said internal signal routing hardware. Fortunately, they just updated PSoC Creator to include a feature that makes this much easier.

Ahahahahahahahahhaha yes, I will regale you with tales later

# ¿ Aug 16, 2012 01:36

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Xpost from the electronics thread for a wider audience: Anyone know of a good USB-to-serial chip like the FT230 series that works as a USB CDC device without a driver install?

PS I haven't forgotten about the writeup about the PSoC that I promised somebody

# ¿ Aug 23, 2012 17:09

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

I'm surprised the Freescale ARM stuff isn't cross platform; the HCS08 stuff I sometimes use at work is all based on Eclipse these days.

# ¿ Oct 19, 2012 02:40

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Extra aside: I know I promised a real review of the PSoC a while back. Here's the abbreviated version:

- The libraries they provide are generally real easy and less buggy than the average embedded library in the classical sense, although there are many semi-documented assumptions that are made (eg. that your CPU clock at run time is the same as your bus clock was at design time) that can bite you in the rear end. Also they use camelcase which is kind of grating but whatever.

- The digital stuff is almost spectacular. While their logic blocks don't really comprise the "mixed signal FPGA" that they try to sell it as, they are often very useful.

- The DMA capabilities are awesome.

- Power usage is kind of meh. Pretty much dead average.

- The analog spec is a lie through and through. Every word of it. Including "and" and "the". And even the parts that resemble the truth are full of annoying limitations. Especially PSoC 5, which is basically evaluation silicon masquerading as a product. The PSoC 3 on the whole is much more mature and generally works the way it is supposed to, although there are some bugs and limitations that effect both.

# ¿ Oct 19, 2012 02:49

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Martytoof posted:

I'll be more than happy to run this all in a VM. Again, my main problem is a lack of clear instruction for people who aren't already terribly familiar with embedded development. It's nothing I won't be able to overcome since I like to think I'm a pretty bright guy, but there's so much specialization where every board developer recommends their own set of tools, etc.

This is the biggest pain in embedded development in my opinion. Everyone vendor has their own special snowflake one-off half tested development toolchain. This poo poo factors into business decisions, by the way - once you have a couple of developers that are comfortable with the toolchain for a particular chip, it's pulling teeth to switch to something else for another project after they've already learned the ins & outs & quirks & register names.

FWIW, CodeWarrior is pretty slick once it's configured (it has something like CTags/CScope built in), and if they haven't changed the debugger from the one that I've used it's about the best there is.

# ¿ Oct 19, 2012 02:53

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

PS Cypress' programmer costs a hundred bucks because they threw an fpga in it, hehehehe

# ¿ Oct 24, 2012 20:52

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Besides bitwise operators, at some point it will probably be useful for you to learn how unions and bitfields work (both of these get used a lot more in an embedded context than in a 'regular' systems-programming context).

oh, and TURN OPTIMIZATIONS OFF GLOBALLY and reintroduce them with pragmas where you need them if you're sure you need them. This will save you headaches.

# ¿ Oct 30, 2012 18:19

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

My Stellaris boards (Cortex M4F) came in yesterday. Good times.

# ¿ Nov 10, 2012 15:11

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Man state of charge is a pain in the rear end

# ¿ Nov 13, 2012 15:35

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Any decent profilers for ARM that I could interact with via JTAG or SWD?

# ¿ Nov 29, 2012 15:47

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Martytoof posted:

ST is giving away free STM32F3DISCOVERY boards, apparently. I have one of these and it's pretty nifty. Cortex M4, has an integrated ST-Link SWD USB interface that you can decouple from the project board and use to probe any other ST projects you might have (and apparently unofficially other vendors' Cortex MCUs, but I haven't tried yet).

Link is here: http://www.st.com/internet/evalboard/product/254044.jsp

THanks for linking this

# ¿ Nov 30, 2012 16:15

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

peepsalot posted:

what's my best bet for some dead simple data storage to interface with msp430, on the order of a couple mega bytes of data?

There are a bunch of memory chips in that size range that you can talk to via SPI or I2C pretty easily. Whether it's best to go with EEPROM or flash or FRAM boils down to your requirements for write endurance, speed, cost etc

# ¿ Dec 8, 2012 00:23

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

movax posted:

Totally missed it, but it does look pretty slick, and I think it'll be fine for hobbyist/etc use. The configurable blocks are pretty slick; need a ton of PWM for motor control? No problem! gently caress ton of SPI/I2C for weird reasons? Still good!

Paging Otto to this thread to rant about how the PSoC has screwed him over repeatedly (though I think he was having problems with a specific version).

<-------------------

I and my coworkers have certainly had plenty of issues with the PSoC 5.

The worst of these have been on the analog side of things. There are "unpleasant" stability issues mostly stemming from the Delta-Sigma ADC component misconfiguring its charge pump clock, and unrepeatability issues related to a whole host of clock interactions unforeseen by their design team and an input buffer with numerous nasty issues including what looks like a race hazard (if you can tolerate bypassing the buffer for your application, do so; we couldn't). While some of these issues exist on the PSoC3, they are roughly 4x smaller in magnitude based on the measurements I and a couple of coworkers and some engineers at Cypress have done. This is a recurring theme in PSoC land: the PSoC 3 has some warts but is generally a working and finished product, whereas the PSoC 5 is engineering silicon that you get charged money for.

On the digital side, things are generally much better but there are still plenty of annoyances. The UDBs are great (although confirm the maximum voltage and current and slew rate ratings on inputs and outputs thoroughly by empirical means before you believe that datasheet!) and the DMA capabilities are fantastic, but many of the stock components are poorly coded, generally assuming that

nothing has changed at run-time from design- or compile-time settings (many components, eg the SD card component, break if you change your master clock to save power and provide no way to tell them you've changed clock speed or provide an external clock that doesn't change) and
no error conditions will ever occur, and if they do deadlock is an acceptable way to handle them (the code for many components is riddled with infinite loops, eg. the I2C component will get stuck forever if it misses an ACK, there is no way to set a timeout, and the normal hooks that most components provide in their source are not present so you can't fix it yourself without rewriting the whole thing)

On the other hand, this has given me a great education in how to implement a watchdog :rimshot:

There are of course some weird quirks and bugs with PSoC creator itself that are mostly in line with what you see in freebie embedded environments - the rubber banding of components gets confused and shits itself more often than not, if you delete or rename a component it leaves the generated source with the old name hanging around in the generated source directory but removes it from the project (this leads to fun errors - once I had an input to an Amux called 'Battery'. I changed the name to Vbb. I later created some routines to calculate percent charge remaining based on a calibrated discharge curve and put the code in src/routines/battery.c and the constants in include/routines/battery.h. battery.c wouldn't compile for the longest time, saying that none of the constants defined in battery.h were defined. This was because somewhere in the generated source directory, there still lingered a Battery.h from when Vbb had been called Battery which was getting included instead), every time I start up my TopDesign.cysch seems to be at a different zoom level, the .cyprj file generates merge conflicts incessantly and generally is a good example of how not to implement and XML-based file format, phantom errors are sometimes generated on builds that disappear when you click their item in the notice list, the debugger gets easily confused, can't step over a breakpoint or into a function reliably and even loses track of the program counter(!)(this was all fine in Creator 2.0 but broke in 2.1), etc etc.

There are also a bunch of acknowledged errata and limitations of the PSoC 5 that are supposedly getting fixed in the upcoming LP version of the silicon. I'm not holding my breath, and after chasing ADC issues for a couple of months and farming out half the crap we had wanted the PSoC to do back to dedicated external chips due either to limitations or errata (eg. USB is now handled by and FTDI chip in our design), we're not going to bother with other products of theirs where I work. Sorry to the two apps engineers who were immensely helpful and tirelessly fought to have problems fixed before being told to work on other things because we weren't a high enough volume customer to be worth the time.

All this being said, I wouldn't worry at all about using a PSoC for a hobby design.

At home you don't give enough of a poo poo about power to downclock dynamically, so a bunch of component issues go away.

At home you can turn the thing on and off if something gets stuck in a loop so you don't care if a component deadlocks because some jackass in Bangalore thought while(1) was the greatest thing since sliced bread.

At home you don't need 17 bits of noise-free resolution from a 20 bit ADC with perfect linearity (after correction) and no offset (after correction) and no hysteresis and no tempco (after correction) and by the way could you give me ten updates a second after filtering, oh wait I meant thirty how silly of me!

and so on.

# ¿ Dec 19, 2012 03:00

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Why not use a named FIFO or a socket?

# ¿ Dec 21, 2012 21:42

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Martytoof posted:

JTAG question:

If I want to use a 5 pin JTAG connection to program/debug a Cortex MCU on a dev board, should I be powering the chip from the JTAG adapter (it provides 3v3) or should I be powering the chip from its own power supply, or does it not matter as long as the chip meets minimum running voltage requirements?

I'm going to be wiring individual cables from my Bus Blaster JTAG card to my Cortex dev boards. I suppose I can either hook up the 3v3 line from the Bus Blaster and hook it into Vdd, or I can not hook up the 3v3 line and power the MCU boards over USB like I normally would.

I'm scouring datasheets for information so I avoid blowing my BB or MCU but so far programming info seems vague at best.

(I'm specifically not using SWD because the Bus Blaster needs to be re-flashed to support SWD and I don't really want to complicate things right now)

You can do either but just powering the chip from its own supply is probably the easiest and most foolproof thing. Nb you won't be able to do profiling without the ETM pins and you may need a 20-pin connector to accomodate them instead of a 10-pin (but you may not care about profiling).

# ¿ Dec 22, 2012 02:11

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Anyone done SIL systems before? Is it as painful as it looks?

# ¿ Jan 7, 2013 20:35

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Delta-Wye posted:

Here is a weird question that I thought someone here may have some insight off the top of their head. When I'm doing embedded programming (say, MSP430) I usually use the smallest datatype available. If I know a value will fit into a char, I'll use a char, even if I am not particularly memory constrained. That is to say I don't just hold ASCII characters in a char datatype, but use it as a 8-bit integer. Supposedly this doesn't work very well on a platform like the MSP430. I was told that the 16-bit processors will read a 16-bit value out of memory, mask it to an 8 bit value, do the required operation, then have to mask it again with the contents of memory when storing it. Needless to say, such masking operations would add computational overhead so if you are not memory constrained it is more computationally efficient to use a 16-bit (int) value.

I haven't taken the time to dig up documentation that specifies one way or the other, or compile c code to assembly and see what it is doing, but am interested if anyone has insight. If it adds a ton of overhead, this would be a counterproductive habit I should break because I am rarely that memory constrained. For cases like a massive array of 8-bit samples or something, the computational overhead may be acceptable, but otherwise I've been doing a very silly thing.

On any given platform, loads, stores and integer operations will be fastest on datatypes that have the same width as the machine word. Some architectures provide explicit instructions for loading, storing and operating on half words or bytes or whatever, either for convenience or for speed. I wouldn't bother worrying about this until you found some bit of code you're working on where you need to perform X operations in Y ms but are currently taking 2Y ms and the generated assembly looked like it was wasting time marshalling and demarshalling bytes into 16-bit words or whatever. You're much more likely to be wasting time doing something like blocking on a slow peripheral or polling vs waiting for an interrupt anyways, at least in the code I've worked on.

# ¿ Jan 21, 2013 00:19

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

The arduino libraries aren't the only bad I2C routines out there.

# ¿ Jan 22, 2013 02:44

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

e: didn't see movax's post, this is re: Victor

Haven't seen your code. Hope it's good. I2C is simple enough but it gets screwed up often. My recommendation is that you provide versions of your functions with specified timeouts.

In my post, however, I was referring to Cypress' I2C routines for the PSoC 3 and 5, which have a similar flaw that looks like

code:

...

send_a_thing();
while (!BIT_IN_A_SFR_WHICH_INDICATES_AN_ACK_WAS_RECEIVED);

...

Thus, if the slave doesn't get the first byte, it will hang forever waiting for a response that isn't coming. As I mentioned in an earlier post that consolidated my many and varied complaints about Cypress Semiconductor and the products thereof, on the bright it serves as a good excuse to gain experience with the implementation of a watchdog timer :v:

Blotto Skorzany fucked around with this message at 04:16 on Jan 22, 2013

# ¿ Jan 22, 2013 04:14

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

movax posted:

Everyone reinvents I2C libraries all the time, and some of the app notes companies put out have sample routines that aren't entirely production-level robust. IMO more companies should be putting out "offical" software libs / "extensive samples" for use by their customers. It can't take much more than 1 or 2 Sr. SW engineers + a week or two to release (even warranty-less) well-written, solid, interrupt-driven serial comm code for SPI/I2C and friends.

Yeah, this and fixed point arithmetic are two wheels that get reinvented as octagons all the time, it's almost comical. :sigh:

# ¿ Jan 22, 2013 04:15

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

I have never been to a Radio Shack that had discrete components or ICs. I thought they were the stuff of myth

# ¿ Jan 30, 2013 15:35

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Who gave you the george clooney avatar, Victor?

# ¿ Mar 25, 2013 03:35

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Disnesquick posted:

CAN/LIN does look the business however, it seems to be pretty much what I'm looking for and there seem to be a few AVRs with hardware support. Cheers.

You might want to use the 2515 + 2551 or similar with a regular AVR rather than the 2551 (or some other CAN transceiver) with a CAN-capable AVR . They're pretty easy to use and it's more cheap poo poo to blow up if something is miswired instead of blowing up your micro :v:

# ¿ Apr 12, 2013 21:40

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Make sure there are no poles in the right hand side of the s-plane. Boom, stable :tipshat:

# ¿ Apr 25, 2013 21:19

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

IMO licensing and curation are very difficult issues for you given your stated goals, with curation being the greater of the two (think of the issues CPAN and similar have). I would also expect that you'd have a problem wherein people who are competent enough to write correct DSP building blocks also know about DSP chips and use them preferentially where speed is needed.

# ¿ May 7, 2013 21:13

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Martytoof posted:

I'm curious how the adoption of something like the Arduino Due with an 80-something MHz Cortex M3 affects the above. Still no FPU AFAIK, but more cycles to spare.

Yep, none of the M3 variants have an FPU

# ¿ May 7, 2013 21:14

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Victor posted:

Hell, the use of digitalWrite(pin, level) could have been implemented via digitalWrite<pin>(level), avoiding the insane number of cycles it takes to write to a single pin.

There is a tradeoff here, and it isn't necessarily one that everyone will want to make. The writer of that blog didn't really profile anything (hard to blame him since it isn't super easy to profile code running on an Arduino), but there are several distinct things that lead to that function being as slow as it is. The runtime checking is excessive, the excessive runtime checking and several other runtime configurations are done inefficiently, some of the safety could be better provided by the type system (eg. checking they passed a valid pin), etc, but claiming that templates are The Answer is a bit naive. The Atmel chip in the larger Arduinos has what, 64ish GPIO pins? You probably don't want to duplicate even a small function 64 times if code space is tight.

# ¿ May 9, 2013 22:16

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Victor posted:

Maybe I'm not being clear enough. Consider if we made the following changes to Arduino:

make the libraries robust and well-designed

provide a proper build system

provide motivating examples of using the various peripherals, demonstrating good coding and design style

provide makefiles and perhaps project files for a few IDEs

How much better do you think this would be? We can throw in more capable hardware and things don't change too much. You'll probably have to enable clocks to various peripherals and DMA can get a bit tricky, but that isn't needed from the get-go.

Writing better software, using an actual build system (even if it's just a makefile), and being able to consult datasheets is definitely a step up and maybe I'm not being clear enough on that. What I'm saying is that these things can be made easier than they are, and we need not demand intricate knowledge in order for someone to get up-and-running, with a solid foundation to work on. There's just no reason to e.g. provide new users with peripheral libraries that don't expose all the errors so that it's as easy as possible to troubleshoot problems.

Part of this may be due to a huge personality difference between folks like Jawn6V[sic] and myself. I like to dig into something head-first, learning the various bits and pieces only when I need to. Oftentimes, bad software and hardware design requires you to know far more details than is theoretically required, for a given task. I wouldn't be surprised if Jawn6V[sic] doesn't mind reading through a datasheet in a bookworm fashion, which would mitigate some of the issues I've raised.

There are a few points here.

The first half of this seems to be about building a dev board that is essentially a better Arduino in terms of quality, which is a great goal, albeit one that is already partly and imperfectly filled by things like TI's Stellaris launchpads.

The second half seems to be about building a dev board with greater capabilities than the Arduino, which is where the questionable utility resides. For instance, suppose someone wants to do serious signal processing or process control. The Atmel chip that (most) Arduinos use doesn't have the horsepower for this, and not only due to its lack of an FPU and non-astronomic clock. It might at first seem that a more powerful dev board would be useful, but hold your horses. The type of person who has these problems knows what a Fourier transform is, otherwise they wouldn't know how to implement or use one, or probably even that they should use one (for a lot of process control problems you would actually want a laplace transform, but whatever). You don't learn these things without picking up a bunch of other EE knowledge along the way, or at least relatively few people do. If you know about PID control, you probably know there are ICs that handle the PID stuff on their own that cost very little and are easy to use. If you know about signal processing, you probably know about a zillion types of micro, and about DSP chips, and you probably want control over how poo poo is laid out.

This is the no-mans land that Jawn was talking about - there is demonstrably a lot of demand on the very low end, and a multibillion dollar industry on the high end, but there are good reasons to believe there isn't much demand in the middle. It's possible that this is a niche that's waiting to be filled, but the odds look to be against it. Furthermore, apologies if I sound like an rear end in a top hat or an "elitist" in saying this but it stands to reason that if this niche were to be filled competently, it would be by someone who doesn't think PCB layout is wizardry. You have a reasonably good background in programming, Victor, and you seem to have picked up on a fair amount of the math needed for control systems in your quadcopter ventures, but if you think this opportunity is real and are sure you want to do this I think you're going to have to bone up on the fundamentals of electronics engineering. I recommend The Art of Electronics if you elect to go this way.

e: another point here is that PCB layout is kind of annoying, but in many contexts just isn't that hard - this is another thing that eats away at the middle end of the market as it were.

Blotto Skorzany fucked around with this message at 22:34 on May 9, 2013

# ¿ May 9, 2013 22:31

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Delta-Wye posted:

Curious what exactly you mean by "scoping functions". Are you referring to public/private or seperation? I'm pretty sure you can recreate that by encapsulating a function inside of a library that is a separate .c/.h file by simply not exporting the private functions in the header file.

Probably he means using classes as ersatz namespaces.

# ¿ May 15, 2013 15:26

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Most of the ARM vendors' IDEs will use one of the variants of gcc-arm as the compiler (some will use Keil, which is a worse compiler and has an annual license fee and needs to phone home to a license server or some poo poo). It's possible to use the GCC ARM toolchain without an IDE if that's your thing (although using gdb with no IDE wrapping it feels like stepping into 1970). I believe STM and TI both ship free IDEs; my own professional experience with ARM is with Cypress's PSoC and its PSoC Creator IDE, which I wouldn't wish on anyone (although the LP did improve the situation considerably).

# ¿ May 15, 2013 20:54

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Victor posted:

Ok, I'm sick and tired of waiting for my STM32F4xx to flash just to test a small change in code. Because this ARM chip is von Neumann, why not just load that small bit of code into SRAM—maybe even the core-coupled memory (CCM) which we aren't using at all right now. (We probably should because it has zero wait states, compared to the flash's five.) Why not link individual functions with the currently on-flash code, but locate them at a known location in the CCM? (Really, it can go anywhere in SRAM, but putting it in CCM isolates it especially well from stuff like stack overflows and so forth. Maybe not important, but sometimes I'm paranoid.)

The way I imagine this working is to have, at bare minimum, two functions on flash:

A loader for CCM code, replete with CRC32B checksumming. I'll probably do it over XBee.

A way to invoke the CCM code.

In reality, I'd want more on flash, including STM's peripheral library or some other peripheral library.

How does this all sound? I have to believe someone has tried it before, but perhaps my impatience is greater than average? Waiting 10s to test a one-line change is tedious. I also don't have enough $$$ for a simulator. Ok maybe there is something free like qemu—now that I'm on startup-doesn't-have-money-for-a-few-months leave, I can stop doing critical path work and start making my embedded life better. Anyhow, there are problems that simulators don't solve so this is still a feature I want.

Breathe for a moment. How long does it actually take you to program the flash? What method of programming are you using?

# ¿ Jun 4, 2013 22:20

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

We use a couple FRAM chips on my main project at work and the stuff is the tits - fast, real low power, easy to talk to since there are no delays, etc. It's kind of expensive but definitely worth it. Be aware that Ramtron et al. sometimes switch back and forth between kbits and kbytes in their documentation, but there is almost always a spot where the size of the chip is specified unambiguously (eg. it will say "1 MB (131,072 bytes)" or something).

I've been waiting on samples from Everspin for a while now, and I'll report back when they send me something and I get a chance to try it out; my understanding just from reading datasheets and looking at prices is that MRAM scales up better and will be cheaper for 1 megabyte+ chips, but FRAM is great if you just want 128k or whatever.

# ¿ Jun 16, 2013 20:36

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

That's exactly what we use FRAM for, I expect MRAM will fit the bill just as well. When you get to selecting components you'll find that generally I2C for these NVRAM chips tops out at 400 kHz, SPI at 3.4 MHz and the manufacturer's parallel protocol at 40 MHz or so (and get 4 or 8 bits at a time), so if you have free pins you can go Pretty Quick.

# ¿ Jun 16, 2013 22:17

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

isr posted:

For example, military contractors have to write everything in assembly,

Huh? For a while there was a mandate to use Ada although that eventually blew over, the JSF has published C++ coding standards (perhaps contributing to its lol-factor), we aren't a defense contractor by any stretch but we have products that get sold to .mil customers that had their firmware done in C, ...

# ¿ Sep 5, 2013 17:09

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

isr posted:

There are a lot of hoops to jump through just for certifying appliances [for safety], for a cruise missile I bet the requirements are much more stringent.

On a related note, does anyone know of good reads for doing designs for SIFs that have to get SIL certified? It seems like CE is cake and UL general safety certification isn't hard, FM intrinsic safety is a huge but reasonably well understood bitch, (and the equivalent ATEX and CSA certs), and nobody will say what to do for SIL without being paid five grand to come give a talk which then leaves you barely wiser than before.

# ¿ Sep 5, 2013 19:08

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 17:47

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Corla Plankun posted:

I just got a job doing embedded code with a dspic and I am really interested in doing things the right way instead of just doing them. My work involves signal processing, serial communication, and a host of digital outputs--I know how to do all of these things one-at-a-time but I am worried about getting them all to take turns nicely. Does anyone know of a good resource (free or paid) that could help me think about this in a constructive way? I think I need to develop an interrupt-driven scheme to keep everything working when individual modules take too much time, but its tricky to tell which parts should be interrupts and which should be in the main loop.

For what it's worth, I'm using MPLAB X and programming in C. Most of the resources I have found are either too basic or they use assembly and it takes too much mental effort to translate that to C.

What it sounds like you want here is a preemptive scheduler (probably with priorities), which is the most fundamental thing an RTOS will give you. In general I have found it easier to write well-factored firmware with an RTOS than without (except for really small things). There is at least one decent free one with permissive licensing as well.

# ¿ Sep 5, 2013 20:10

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

«‹›2 »