Writing to MCU flash

if you only need it at test time you could just patch hex file and reprogram once you know the right values

Reply to
Lasse Langwadt Christensen
Loading thread data ...

Putting a little EEPROM on the board is often the simplest solution. It is entirely /possible/ to store configuration data along with program code on most microcontrollers, but it can be complicated. You typically have to pause processing while programming, and you might not be able to erase the segment for the configuration without also erasing the main program.

Keep the program flash for programs, and write it when you are updating the software. Use a small data EEPROM for the data. It keeps everything clear and neat - saving significantly on development costs for the price of a tiny chip.

Reply to
David Brown

That's too much like work. There's space in the flash for the calibration code and the table (the basic program is pretty simple--read the control voltage from the ADC, do a table interpolation to get the gain, write to the dpot and mux. Lather rinse repeat.

There's a power-up offset check and a gain calibration, which are both done in firmware.

Thanks

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

rue of

ins

est

U

--the

This is why I like FPGAs. Real time in FPGAs is "REAL TIME" and you don't even need to think much about it. Trying to simulate real time functions o n an MCU with interrupts is a PITA. With FPGAs you can just focus on the p roblem, rather that the limitations of the solution.

Rick C.

  • Get 6 months of free supercharging + Tesla referral code -
    formatting link
Reply to
gnuarm.deletethisbit

John Larkin wrote

In this case the SDcard only carries data, no code. Not even a filesystem, 1 data record per sector, read exactly every 200 mS. All the executable code is in w Microchip 18F14K22 PICs.

I know you did some HUD display software hardware? long ago. I have one 18F14K22 as auto--pilot reading from the SDcard,

formatting link
and one driving a SAA5281 Ceefax chip to add data to the analog video from the drone:
formatting link

Now to get the data after its seemed logical to read it back from the display memory from teh SAA5281, call it re-using code :-) That took exactly 134 lines of asm, and a serial to USB module (the hardware) to plug it from the remote into a PC or whatever to record as text file.

Again I was amazed how extremely powerful asm is!!! You cannot do it on a raspberry or some other Linux box, because it is all time driven, all interrupts (gnuarm take note):

main_loop: clrwdt ; watchdog timer bra main_loop

I wondered, all those big blobs of software, gigabyte speed multicore processors, are we going the wrong way? Nature wants the simplest most powerful solution, natural selection, the whole thing needs a cleanup [1].

Loading hex file: Program 4366 bytes at address 0x000000 Config 14 bytes at address 0x300000 EEPROM 0 bytes at address 0xf00000

So about 4 kB for the HUD and flight recorder.

Loading hex file: Program 4626 bytes at address 0x000000 Config 14 bytes at address 0x300000 EEPROM 0 bytes at address 0xf00000

and about 4 kB for the auto-pilot.

And zero boot times :-)

Sure gnuarm FPGA can also do that, but these micros already have a lot on board for peripherals.

Dinos are dead.

Reply to
<698839253X6D445TD

We've done a few boxes that use a Zync chip (FPGA and two ARM cores) with the full FPGA config and Linux and the whole file system on the SD card, external DRAM, running all the standard Linux utilities and stacks, and our applications in c. All that sounds complex but it works fine. The serial i/o and USB and Ethernet and file system were free. You might not want to do all that in assembly.

We did a few products using a microZed

formatting link

(which runs Linux out of the box and allows users access to waveform files using standard Linux tools)

and a couple with the Zynq on our board.

formatting link

All that sounds complex, and it is, but it just works.

It might be interesting to do things like this using Linux and Python.

We also do bare-metal c apps on single-chip ARM systems. LPC1750 series cpu's.

formatting link

Everything, including the cal table, is in on-chip flash. We program the chip over the jtag connector and cal over the USB port.

I don't like programming c, but I have a couple of whiz-kids who do.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

John Larkin wrote

All very nice stuff, and having an FPGA with Linux running is in a way the best of both worlds. I have never used Zync, have an older Xilinx FPGA development board. C is OK, but not for time critical cases, it then simply puts an extra layer between you and the hardware. That is my view anyways. How is the boot-time of that Zync thing?

Reply to
<698839253X6D445TD

I seem to recall a console prompt in a second or two.

We did some tests to see how much a tight loop (wiggling a port pin) might be suspended by Linux system interrupts. On the dual-core Zynq chip, we never saw a timeout over 20 us.

It's possible to run Linux on one core and bare metal on the other. But we just move time-critical stuff into FPGA fabric.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

John Larkin wrote

That is very very good, my core i5 laptop running slackware linux takes so long you can get coffee in that time. It can be better old eeePC with Linux in FLASH boots in maybe 30 seconds.

20 us?? or 20 ms??? Task switch normally causes ms size interrupts, depends on what is running of course, Linux is not a real time OS. That big wallclock I have running on a raspberry
formatting link
starts flickering if I run any other task a the same time, and even if I just ssh to it.

