Writing to MCU flash

It would have been been considered bad coding style in 1998, just as it is now.

The fact that MS has produced worse code does not make yours good.

Do not worry about that.

I get involved from early on, and work together with them. I have made full schematics and pcb designs (with relatively little analogue stuff - one transistor is okay, but if I put two transistors together I'll get them wrong). But other people are better at it than me, so they do the electronics design. I'll often be the main voice behind choosing the microcontroller or other digital architecture.

We don't find much need for advanced filters in most of our stuff. But yes, they can be fun.

Agreed. Assembly is nice on mid-level cpus. It is ugly on braindead devices with too few registers, too few addressing modes, too few instructions - like the PIC, 8051, etc. It is ugly on RISC devices with too many registers, complicated scheduling, complicated instruction formats. The goldilocks area is in the middle - things like the 68k or the msp430.

Still, C code (or C++, or Forth, or other low-level high-level programming languages) are a great deal more efficient, as long as you understand how the language works and how your tools work. (You also need to know how to design good software, but that applies to all languages.) It is unfortunate that a fair number of people don't properly understand the languages they use, the tools they use, or their targets.

Was it someone who thought "volatile" meant "atomic" ?

I first (triumphantly re)invented that process in 1982.

It remains a source of pleasurable bewilderment that it is regarded as novel (and that people can make a living proselytising it).

They are all other domain specific languages, and languages touted as allowing non-programmers to avoid having to interact with the IT department.

Programs start small and well within the relevant domain. They gradually expand (and become cancerous growths) and go outside the domain (and fall over a cliff).

Yes, it is difficult to beat those tools that process.

That's "easy" in that it is more or less a language independent issue.

C/C++ has far more and far more subtle traps. That's been known from the earliest days: the /second/ C book (the "C Puzzle Book") was about some of them. With language and processor changes over the decade, the problem has only become worse.

And I'll skip over the philosophical aspects of there even being an Obfuscated C contest. Some of those entries are truly remarkable in many ways!

The programmer applied the universal principle of "always blame the compiler."

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

Regrettably, with complicated languages and complicated ISAs, that isn't a completely ridiculous attitude.

Trust, but verify.

On Sunday, January 27, 2019 at 3:25:42 AM UTC-5, snipped-for-privacy@nospam.org wro te:

tail it took

Story is wrong though - just like the human brain doesn't need to process a n injury to a hand to cause the arm muscles to retract the hand. "Dinos" m ostly likely had multiple brains to control the body. I still don't know w hat you meant by "Dinos are dead". Obviously some sort of comparison that is clear in your mind, but you didn't make any connections, so I have no id ea what you are talking about.

a

you.

"Bad sector handling" doesn't prevent all data loss. Flash memory is parti cularly unreliable perhaps only better than spinning rust. Since sectors c an be lost putting a record within a single sector is not a very reliable w ay to prevent data loss.

Rick C.

-+ Get 6 months of free supercharging -+ Tesla referral code -

e

true of

gains

.

test

MCU

le--the

l

It

ly

to

g

n't even need to think much about it. Trying to simulate real time functio ns on an MCU with interrupts is a PITA. With FPGAs you can just focus on t he problem, rather that the limitations of the solution.

a

Let's just be realistic without assuming, eh? I don't know what factors ar e significant in his project, he hasn't shared that with us. We also don't know what else is going on in the processor. You made all manner of assum ptions without consideration to anything you know about the project especia lly the 100 lines of code. I would never hire you to design an embedded bo ard for a project of mine.

I guess the most reasonable thing you wrote was your preference for stickin g with a bad solution primarily because you have never bothered to learn ab out better solutions.

Rick C.

+- Get 6 months of free supercharging +- Tesla referral code -

d

he

s true of

gains

e.

t test

MCU

k h

ble--the

al

It

lly

to

ng

on't even need to think much about it. Trying to simulate real time functi ons on an MCU with interrupts is a PITA. With FPGAs you can just focus on the problem, rather that the limitations of the solution.

d a

You are looking at FPGAs through the eyes of a dinosaur. A soft core in an FPGA can be thought of as a logic block rather than the way you think of t he complexity of a typical MCU. Small CPUs can be built in just a few hund red LUTs and be dedicated to a specific task rather than using a single MCU to task switch between many tasks greatly increasing the complexity of pro gramming, communications and the memory requirements.

Again, people are limited in their thinking to what they are used to. One of the big ones is the idea that you need to program in C. Not only comple x to code for embedded use, it's very hard to debug. There are better alte rnatives such as Forth.

Rick C.

++ Get 6 months of free supercharging ++ Tesla referral code -

:

olled

at the

me is true of

s.

lled

m

able gains

brate.

or at test

the MCU

work

he

.

which

PCB

gets

stable--the

he cal

on. It

gram

pically

able to

main

dating

osts

ou don't even need to think much about it. Trying to simulate real time fu nctions on an MCU with interrupts is a PITA. With FPGAs you can just focus on the problem, rather that the limitations of the solution.

board

?, and a

c -

but

r

s you

It

s

e

er

r

ed

This is just ignorance on the part of the people using the tools. Both C a nd HDL tools are command line driven or have a GUI to suit your preferences . Many HDL designers use the command line interface since it gives you bet ter control and as you indicate, archivable scripts to run the tools.

Rick C.

--- Get 6 months of free supercharging --- Tesla referral code -

am.org:

Xilinx,

Yes, it is much easier to think of real time, parallel processes in HDL whe n you just write the code as if everything is in parallel because... it is.

nd line too:

You can run all FPGA tools from the command line as far as I know. The GUI is just a layer that invokes the command line tools.

Rick C.

--+ Get 6 months of free supercharging --+ Tesla referral code -

f code do.

The difficulty in isolating the bug is from the lack of appropriate self te sting capability designed into the system. It is always a good idea, even if after the fact, to provide a way for the hardware sub-system to be teste d independently of the software. Here the DACs were used to generate sine waves, so I would have added a feature to drive the DACs from a lookup tabl e embedded in the HDL code. That sine wave could have be tested for spurs with no artifacts from the DDS or the software. Then the DDS should have a mode of free running independent from the software which would provide a s ine wave output with no influence of the software allowing you to analyze t he spurs added by the DDS.

Rick C.

-+- Get 6 months of free supercharging -+- Tesla referral code -

Yes there are reflexes, but it (the dino) also needs to take evasive action for example, strike back, etc. I don't know about multiple brains, I do know the nerve signals for pain are very slow: From

0.61m/s (pain) So if end of tail of a dino is 20 meters from its head, it would not notice the rat ? tiger? whatever taking a byte for about 12 seconds! The tiger would easily get away, same for a human hunter. Well theory of course, never tried it on a live one...

See the link I gave:

I record a lot on FLASH, and now I am talking about SDcards, and if you check write call error return you will know when a card is defective, or simply full. And look at that link, not all cards are the same and allow the same random access.

Think about it: All those digital cameras, HD recorders, no problem.

As to writing to flash in a micro, I do not do that, I do not like the idea of boot loaders and sending the executable over the net, encrypted or not.

Simply hand or mail a new chip. The BIG advantage of that is, that if things do not work for any reason (and it would not be the first time a software update introduces new bugs), then you can simply put the old chip back. No FLASH is really reliable,

As to dinos are dead, in my view many things can be done faster and more reliable by small micros, or FPGAs then huge multi tasking multi-cores running Linux. The software in a few Microchip PICs for my drone an example of that,

Oops I don't know about multiple brains, I do know the nerve signals for pain are very slow: From

0.61m/s (pain) So if end of tail of a dino is 20 meters from its head, it would not notice the rat ? tiger? whatever taking a byte for about 12 seconds! The tiger would easily get away, same for a human hunter.

20 / .61 = 33 seconds....

Of course I am making assumptions - extrapolating from the little information we have. And of course if this were a customer, I would be expecting a great deal more information before giving suggestions. It's not a matter of not hiring me for this "job" - I simply wouldn't accept a job with that level of requirement detail.

What we know of the situation is that the OP has a small, cheap microcontroller. His problem is that he wants to store some calibration data, and is not happy about storing it in program flash. The obvious answer - baring other factors that are missing from this information - is to add a small, cheap EEPROM. It will solve his problem with minimal cost in hardware, and minimal cost in code complexity (100 lines is a perfectly good order-of-magnitude estimation).

If he already has an FPGA on board, then it might be a different matter. Then the solution could be to add a small, cheap EEPROM and put those

100 lines of C code in an embedded (soft or hard) processor on the FPGA.

On Tuesday, January 29, 2019 at 3:59:12 PM UTC-5, snipped-for-privacy@nospam.org wr ote:

he tail

ed,

s an

mostly

s

ea

on for example,

are very slow:

ce the rat ? tiger? whatever

for a human hunter.

Likely you are extrapolating beyond your data set.

is a

you.

rticularly

ay

dSurvey

I don't see anything on error recovery or failure rates.

heck write call error return you will know

om access.

So?

Where do you get the idea there is "no problem"???

e net, encrypted or not.

and it would not be the first time a software update

Agreed on this point.

reliable by small micros, or FPGAs then huge

Horses for courses. The only reason for using an OS is if it provides some functionality that is hard to get any other way. If you want to communica te over wide bandwidth wifi or any of a dozen other interfaces that an OS p rovides easily, then an OS is justified. Using Linux simply because you ca n get a processor on the FPGA chip is not a very good reason for using it w ith LInux.

By the same token, many people have a mistaken impression that only MCUs ca n be small and cheap. Sure, there are no $0.25 FPGAs available in an 8 pin DIP, but for many lower end apps a $2 FPGA works as well if not better tha n a $2 MCU. It's not uncommon to have some unique interface that is hard t o do in an MCU even with all the various peripherals on chip.

Rick C.

-++ Get 6 months of free supercharging -++ Tesla referral code -

Internally in the card a failed write to a physical sector results in that sector marked as 'bad' and the translation table from logical sector to physical sector being updated (also in flash in that card) to point to a good sector that is then used for write. If this process fails you get a write error. Write returning OK is data OK on the card. In case of data logging, writing sector after sector, or block after block (whatever is best for the card) is no different from sequentially writing via some OS using some filesystem. I have inspected and recovered data (images and video) from cards that were erased (report was in sci.crypt) found all was neatly sequentially written, even in case of that MS OS. Fragmentation only occurs after many read writes erasures of files of different length by the OS. So why use a filesystem if you only have one data stream. Cards can go bad, use a hammer and nail, heat those, saw, maybe big sparks (have not tried), EMP, to either physically damage the on board controller or cause enough charge change in the storage cells.

For the rest you can drop those, shake those, unlike harddisks,

Because there is no problem :-)

