#avr Logs

Nov 21 2019

12:37 AM rue_bed: without
12:42 AM rue_bed: F103
12:42 AM rue_bed: I blame the awefull-so-far gcc floating point math
12:42 AM rue_bed: whatever they include for the stm32 is awefull
12:42 AM rue_bed: and yea, part of the sin() is linear
09:31 AM rue_mohr: to use actual sine values and not bad approimations?
09:33 AM rue_mohr: I'm getting curious as to how far its out, I might sit down and have it make a table, and compare with real values
09:35 AM cehteh: how exact do you need it?
09:35 AM cehteh: for DAC .. some integer 12, 14 bit or what?
09:49 AM Fuchikoma: sin(x) = x is good to about 0.25 radians, where the error is ~1%
09:49 AM Fuchikoma: If you need speed and/or don't have good floating point performance, use a lookup table
09:55 AM cehteh: i wonder if a trapezoid (or triangle) curve and a spline interpolation will already be good enough
09:56 AM cehteh: depends on how many points and accuracy you need
09:57 AM cehteh: on stm32f3 there should be enouhg space for a lookup table as well, except when you want jitter-free high quality waveforms
10:01 AM Fuchikoma: Well sin and cos can share the same table, and you only need to store 1/4 of a wave
10:02 AM Fuchikoma: With a reasonable number of points, linear interpolation would be just fine I'd wager
10:02 AM cehteh: problem is the jitter-freeness .. when you want to change the output frequency only for a fraction you need another table
10:03 AM Fuchikoma: I don't quite get that?
10:03 AM Fuchikoma: only for a fraction of what?
10:03 AM cehteh: frequency
10:04 AM Fuchikoma: Just scale the timestep into the table
10:04 AM cehteh: yes, that leads to artifacts and qunatization errors
10:04 AM Fuchikoma: Frequency translates to, essentially, the angular velocity of the vector
10:05 AM Fuchikoma: I don't see how having more than one table will help with this
10:05 AM cehteh: well .. nitpicking, i am talking about when you want to do it extremely precise
10:06 AM Fuchikoma: Precision is inherently limited by the bits available for the calculation :D
10:07 AM cehteh: and the time steps you have, eventually you have to fine adjust the sampling frequency to match a multiple of your timebase
10:07 AM cehteh: the cheap function generator i got recently cant do that, expensive ones can do
10:08 AM davor_ is now known as davor
10:12 AM Fuchikoma: Are you sure that's not a function of the DAC bandwidth?
10:14 AM cehteh: its more because the DAC runs at constant frequnecy
10:14 AM cehteh: or at least at quantizized frequncy
10:16 AM cehteh: any frequnecy whhich is not an exact multiple of the DACs sampling frequency will result in jitter
10:16 AM cehteh: (usually neglegible because its very small)
10:16 AM nohit: the arm math lib ones use lookup table
10:16 AM nohit: https://pastebin.com/MP5Fyuin
10:16 AM Fuchikoma: So it's a cheap DAC, and not the fault of the underlying math
10:17 AM cehteh: that works together, use math to map to the existing sampling frequnecy which results in jitter
10:06 PM rue_mohr: cehteh, I'm talking REALLY OFF
10:06 PM rue_mohr: this is WAY OUT
10:06 PM rue_mohr: but It would help if I had it print out a value table to show you just how bad it is
10:08 PM cehteh: something configured wrong?
10:25 PM rue_mohr: oh I must have set gcc to compile with wrong values for sin? ( :-| )
10:26 PM cehteh: no idea what you are doung, but it shouldnt be totally off
10:26 PM rue_mohr: looks awefull
10:26 PM cehteh: iirc the math lib has a lot, or at least some tuning knobs
10:28 PM cehteh: is that a glibc derivative?
10:36 PM rue_mohr: you want to see the code or the makefile.
10:39 PM cehteh: no, the docs of the libc you use
10:42 PM rue_mohr: CFLAGS += -mcpu=cortex-m3 -mthumb -mfix-cortex-m3-ldrd -march=armv7-m
10:42 PM rue_mohr: CFLAGS += -mfloat-abi=soft -msoft-float
10:53 PM rue_mohr: I need a good cariable name for runtime-in-minutes-remaining