Writing to MCU flash

You want to move something that is one line of C code, into FPGA hardware? Unless you are doing sampling at megaherz, that's crazy. Doing /any/ of RMS calculations in hardware is crazy. It is symptomatic of a company dominated by hardware folk and FPGA folk who have always done it this way - starting 20 or 30 years ago when it made sense, and failing to follow with the times since then. (Unless, as I say, you are talking about very high frequency signals.)

Reply to
David Brown
Loading thread data ...

The c is usually much easier to change than recompiling the FPGA. We have avoided some interesting FPGA families because we couldn't even get the demo tools to run. FPGA tools are usually tangled in FlexLM horrors, whereas the c suite is public domain.

c builds take seconds, and FPGA builds take hours.

c builds are command-line driven, whereas most FPGA tools are click driven. It's hard to archive clicks.

--
John Larkin         Highland Technology, Inc 

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

The two relevant products have 12 and 24 each of 16-bit ADCs, each ADC sampling at 500 KHz. 12 million subtract-square-accumulates per second might be done on the ARM, but that would dominate things. My c guy doesn't like pushing realtime cpu performance to the limits, which is a reasonable attitude.

It's not crazy, and it works.

My FPGA guys tell me that there are reasonable provisions in modern FPGAs to do math in floats. So far, the only one we have done is the huge-fixed-accumulator-to-float conversion, which was apparently trivial to implement.

It is symptomatic

I design the architectures and the hardware. We meet and negotiate between PCB hardware, FPGA functions, and what the ARM will do. It's fun and it works.

c hasn't changed much in decades. FPGAs sure have.

--
John Larkin         Highland Technology, Inc 

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

John Larkin

Yes, although...

I have used iverilog (Icarus Verilog command line verilog compiler) for Xilinx,

formatting link
and verilog 'style' is much like C It has been a while but I did that xilinx thing on Linux from the command line too:
formatting link
a very very long time ago...

Reply to
<698839253X6D445TD

David Brown wrote

No it is often a much better way. The problem with your 'one line of C code' is that you have no clue about the underlying hardware and bringing in whole libraries and tons of code with their bugs and unknowns to do something that can be done in a few lines of asm / verilog / whatever hdl,

THERE is exactly the current problem with bloat. And cluelessness build on cluelessness until we have the CEO using the 'I want' app say a food company CEO now in control of an airplane manufacturing plant dictating his latest brainfart and there you have it, It won't fly.

Or a reality show host .. well you guessed it.

Freaking hell a 32 bit square root in PIC asm is only a few lines man. Your freaking compiler of whatever kind can _never_ do better.

Reply to
<698839253X6D445TD

.org:

ilinx,

it is pretty much only for simulation

but you have to think very differently

line too:

you can still run the Xilinx tools from a command line if you want to

Reply to
Lasse Langwadt Christensen

We do, and I'm told that it's difficult.

--
John Larkin         Highland Technology, Inc 

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

In the minimalist world of my original post, the LPC804 has a useful number of CPLD macrocells available for simple stuff that needs hardware timing. We haven't used it for anything yet. Super nice little chip altogether.

Cheers

Phil Hobbs

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

Lasse Langwadt Christensen :

IIRC he did output for impact, but it was many years ago, not sure he followed up on tha tfor the later FPGAs

I still think whatever I like, its a free world up there ;-)

Good.

Reply to
<698839253X6D445TD

We're looking into littleFS for data logging on a system whose power can be disconnected at any time. It's a fire detection/suppression system for cotton harvesters, and we're facing large, rapidly fluctuating background signals due e.g. to sunlight bouncing off rapidly moving cotton and machinery, so we need to do a bunch of data logging and data mining and stuff to develop good algorithms.

(The actual fire detection algorithm relies on MWIR detectors and is rock-solid--it's the SWIR spark detection technique that's more difficult.)

Cheers

Phil Hobbs

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

I do a lot of backup either to harddisk, SDcards, or optical disks (Blu-ray). Usually use 'dd', that does a sector by sector copy. But always in the case of sdcards or optical I compare the resulting image. You can do that in Linux with 'diff' but I use something I wrote: dvdimagecmp, as it shows the errors and write speed;

formatting link

Optical does show read-back errors sometimes, SDcards the same, harddisks never. If you are sort of paranoid you can read back a sector written, compare to the original, retry if you like, but remember in case of a sdcard the real physical sector on the card is not the same as the sector number you wrote. As to cards, their internals, goods and bads, this is worth reading:

formatting link

for me that boils down to using a good card, and as the discussion was, writing random sectors is OK, when you get a write error the card is defective as simple as that, the card's micro should map the logical sector number to a physical sector number and show an error if no free physical sector is available, else try the write to an other free sector if it fails internally and update the translation table.

For data logging when there is only one source, writing sector by sector without using a filesystem is simpler. There is a lot that can go in a 512 byte sector, I put latitude, longitude, altitude, speed, heading and a few more things in those 512 bytes and have plenty space left. last sector always starts with a 0 byte. Reading back is simple because in Unix a memory device is a file, so use fseek() to the sector, well example code is on my site. Simplicity.

Reply to
<698839253X6D445TD

People who say that Verilog is like C (and/or that VHDL is like Ada) usually have very little experience of either language, and certainly not of both.

Reply to
David Brown