I have SDcards in use for 6 years or more all day, cheap ones too, and those still work. All old cards from video cameras still work. I do make backups on harddisk and optical though, so I can compare.

I think that line by me 'No FLASH is really reliable,' can be interpreted 2 ways, I did mean without the No :-)

I think we agree on the main point, apart from SDcards perhaps, what is your problem with SDcards?

particularly

e way

lashCardSurvey

t sector marked as 'bad' and the

lso in flash in that card)

k (whatever is best for the card)

em.

re erased (report was in sci.crypt)

ferent length by the OS.

s (have not tried), EMP,

e change in the storage cells.

If the errors are well behaved, then they will be mitigated. If a sector i s not bad at the time of writing or the error is not apparent when written, but then an error develops when it is read, this does not mitigate that pr oblem.

You keep talking about file systems. I've never said anything about file s ystems. I've simply pointed out that Flash memory is not very reliable com pared to the rest of a properly designed electronic system. I've also said nothing that is particular to SD cards.

u check

andom

ose still work.

I don't have a lot of evidence to offer showing the failure rates among fla sh devices, but I have personally had flash devices fail and I have read ma ny, many warnings that flash devices have a relatively high failure rate an d should not be used as solitary backup media for important information. M uch of that has been here in this group.

I've also never had a hard drive fail that I can recall. Does that mean I should consider hard drives to be reliable?

the

n (and

2 ways, I did mean without the No :-)

re reliable

ome

cate

rovides

with

can

n

han

to

our problem with SDcards?

I think you have failed to read properly what I have written and have read much that I did not write.

Rick C.

+-- Get 6 months of free supercharging +-- Tesla referral code -