On Mon, 28 Jan 2019 09:13:14 +0100, David Brown <david.brown@hesbynett.no> wrote:>On 28/01/2019 08:23, 698839253X6D445TD@nospam.org wrote: >> David Brown opiniated >>> On 27/01/2019 19:34, 698839253X6D445TD@nospam.org wrote:>>> David Brown wrote ><snip> > >>> Perhaps that all made sense to you when you wrote it - it makes no sense >>> to me. >> >> >> That is possibly where the problem is. > >It is where your problem is, yes - you write things that have no >connection with the discussion and make no sense. > >> 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, > >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.)How do you interact with the electronic designers? Do you get pulled in after the architecture is frozen, and given a spec to implement? Or are you involved in hardware/software/analog/digital tradeoffs from the start? Signals and Systems is fun, especially if you have multiple ways to implement it. A filter can be various kinds of analog, FIR in an FPGA, IIR in uP code, whatever works.> >> >> >>>> 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. >>>> >>> >>> /Anything/ is better than doing PIC assembly. >> >> That statement proves my point. >> > >It proves that you are stuck in the 80's.We still, rarely, drop down to a bit of asm. It's ugly on an ARM. -- John Larkin Highland Technology, Inc lunatic fringe electronics
Writing to MCU flash
Started by ●January 24, 2019
Reply by ●January 28, 20192019-01-28
Reply by ●January 28, 20192019-01-28
On Mon, 28 Jan 2019 08:27:19 +0000, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 28/01/19 06:30, David Brown wrote: >> People who write C code professionally usually know what their lines of code do. > >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. > > >> /Anything/ is better than doing PIC assembly. > >I once looked at a PIC's assembler, and thought >"life is too short".We had a weird problem last week. An ARM talks to an FPGA which implements a bunch of DDS sine wave generators, driving a mess of serial DACs. The sinewaves had weird erratic spikey glitches, which were suspected to be SPI transmission-line problems, but weren't. Much experimenting and thinking led us to the real problem: a VOLATILE declaration in c wasn't always working, so the sinewave amplitude multiplier values would occasionally get zeroed. One clue was that the glitches were erratic but quantized to 1 ms time ticks, and the ARM runs a 1 KHz interrupt. I solved the problem by applying the universal principle of "always blame the software." -- John Larkin Highland Technology, Inc lunatic fringe electronics
Reply by ●January 28, 20192019-01-28
On 28/01/19 16:38, John Larkin wrote:> On Mon, 28 Jan 2019 08:27:19 +0000, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > >> On 28/01/19 06:30, David Brown wrote: >>> People who write C code professionally usually know what their lines of code do. >> >> 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. >> >> >>> /Anything/ is better than doing PIC assembly. >> >> I once looked at a PIC's assembler, and thought >> "life is too short". > > > We had a weird problem last week. An ARM talks to an FPGA which > implements a bunch of DDS sine wave generators, driving a mess of > serial DACs. The sinewaves had weird erratic spikey glitches, which > were suspected to be SPI transmission-line problems, but weren't. > > Much experimenting and thinking led us to the real problem: a VOLATILE > declaration in c wasn't always working, so the sinewave amplitude > multiplier values would occasionally get zeroed. One clue was that the > glitches were erratic but quantized to 1 ms time ticks, and the ARM > runs a 1 KHz interrupt. > > I solved the problem by applying the universal principle of "always > blame the software."That's trivially valid if you include the VHDL/Verilog code in the definition of "software" :) In cases such as yours, it can be "entertaining" to determine whether to assign the root-cause to the programmer, the compiler, or the language. With modern C (worse: C++), KISS has disappeared from the language.
Reply by ●January 28, 20192019-01-28
On a sunny day (Mon, 28 Jan 2019 15:21:27 -0000 (UTC)) it happened Don Kuenz <g@crcomp.net> wrote in <20190128a@crcomp.net>:>David Brown <david.brown@hesbynett.no> wrote: >> On 28/01/2019 09:56, 698839253X6D445TD@nospam.org wrote: >>> David Brown imagined >>>> On 28/01/2019 08:23, 698839253X6D445TD@nospam.org wrote: >>>>> David Brown opiniated > ><snip> > >>>>>>> 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. >>>>>>> >>>>>> >>>>>> /Anything/ is better than doing PIC assembly. >>>>> >>>>> That statement proves my point. >>>>> >>>> >>>> It proves that you are stuck in the 80's. >>> >>> 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. >> >> No professional developer writes assembly on PICs any more. > >Careful there. Olin Lathrop's a professional PIC developer who advocates >MPASM over C. http://www.embedinc.com/embed.htm > > >>> PS I have a little challenge for you on a PIC 18F14K22 if > >Interesting chip. > > >Thank you,Interesting site :-)
Reply by ●January 28, 20192019-01-28
David Brown uttered a mantra:>OK, virtually no professional developer writes assembly on PICs. Better?Mantras are close to religion and people who use them believe those work. Science is something else.
Reply by ●January 28, 20192019-01-28
David Brown stated <david.brown@hesbynett.no> wrote in <q2n5en$965$1@dont-email.me>:>I am not a beginner at programming - but I can see that you hadn't >learned much about reliable coding before writing that jumble. You >should learn a little about interfaces and implementations, and how to >write them in C.Well, the code is from 1998 (really) some minor things changed later in Usenet, so some minor things were changed in the code. In all those years nothing bad happened, I have a database that goes back to year 2000 or so (old one was lost when harddisk was dropped), and maybe in all those 18 years 18 crashes. I know why, and do not bother. So, now compare that to eeehhh wherewasit redmond.. stuff?>I'd recommend you open your eyes and see what has happened in the >industry in the last 30 years or so. I agree that not all of it is >good, but many things have moved forward.Na, I'v contributed some to that...>I write embedded code for a living, not just toys for fun. I don't get >to publish my clients' code.I know, everything you do is secret and perfect.>But I'd be embarrassed to have something like that newsreader code >published in my name.I would be embarrassed too if you published my code in your name :-) Without mentioning source that is. There was a website long ago that published a clone of my xste (subtitle editor), every time I added some feature they did too (for money that is). Then I announced a feature, it was for a working group, they announced it too. The requirements changed and that feature was no longer needed, so I never implemented it. That website disappeared. Like snow in the sun. Yes many derivates of software I wrote were made by many people all over the world with my consent. Open source is fun. There are always the jealous types, I remember people writing 'that can never work' and stuff like that, 'it has memory leaks all over it' (for the subtitle software), and crap like that, Some had a very specific business interest to attack. None of those are still around AFAIK. You should try open source too. People will rip your code apart, some people will have requests (I implemented several in NewsFleX), read open source code, share it, that is the right way. All your secrecy to me means it is unverifyable and of no value. Your attacks are not specific, and hold no ground. You hide. :-)
Reply by ●January 28, 20192019-01-28
On 1/28/19 12:02 PM, Tom Gardner wrote:> On 28/01/19 16:38, John Larkin wrote: >> On Mon, 28 Jan 2019 08:27:19 +0000, Tom Gardner >> <spamjunk@blueyonder.co.uk> wrote: >> >>> On 28/01/19 06:30, David Brown wrote: >>>> People who write C code professionally usually know what their lines >>>> of code do. >>> >>> 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. >>> >>> >>>> /Anything/ is better than doing PIC assembly. >>> >>> I once looked at a PIC's assembler, and thought >>> "life is too short". >> >> >> We had a weird problem last week. An ARM talks to an FPGA which >> implements a bunch of DDS sine wave generators, driving a mess of >> serial DACs. The sinewaves had weird erratic spikey glitches, which >> were suspected to be SPI transmission-line problems, but weren't. >> >> Much experimenting and thinking led us to the real problem: a VOLATILE >> declaration in c wasn't always working, so the sinewave amplitude >> multiplier values would occasionally get zeroed. One clue was that the >> glitches were erratic but quantized to 1 ms time ticks, and the ARM >> runs a 1 KHz interrupt. >> >> I solved the problem by applying the universal principle of "always >> blame the software." > > That's trivially valid if you include the VHDL/Verilog > code in the definition of "software" :)Now there's a giveaway. You don't even believe in hardware! Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net https://hobbs-eo.com
Reply by ●January 28, 20192019-01-28
On Mon, 28 Jan 2019 08:27:19 +0000, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 28/01/19 06:30, David Brown wrote: >> People who write C code professionally usually know what their lines of code do. > >Older people in the embedded world, yes. Younger people >in other fields - sometimes :(If A is a float, A=A+3 could be a big deal. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●January 28, 20192019-01-28
On Mon, 28 Jan 2019 13:06:40 -0500, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>On 1/28/19 12:02 PM, Tom Gardner wrote: >> On 28/01/19 16:38, John Larkin wrote: >>> On Mon, 28 Jan 2019 08:27:19 +0000, Tom Gardner >>> <spamjunk@blueyonder.co.uk> wrote: >>> >>>> On 28/01/19 06:30, David Brown wrote: >>>>> People who write C code professionally usually know what their lines >>>>> of code do. >>>> >>>> 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. >>>> >>>> >>>>> /Anything/ is better than doing PIC assembly. >>>> >>>> I once looked at a PIC's assembler, and thought >>>> "life is too short". >>> >>> >>> We had a weird problem last week. An ARM talks to an FPGA which >>> implements a bunch of DDS sine wave generators, driving a mess of >>> serial DACs. The sinewaves had weird erratic spikey glitches, which >>> were suspected to be SPI transmission-line problems, but weren't. >>> >>> Much experimenting and thinking led us to the real problem: a VOLATILE >>> declaration in c wasn't always working, so the sinewave amplitude >>> multiplier values would occasionally get zeroed. One clue was that the >>> glitches were erratic but quantized to 1 ms time ticks, and the ARM >>> runs a 1 KHz interrupt. >>> >>> I solved the problem by applying the universal principle of "always >>> blame the software." >> >> That's trivially valid if you include the VHDL/Verilog >> code in the definition of "software" :) > >Now there's a giveaway. You don't even believe in hardware! > >Cheers > >Phil HobbsWe almost always get our PC boards right first try. Code is almost always wrong as written, and needs many iterations to bet to mostly bug free. VHDL is better than c, mainly because my VHDL guys include a lot of test benching and don't consider the code done until it simulates right. But the first as-typed code is usually wrong. The idea is that the easier it is to change something, the less effort will be invested in getting it right. Fun: google spreadsheet errors Turns out that most spreadsheets are wrong. Billion dollar mistakes have been made. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●January 28, 20192019-01-28
On 1/28/19 1:34 PM, John Larkin wrote:> On Mon, 28 Jan 2019 13:06:40 -0500, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> On 1/28/19 12:02 PM, Tom Gardner wrote: >>> On 28/01/19 16:38, John Larkin wrote: >>>> On Mon, 28 Jan 2019 08:27:19 +0000, Tom Gardner >>>> <spamjunk@blueyonder.co.uk> wrote: >>>> >>>>> On 28/01/19 06:30, David Brown wrote: >>>>>> People who write C code professionally usually know what >>>>>> their lines of code do. >>>>> >>>>> 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. >>>>> >>>>> >>>>>> /Anything/ is better than doing PIC assembly. >>>>> >>>>> I once looked at a PIC's assembler, and thought "life is too >>>>> short". >>>> >>>> >>>> We had a weird problem last week. An ARM talks to an FPGA >>>> which implements a bunch of DDS sine wave generators, driving a >>>> mess of serial DACs. The sinewaves had weird erratic spikey >>>> glitches, which were suspected to be SPI transmission-line >>>> problems, but weren't. >>>> >>>> Much experimenting and thinking led us to the real problem: a >>>> VOLATILE declaration in c wasn't always working, so the >>>> sinewave amplitude multiplier values would occasionally get >>>> zeroed. One clue was that the glitches were erratic but >>>> quantized to 1 ms time ticks, and the ARM runs a 1 KHz >>>> interrupt. >>>> >>>> I solved the problem by applying the universal principle of >>>> "always blame the software." >>> >>> That's trivially valid if you include the VHDL/Verilog code in >>> the definition of "software" :) >> >> Now there's a giveaway. You don't even believe in hardware! >> >> Cheers >> >> Phil Hobbs > > We almost always get our PC boards right first try. > > Code is almost always wrong as written, and needs many iterations to > bet to mostly bug free. VHDL is better than c, mainly because my VHDL > guys include a lot of test benching and don't consider the code done > until it simulates right. But the first as-typed code is usually > wrong.Test-driven design is a software development technique that applies that idea to code. You write a description of each function, write a unit test for it, and then write the function. My son and colleague Simon (formerly known as Dashing Firmware Hunchback) built a build-and-testing framework that he uses for that--the firmware gets mostly debugged on x86, with functions that log and mimic the peripherals. It's way faster than doing it on the target, and of course it can be going on in parallel with the target hardware development. (He's a much more orderly fellow than I am.)> > The idea is that the easier it is to change something, the less > effort will be invested in getting it right. > > Fun: google spreadsheet errors > > Turns out that most spreadsheets are wrong. Billion dollar mistakes > have been made.You betcha. The last spreadsheet I used for anything except reading other people's CSVs was Visicalc, circa 1982. I took one look at it, realized that spreadsheets were impossible to debug, and chucked the whole notion. I do plots using text files + Gnuplot, feasibility calculations with an old version of Mathcad, and otherwise I mostly write something. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net https://hobbs-eo.com