At that speed, you have justification for using an FPGA (you are doing

12 megasamples/sec). To do it with cpus, you'd need quite a bit one (Cortex-A, PPC, etc.) rather than a microcontroller. And you'd need to know what you are doing. (Alternatively, you could go for a big DSP - but that's almost as ugly as an FPGA.)

It's hard to get this rate of throughput on a single processor - and be sure that you are getting everything, all the time (caches give you fast throughput, but make it really difficult to get real-time guarantees).

I have no idea about the rest of the design, but my first thoughts here would be to modularise and handle the channels separately. Handling /one/ channel with a small Cortex-M4 device should be simple, and give you easy separation of the analogue signals as well.

I did make it clear that megasamples rates were a different matter.

Sure, it can all be done in an FPGA. I am not questioning if this is possible in an FPGA, merely if it is the sensible way to handle it.

What you can /do/ with C has changed rapidly, especially in the embedded world. The tools have changed dramatically. The language hasn't changed much (it has changed a bit). Kind of like Verilog and VHDL, really.

Reply to
David Brown

You must be thinking of a completely different language - certainly a completely different type of development.

People who write C code professionally usually know what their lines of code do.

Perhaps that all made sense to you when you wrote it - it makes no sense to me.

/Anything/ is better than doing PIC assembly.

Reply to
David Brown

No

No.

That is possibly where the problem is. I see no 'tronics from you, you almost sound like a sales person for some bloatware that blinds people from the inner working of things,

That statement proves my point.

Reply to
<698839253X6D445TD

David Brown opiniated

I was thinking all the nonsense written by people like you, as to C (language) the few statements it has, and the many many instructions in for example a PIC (something else you have zero experience with) micro, bit oriented operations, what an idiot one would be to do that in C and then having no clue what the compiler does with it make very inefficient use of the hardware,

Reply to
<698839253X6D445TD

It is where your problem is, yes - you write things that have no connection with the discussion and make no sense.

I am an embedded programmer, not an electronics designer. (I've done a fair bit of digital electronics design in the past - I have very little experience of anything analogue beyond ADC's and DAC's.)

It proves that you are stuck in the 80's.

Reply to
David Brown

Older people in the embedded world, yes. Younger people in other fields - sometimes :(

I've seen too many that only have a vague concept of what a cache is. And even getting them to outline what a processor does during an unoptimised subroutine call can be like pulling teeth.

PEBCAK in a stark form.

I once looked at a PIC's assembler, and thought "life is too short".

Reply to
Tom Gardner

So what are you doing here?

Remarks like that show you should really look for an other job and be easier on humanity,

You know, I spend much of the weekend writing PIC asm, and C code for on the PC. All about flight control, did testing, collecting data, testing, timing checks.. At some point I was aiming for a 2 second interval, and man was I stunned when the calculation from the acquired data showed 2.000. 'That cannot be right', ran the test again, and then ? now it was 8 % off. relief. In those old day you had to have the 'tronics working with 20 % carbon resistors and 19% tolerance (aging) tubes, yes TVs still worked.

As from the eighties, man I started in the fifties with 'tronics, solved problems with RTL, DTL logic before many of your were even diapers dry, and so FPGA is for me just back to logic that is what it is, nothing new, but more of old. Designed my own processor when I could not get a budget for one, but had unlimited budget for logic..

From the bottom up yes? When I retired I did not stop with 'tronics and did not stop coding (yes I did embedded on cannot remember how many different micros), so now I play with things I can select, and have fun with that. All the nonsense by you kiddies about programming; the whole recent discussion with J. Larkin, I just left it for what it is as it has no purpose other than chatting and you can indeed do that in a bar. This subject was writing to flash memory and I think I addressed that, at ;east for SDcards, if it is beyond your grasp so be it. Make a positive contribution to 'tronics publish some code and projects, I have always done that, even this newsreader, written in C, you could actually learn some basic programming principles from. The list is endless and there are many projects on my site, many need updating but I am busy now with new stuff.

Have fun.

PS I have a little challenge for you on a PIC 18F14K22 if you think you are so good in embedded (use any language you like) ? But it must work (mine does) OK?

Again, it is not only that you can program in some language, say same as speak some language, you also need to know in depth what you talk about, A life long study of THAT.

Reply to
<698839253X6D445TD

You might not have noticed, but electronics threads are in the minority in this group. And within the on-topic threads, software is relevant - people ask questions and give advice on it.

No professional developer writes assembly on PICs any more. You might do it for fun (and that's a perfectly good reason). But not as a serious choice. I've done professional assembly programming, including on a PIC - it made (some) sense long ago.

Am I supposed to appreciate some point here? Is your point that sometimes you get values accurate to one part in a thousand even when you have 8% tolerances? Or that you can't write a timing loop in PIC assembly that is accurate to 8% ?

If you are having fun, great. But don't pretend that your methods make economic sense these days.

I am not a kiddie. True, I am still a good way from retirement age. That means, however, that I live with the times and adapt to get the best choices available /now/, rather than sticking to what I used twenty years ago. (Except, of course, when the choice from twenty years ago is still the best choice today.)

The subject of the thread was writing to flash on an MCU, not an SDCard. (And yes, I have written to SDCards too.)

What newsletter? What site? I am highly sceptical to the idea that your site could teach me any "basic programming principles", but I will reserve final judgement until seeing it.

Challenge not accepted. It would be like challenging someone to a rally race and saying they can use any car they want, as long as it is a Model T Ford.

Reply to
David Brown

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.