Yes, way to go.

Reply to
<698839253X6D445TD

Microseconds. The wiggled port, seen on a scope, would sometimes hang high or low for that long; usually for less. And that was when we were bashing a lot of ethernet traffic. I was impressed.

It does (I've been told) allow one to politely suggest that some processes be run on one CPU core or the other, but the assignamt isn't absolute. We did what we could on the Zynq test.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

The TI ARM processor used in the BeagleBone Black has a couple of co-processors that seem to be designed for doing time-critical stuff. I'm sure somebody here has used them for such things. John

Reply to
jrwalliker

On Saturday, January 26, 2019 at 3:44:19 AM UTC-5, snipped-for-privacy@nospam.org w rote:

ders

product

to show the code in some cases.

on sockets for that reason anyways).

chip.

ROMs are programmed to default when programming).

ckets are OK.

o starbucks for coffee and updates),

d update etc etc.

oject today...

by itself.

S.

m the drone:

play memory from teh SAA5281,

are) to plug it from the remote into a PC

l time driven, all interrupts (gnuarm take note):

cessors, are we going the wrong way?

whole thing needs a cleanup [1].

board for peripherals.

Not sure what a Dino is, but your idea of dedicating a sector per data reco rd is poor in the extreme. Sectors on Flash are not very reliable. It is a good idea to have a flash file system to manage the good/bad blocks for y ou. I guess you can do that yourself, but are you thinking of that?

Rick C.

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

formatting link

Reply to
gnuarm.deletethisbit

The thread is about low level control of hardware. I'm not sure why anyone would want to complicate that with some humongous iron running Linux when a simple MCU or even a roll your own CPU in the FPGA would do the trick!

Why do people want to complicate things so much?

In many respects, just running C code on an MCU is a tremendous waste of time, both processor and development.

Rick C.

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

formatting link

Reply to
gnuarm.deletethisbit

gnuarm wrote

formatting link
dinosaur are extinct The story goes, because those were so big, that if one was bitten in the tail it took almost a second for the nerve signal to reach the brain and be processed, making those an easy victim for other animals and human hunters.

No, bad sector handling is done by the SDcard firmware we are talking about SDcards for data storage.

Reply to
<698839253X6D445TD

FPGAs and MCUs have their advantages and disadvantages.

100 lines of code. How would changing this to an FPGA affect board complexity, price, development time? Let's assume - to be realistic - that the OP or his group are happy with microcontroller development but inexperienced with FPGAs.

Sometimes FPGAs /are/ the right answer. And for some things, either FPGAs or microcontrollers are good choices, so you use the solutions you are familiar with. But this is not a case for an FPGA.

Reply to
David Brown

Flash is so cheap, write a few copies of everything and use whichever has a good checksum.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

We have advocates for running soft-core low-performance 8-bit CPUs inside FPGAs, microBlaze and such, but it doesn't make sense to me. It would take a new infrastructure (compilers, libraries, debug). RAM is expensive inside an FPGA, external DRAM is a big deal, and separete ARM chips are cheap.

The advantage of an internal CPU is that one (might maybe) save pins and (might maybe) do a synchronous interface from uP to fabric. External ARM to FPGA interfaces tend to be async, which is emotionally distasteful but not a big deal in real life. One could even go SPI.

SOCs, an FPGA with a hard ARM core or two, are getting cheap.

Embedded c and VHDL are sort of different cultures.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

Agreed. I don't think cpus on an FPGA make any sense unless you need the FPGA anyway, and even then it is usually simpler and cheaper to use an external microcontroller. As you say, development of microcontroller stuff and FPGA stuff is mostly a different culture, and the whole project will be simpler to do and easier to manage if they are mostly separate. It's a different matter if you have special requirements for the integration - FPGA acceleration of cpu instructions, tightly coupled peripherals, etc.

Reply to
David Brown

ed

the

is true of

d

e gains

te.

at test

e MCU

rk

ch

B
s

able--the

cal

It

m

ally

e to

n

ing

s

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

rd

and a

t

ou

one case where it might make sense is if you have slowish state machines for something like setup and want it to be easy to chance by someone who only knows c

Reply to
Lasse Langwadt Christensen

We often move the boundary between hardware/VHDL and c code. Like on one recent project, we want to report RMS voltage, based on samples from a unipolar ADC. Part of the math (subtract the DC baseline, square, sum a bunch of squares) is done in the FPGA. Some (compute the offset, process the sum of squares, scale and calibrate) is c. That was whiteboard negotiated. There are some synchronous detectors that work about the same way, part hardware and part code.

I would have moved the offset calculation into the FPGA.

We haven't done any floats in an FPGA, but people tell me it can be done. Our preferred ARM has hardware vector FP.

Actually, I think the sum-of-squares is floated by the FPGA before it's presented to the ARM.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.