#avr Logs
Mar 18 2018
#avr Calendar
12:10 AM day__ is now known as day
02:20 AM _nexxus__ is now known as _nexxus_
02:48 AM proteus-guy is now known as proteusguuy
04:46 AM Emil_ is now known as Guest29483
05:04 AM polprog: what a mess
05:04 AM polprog: kynar everywhere
06:26 AM nuxil: kynar?
07:10 AM Guest29483 is now known as Emil_
07:48 AM h4x0riz3d: polprog, https://i.imgur.com/NBZzEif.png
07:49 AM polprog: h4x0riz3d: nice :)
07:49 AM h4x0riz3d: and my own text is orange
07:53 AM h4x0riz3d: it wasn't easy to make hexchat look like that, i admit
07:54 AM * h4x0riz3d slaps rue_
08:07 AM polprog: h4x0riz3d: you slaped him so hard he fell of the bed :D
08:09 AM h4x0riz3d: >:)
09:31 AM nohitzzz2: synthedit was made in 1987 :o
09:32 AM h4x0riz3d: so it's one year older than me
09:33 AM nohitzzz2: do you know which platform it was back then
09:33 AM h4x0riz3d: no idea
09:34 AM polprog: i suck at remembering dates
09:35 AM polprog: i guess some unix
09:36 AM h4x0riz3d: synthedit was one of the main reasons why i went to learn C++
09:36 AM nohitzzz2: what are the differences with the demo and full product ?
09:37 AM h4x0riz3d: i don't know about the current version
09:38 AM h4x0riz3d: in v1.0x you were limited in presets (i think), and maybe also number of input/output channels in the exported VST, also, the name of the exported VST had "SynthEdit" in it
09:40 AM nohitzzz2: ok
10:21 AM Emil: I dont think 8 bit avrs have exceptions
11:21 AM nohitzzz2: here's a C oscillator module if anyone has use for this https://pastebin.com/kJtAaN76
11:21 AM nohitzzz2: should work with any microcontroller
11:27 AM nohitzzz2: im gonna ditch that since i'll be using floats and classes, makes everything so much easier
11:50 AM Ameisen: there's no particular reason you can't support C++ exceptions in AVR
11:50 AM Ameisen: I just suspect that they might have more overhead than is useful on it due to the ISA's constraints
11:50 AM Ameisen: on ARM or other 32-bit chips, they're often smaller/faster than error codes.
11:50 AM Ameisen: depending on use
11:51 AM Ameisen: Harder to say on AVR since it's a weird architecture
11:59 AM skz81: <Ameisen> there's no particular reason you can't support C++ exceptions in AVR >> there is !
11:59 AM skz81: aka unwinding
12:00 PM Ameisen: You can implement unwinding still. It's just going to be a major hassle.
12:01 PM Ameisen: and probably not worth it
12:01 PM * Ameisen had to port llvm-libunwind to MIPS
12:02 PM Ameisen: I can always tinker with it. The unwinding support code would probably bloat program memory a bit.
12:03 PM Ameisen: of course, you also save all the branches from traditional error codes (which is usually why exceptions end up smaller)
12:03 PM Ameisen: but AVR is weird and I suspect it will be way worse
12:19 PM skz81: Ha maybe you could, did check so deep. I stopped when I realized AVR-GCC doesn't offer it. Said to myself that it was for good reasons :)
12:19 PM skz81: did NOT* check
12:23 PM Emil: Ameisen: "what is an exception"
12:23 PM Emil: I thought you meant actual hardware exceptions
12:24 PM Emil: like division by zero
12:24 PM Emil: Which arm has
12:24 PM Ameisen: I presume when yo usay avr-gcc doesn't offer it, that GCC's libunwind doesn't support AVR?
12:25 PM Ameisen: not hard to implement the basic unwind routines for any arch. It's basically just saving/restoring the registers
12:26 PM Ameisen: a little ackward on MIPS due to one of the registers _always_ being populated by the return address of a function call, though
12:26 PM Ameisen: so you end up using a delay branch and reseting the register in the delay slot
12:27 PM skz81: Ameisen, I mean -funwind-tables is not supported, then -fexceptions neither.
12:28 PM Ameisen: I'd have to check why they have it disabled
12:28 PM Ameisen: 99% chance it's because AVR is _barely_ supported on GCC (I think it has... like... 0.5 developers), active bugs aren't being fixed, and there isn't much demand for it
12:29 PM Ameisen: I know avr-llvm can do it
12:29 PM Ameisen: but I am not presently highly active in it
12:29 PM Emil: ah you meant "exceptions"
12:30 PM Ameisen: my last work on it was working on the strength reduction code for shifting
12:30 PM Ameisen: since it was awful
12:30 PM Ameisen: also greatly improved some parts of AVR codegen so it would recognize when certain parts of composite types were a known value
12:30 PM Ameisen: IIRC the guy leading AVR did take those from my repo
12:31 PM Ameisen: or at least he said he was gonna
12:31 PM skz81: RAM size can become quickly a problem too.
12:31 PM Ameisen: yup
12:31 PM Ameisen: the tables can be kept in flash memory. No reason for them to be in SRAM.
12:31 PM Ameisen: _generally_, they are quite small. But 'small' has a different definition on AVR.
12:31 PM Emil: Some 60 stacks with on 2048k
12:31 PM Emil: 2048 bytes*
12:31 PM Ameisen: On Cortex-M, unwind tables and exceptions generally make smaller binaries than C error codes
12:32 PM Ameisen: but on AVR, you have other restrictions, like pointers being composite types
12:32 PM Ameisen: the compiler already sucks at handling that
12:32 PM Ameisen: which is a known but not-going-to-be-fixed optimizer issue
12:32 PM skz81: humm I was thinking of saving (nearly?) all the registers for each frame
12:32 PM Ameisen: optimizer is bad at optimizing code where word size < pointer size
12:33 PM Ameisen: it has almost no capability for split types, either
12:33 PM Ameisen: a uint16 will basiclaly always be jammed into a register pair because the optimizer 'presumes' it will be used for a pointer
12:33 PM Ameisen: which causes problems with register pressure
12:34 PM Ameisen: LLVM can handle it, but it needs a lot of work in strength reduction code for AVR.
12:34 PM Ameisen: I also know that the main developers for avr-gcc are openly saying people should work on avr-llvm instead
12:34 PM Ameisen: they are _not_ happy with the gcc maintainers
12:34 PM Ameisen: also, because they told me that directly as well
12:34 PM Ameisen: and in blogs and so forth
12:35 PM Ameisen: I was trying to add address space extensions to g++, was basically told not to bother - it would never be approved as a patch, and LLVM already supported it.
12:35 PM Ameisen: :|
12:35 PM Emil: Those people should't be the maintainers of avr-gcc if they say that
12:35 PM Ameisen: well, the g++ maintainers are apparently real sticklers for the spec
12:36 PM Ameisen: except in cases where they don't care.
12:36 PM Ameisen: So, because the C Embedded Extensions spec was never approved for C++, they refuse to support it in g++
12:36 PM Ameisen: although there are TONS of other instances where gnu extensions exist.
12:36 PM Ameisen: it's a weird double standard. I suspect it's because there's so few AVR developers working on GCC that they don't want to support an extension that would basically be just for AVR and other uarchs
12:37 PM Ameisen: the gcc-side has support for it because it was originally supported there (it's in the spec)
12:37 PM Ameisen: the C++ proposal is still floating around, though they need to actually reformat it
12:37 PM Ameisen: it literally is just "Hey, I copy-pasted the C spec for it here, we should do this"
12:37 PM Ameisen: they need to rewrite it to be C++-contextual
12:38 PM Ameisen: I might do that. I know how to contact a few committee members, so I may try to just drive up support for it. It's na optional extension, but having it actually supported/approved would be helpful in forcing the maintainers' hands
12:38 PM polprog: 2.3Kbytes of flashed in 77sec. Default avrdude settings. thats my new personal anti record
12:38 PM polprog: [its now veryfying lmao]
12:38 PM Ameisen: polprog - if you start doing larger AVR projects, you should look at my build scripts
12:38 PM Ameisen: they are designed to build/flash very quickly
12:38 PM polprog: my makefile setup is just make && make flash
12:39 PM Ameisen: they to full dependency scans on c/c++ source files, multithreaded, and also do the compile multithreaded.
12:39 PM Ameisen: without requiring makefiles.
12:39 PM Ameisen: and the hassle of maintaining them
12:39 PM Emil: polprog: wtf
12:39 PM Ameisen: also 77 sec is slow
12:39 PM Emil: polprog: disable clock division by 0
12:39 PM Emil: polprog: disable clock division by 8*
12:39 PM polprog: Emil: yeah
12:39 PM polprog: but, but
12:40 PM Ameisen: one downside of the scripts presently is that they cannot be told which source files to include (isn't hard to add, just haven't done it)
12:40 PM Emil: polprog: it's the first thing I ever do on new avr :D
12:40 PM Ameisen: you tell them which directories to scan, and they include the source files there.
12:40 PM polprog: i used to flash 7 kb firmwares and it would take max 10 sec!!!
12:40 PM Ameisen: scripts presently work for AVR and for ARM
12:40 PM Ameisen: currently adding Clang support for ARM
12:40 PM polprog: and thats default settings of avdude! avrdude -c dragon_isp -p m8 -U flash:w:main.hex
12:40 PM Ameisen: meaning I have to build some build scripts to build compiler-rt
12:40 PM Ameisen: :|
12:40 PM polprog: that simple. wtf
12:41 PM Ameisen: lemme check my AVR deploy script. ARM deploy script isn't done since... there's no universal ARM flasher or bootloader
12:41 PM Ameisen: Teensy has its own, STM has its own
12:41 PM Ameisen: they all have command-line operated versions, it's just you have to know which to use
12:41 PM Ameisen: https://github.com/ameisen/Tuna-i3-Plus/blob/master/Tuna/deploy.rb
12:42 PM Ameisen: can either be told an explicit port, or will find the port itself
12:42 PM Ameisen: currently only set up for 2560
12:42 PM polprog: i really need to know wtf is wrong. ill run it with -v
12:43 PM polprog: ruby wow.
12:43 PM Ameisen: I use Ruby a lot for scripting
12:43 PM Ameisen: if I find I need a lot of script performance I switch to C++ for it
12:43 PM Ameisen: but the overhead is almost always in the calls
12:43 PM Ameisen: I generally prefer it if my tools are portable, and don't have to be built.
12:43 PM polprog: this so much
12:43 PM nuxil: Ruby. people still use that stuff ?
12:43 PM Ameisen: especially my build tools.
12:44 PM Ameisen: nuxil - yeah
12:44 PM Ameisen: I never bothered to learn python
12:44 PM Ameisen: ruby works
12:44 PM Ameisen: could be worse
12:44 PM Ameisen: could be using perl or php
12:44 PM nuxil: pythom ftw when it comes to scripting :p
12:44 PM Ameisen: still
12:44 PM Ameisen: my multithreaded ruby build system works fine
12:44 PM Ameisen: no reason to change it
12:44 PM Ameisen: it's friggin' fast
12:44 PM polprog: im very often trying to build some project and it just wont.. usually texinfo is the problem - but i have that installed o_o
12:44 PM nuxil: python isnt much to learn. its dead simple
12:44 PM Ameisen: my AVR firmware takes 7 seconds to compile and link
12:44 PM Ameisen: and that's with a ton of optimization options and LTO
12:45 PM Ameisen: Yes, but there's no good reason to rewrite the script
12:45 PM Ameisen: it works and is simple to change
12:45 PM Ameisen: I don't gain anything switching to Python for it
12:45 PM polprog: my "make" invocation takes 0.051sec to actually build...
12:45 PM Ameisen: your source is also like 1 thousandth the size of mine.
12:45 PM Ameisen: :|
12:45 PM polprog: might as well paste this here
12:45 PM polprog: 11:43 < polprog> im trying to build insight. Im getting this error http://paste.debian.net/1015324/ can someone tell me whats wrong? im reading that log and have no idea
12:45 PM polprog: bloody texinfo
12:46 PM polprog: its not the first time i cant build something
12:46 PM Ameisen: Are you trying to build avr-gcc?
12:46 PM Ameisen: not sure what insight is
12:46 PM * Ameisen is a simple man
12:46 PM polprog: no, a gdb frontend earlier today
12:46 PM Ameisen: ah
12:46 PM Ameisen: because I have 'make an embedded compiler toolchain for AVR and ARM and put it on my site' on my list of things to do
12:47 PM Ameisen: that includes some embedded extensions
12:47 PM Ameisen: like float24, float16, uint40/48...
12:47 PM Ameisen: Possibly alternate-format floats as well.
12:48 PM Ameisen: if you aren't using IEEE-compliant floating-point math ('fast math'), you can disable a lot of the 'special' ranges of the float values that correspond to things like nans and such, and gain an extra bit of precision
12:48 PM polprog: like fixed point?
12:48 PM Ameisen: no, still floating-point
12:48 PM polprog: ah
12:48 PM polprog: fixed could be useful as well
12:48 PM Ameisen: by default, soft-FPU emulates IEEE754
12:48 PM Ameisen: if you don't need full compliance, you can gain an extra bit of precision and a little performance
12:49 PM Ameisen: almost nobody does need full compliance on AVR
12:49 PM Ameisen: GCC has limited support for fixed
12:49 PM Ameisen: it has a single fixed-point type in C only
12:49 PM Ameisen: I don't recall what it is - I think it's 16:16
12:49 PM Ameisen: If you need it in C++...
12:49 PM Ameisen: https://github.com/ameisen/Tuna-i3-Plus/blob/master/Tuna/tunalib/fixed.hpp
12:49 PM Ameisen: much more flexible.
12:50 PM Ameisen: Interestingly, GCC supports 16-bit floats in ARM
12:50 PM Ameisen: but not AVR
12:50 PM Ameisen: odd decisions were made.
12:51 PM Ameisen: since everything that's not a uint8 in AVR is a composite type... there's no reason to support everything
12:51 PM h4x0riz3d: maybe that support was added by some ARM-fanboi
12:51 PM h4x0riz3d: ;P~
12:51 PM Ameisen: It's probably added by ARM
12:51 PM Ameisen: ARM has their own official branch in the GCC codebase for ARM Embedded
12:51 PM h4x0riz3d: ah, they are ARM-fanbois, aren't they? ;P~
12:51 PM Ameisen: there's no equivalent from Atmel
12:52 PM polprog: ok. UART working. Time to attach the sensor and start dumping data
12:52 PM Ameisen: there's a reason that ARM is winning out :|
12:52 PM Ameisen: well, also the fact that ARM chips tend to be cheaper and faster than AVR
12:52 PM Ameisen: and Atmel hasn't done much to reduce the cost or improve peformance
12:52 PM Ameisen: I don't think anyone is using xmega or avr32
12:53 PM Ameisen: not sure what their market is. They compete _directly_ with Cortex M
12:53 PM Ameisen: and... do so poorly
12:53 PM Ameisen: though I am curious if RISC-V will enter the MCU market
12:53 PM h4x0riz3d: i use xmega! >:(
12:53 PM h4x0riz3d: xmega ftw
12:53 PM Ameisen: Ah, so you're the guy
12:53 PM Ameisen: :)
12:54 PM h4x0riz3d: xmega is much x, very mega
12:54 PM Ameisen: if ARM released a _more_ standardized Cortex M spec that also standardized register layouts and startup schemes, I think it would be more popular for MCUs
12:54 PM polprog: dont forget about sparc based LEONs in space :D
12:54 PM Ameisen: as it is, you have to have unique startup code for basiclaly every ARM chip
12:54 PM Ameisen: since they're all different
12:54 PM Ameisen: gotta love it when they have a split memory layout, and gnu ld cannot handle split layouts
12:54 PM h4x0riz3d: btw, Ameisen, not sure what you're doing, but xmegas are much easier to deal with in C++ IMO
12:54 PM Ameisen: might add it to lld
12:55 PM polprog: if you are bored, write a BIOS for arm
12:55 PM Ameisen: h4x0riz3d - how so?
12:55 PM polprog: so you can use int 10h :D
12:55 PM h4x0riz3d: compared to the atmegas
12:55 PM Ameisen: I havne't had any real issues in C++ with AVR, other than the fact that g++ doens't support __flash
12:55 PM Ameisen: which is an annoyance
12:55 PM Ameisen: a big one
12:55 PM Ameisen: just give me type-safe flash-relative pointers.
12:55 PM Ameisen: adding address spaces to g++ is like a 2 day job
12:56 PM Ameisen: the middle end clearly supports it because gcc uses it
12:56 PM h4x0riz3d: Ameisen basically, the IO and registers are layed out in big structures, so they are kept identical and consistent (this wastes a pile of RAM, but who cares)
12:56 PM Ameisen: does xmega still have program-memory/sram split completely
12:56 PM Ameisen: using different address spaces?
12:56 PM Ameisen: or does it have a unified address space
12:57 PM h4x0riz3d: so you have a PORT_t structure and say 5 instances of that declared for each port
12:57 PM Ameisen: polprog - BIOS is deprecated even on x86 systems
12:57 PM Ameisen: if you're gonna port something, port EFI
12:57 PM h4x0riz3d: or a USART_t structure, etc..
12:57 PM polprog: Ameisen: ikr. joking :)
12:57 PM Ameisen: ARM has similar
12:57 PM Ameisen: though a lot of the system headers for ARM don't expose it well
12:57 PM Ameisen: I hate seeing this:
12:58 PM Ameisen: #define PORTB (*(volatile uint32 *)0x00FF0012)
12:58 PM h4x0riz3d: yeah
12:58 PM Ameisen: according to g++, that's a reinterpret cast.
12:58 PM Ameisen: guess what isn't allowed to be in a constant expression in C++?
12:58 PM h4x0riz3d: in xmega you have a PORT_t structure declared at specific offsets for PORTA, PORTB, etc..
12:58 PM Ameisen: so even though you _know_ the address already at compile time, you are not allowed to use it because they already defined them as reinterpret casts in their header.
12:58 PM Ameisen: it's stupid
12:59 PM Ameisen: though I wish gcc had an __attribute__((address:)
12:59 PM polprog: Ameisen: waht does that mean in practice?
12:59 PM h4x0riz3d: doesn't it?
12:59 PM Ameisen: polprog - I tend to generate compile-time data structures to do things like optimize GPIO accesses
12:59 PM polprog: ?
12:59 PM Ameisen: I cannot do that using the system headers because those values are not legal for constexpr
12:59 PM Ameisen: the weird cast they perform violates the spec
12:59 PM polprog: huh
12:59 PM Ameisen: if they left it as an integer, I could.
01:00 PM Ameisen: it's an arbitrary restriction that causes me problems.
01:00 PM polprog: so (*(volatile int*) ...) ?
01:00 PM Ameisen: an overly strict spec, and weird-looking cod.e
01:00 PM Ameisen: yeah
01:00 PM polprog: hmm
01:00 PM Ameisen: casting from an integer to a pointer is not legal as a constant expression in C++
01:00 PM Ameisen: C has no concept of constant expressions at all so it's not an issue there
01:00 PM Ameisen: as C cannot do compile-time code generation.
01:00 PM polprog: i dont understand. both are integers
01:00 PM h4x0riz3d: i've been trying to use C++11 and template metaprogramming for making code more optimal
01:01 PM Ameisen: both C and C++ define pointers as 'kind of integers'
01:01 PM Ameisen: they are integral values, but are distinct types from integers.
01:01 PM Ameisen: they are not 100% compatible
01:01 PM h4x0riz3d: i started with a buffered usart class for the atmega
01:01 PM Ameisen: C++ is more strict about it
01:01 PM polprog: okay
01:01 PM Ameisen: h4x0riz3d - if you want, you can look at my thermal management code
01:01 PM Ameisen: if you havne't already
01:01 PM h4x0riz3d: wut it has?
01:02 PM Ameisen: it basically is just a codegen routine which uses a table of ADC values -> temperatures, and optimizes the lookup routines at copmile-time, and autogenerates branches
01:02 PM Ameisen: so the lookup routine is as fast as it can be
01:02 PM h4x0riz3d: what i'd really like is to be able to see the resulting C/C++ code when i instantiate this template object
01:02 PM Ameisen: -S
01:02 PM Ameisen: you'll see it at instantiation
01:02 PM polprog: if i have enum like values (state machine state identifiers) as a serie of defines, should i put those defines in .c or .h ?
01:02 PM Ameisen: https://github.com/ameisen/Tuna-i3-Plus/blob/master/Tuna/thermistors/thermistortable_1.h
01:02 PM h4x0riz3d: use an enum!
01:03 PM polprog: h4x0riz3d: wont that take more ram?
01:03 PM Ameisen: why would it
01:03 PM polprog: no idea
01:03 PM polprog: guess i will
01:03 PM polprog: never really used enums outside Java
01:03 PM polprog: :D
01:03 PM Ameisen: C++ has enum class which is useful. Can also specify the underlying type of an enum.
01:03 PM Ameisen: enum class foo : uint8_t { ... }
01:04 PM Ameisen: enum class implicitly tells the compiler that anything that is of type 'foo' will only ever be one of the values it defines.
01:04 PM Ameisen: so it enables some more optimizations
01:04 PM Ameisen: normal enum mandates no such thing
01:04 PM h4x0riz3d: Ameisen i don't understand that new C++ crazyness
01:04 PM Ameisen: enum class = type-safe enum
01:04 PM h4x0riz3d: i have a _lot_ to catch up x_x
01:04 PM polprog: so that enum. usually goes to .c file?
01:04 PM Ameisen: variables of an enum class type can only be values that are defined for the enum class
01:04 PM Ameisen: nothing else
01:05 PM Ameisen: legally
01:05 PM Ameisen: makes the code a bit more sane usually, and enables optimizations
01:05 PM Ameisen: I also tend to use lambdas heavily as for whatever reason g++ is better at figuring out to inline lambdas than free functions
01:06 PM Ameisen: it SHOULD treat them equally, but meh
01:07 PM polprog: lambdas look awesome
01:08 PM polprog: i forgot they existed
01:08 PM polprog: lol
01:08 PM polprog: kinda like anonymous functions in java [i think they were called like that]
01:08 PM Ameisen: It took me a while to figure out the new C++ features as well
01:08 PM Ameisen: but once you're used to them...
01:08 PM Ameisen: they're incredibly useflu
01:08 PM Ameisen: useful*
01:08 PM polprog: i dont program big stuff in C__
01:08 PM Ameisen: same principle.
01:08 PM Ameisen: a lambda is just a kind of closure
01:09 PM polprog: i should. i should go back to my scope demo project
01:11 PM Ameisen: Presently writing a simple clang-based build script to buidl the clang runtimes
01:11 PM Ameisen: the runtimes are only 'kind of' part of an llvm build unlike in gcc
01:11 PM Ameisen: where glibc is part of gcc
01:11 PM nuxil: lambdas.. only a insane person will use it by their free will :p
01:12 PM nohitzzz2: #define's go to the .h file
01:12 PM nohitzzz2: like register names and bits etc.
01:13 PM rue_: polprog, :) you know what a state machine is, I'm sure glad I'm not the only one in the world
01:13 PM rue_: I only number my states
01:13 PM Ameisen: I like this clang option
01:13 PM rue_: which makes for fun on a piece of paper somewhere
01:13 PM Ameisen: -fheinous-gnu-extensions
01:14 PM Ameisen: handles this case: https://searchcode.com/codesearch/view/16336915/
01:14 PM Ameisen: which is a gnu extension
01:15 PM Ameisen: apparnetly there's actually some libraries that rely on giving values to nop?
01:18 PM polprog: doesnt that second asm block miss a colon?
01:21 PM chat is now known as Guest7011
01:36 PM polprog: this speed is a joke lol
01:45 PM polprog: looks like its fixed
01:45 PM polprog: takes 5 sec now
01:48 PM skz81: <polprog> if i have enum like values (state machine state identifiers) as a serie of defines, should i put those defines in .c or .h ? >> If needed only in .c you can put them there, but if anything else manipulates (even just read) you machine's state, you'll need those #defines in both, then .h
01:49 PM skz81: and non, enum doesn't eat RAM, neither does C++ class-enum...
01:49 PM polprog: turned out i dont need a state machine atm, testing the distance measurement part in blocking mode
02:01 PM polprog: bbl
03:02 PM * Ameisen watches clang try to build newlib
04:33 PM Ameisen: Well, I think I just successfully built newlib
04:33 PM Ameisen: really fast, too
05:11 PM polprog: im back into avr messing
05:12 PM polprog: trying to get the chineese arduino distance sensor working with a simple blocking implementatiom
05:12 PM polprog: tion*
05:12 PM Emil: polprog: you mean those ping pong sensors?
05:13 PM polprog: i was planning to do it with an external interrupt initially
05:19 PM Emil: https://emil.fi/d/ping.c
05:19 PM Emil: I wrote that for some guy who previously asked about them
05:19 PM Emil: if we are talking about the same type of sensor
05:19 PM polprog: https://puu.sh/zKxJL/3bcacb8c68.jpg
05:19 PM polprog: hc-sr04
05:19 PM Emil: yeah should be similar
05:19 PM polprog: i must have forgotten a tiny bit of code. the sensor is triggering and returning the ping. maybe the TCNT is not running... maybe the pin state wait loops are skipping....
05:19 PM Emil: try and see if my code works
05:19 PM Emil: I dont know
05:19 PM Emil: never tested it
05:19 PM Emil: its for m328p
05:19 PM polprog: return(0); //Magic
05:19 PM polprog: thou shall not
05:19 PM polprog: ?
05:19 PM polprog: you know im a fan of the m8 ;) my first chip
05:19 PM polprog: i need to get it working
05:19 PM polprog: moar debugs everywhere. maybe get the analyzer running
05:19 PM polprog: but ill sit to work on that maybe tomorrow. depends on the level of work at school.
05:19 PM polprog: hmn analyzer is a good idea. that or spitting single characters via uart
05:19 PM polprog: although at 9600 baud it may be too sloe
05:19 PM polprog: slow*
05:19 PM polprog: i guess i will just toggle some pins and examine with the analyzer
05:19 PM Emil: >9600
05:19 PM Emil: pls no
05:19 PM polprog: that or 115200. the only two right baudrates
05:19 PM Emil: >11500
05:19 PM Emil: polprog:
05:19 PM Emil: I expected more of you
05:19 PM Emil: 250k/500k/1M or go home
05:21 PM polprog: if i had a 20mhz xtal i'd pump up to 2 megabaud
05:21 PM Emil: You can't
05:21 PM Emil: 20MHz doesn't work for 2M
05:21 PM polprog: 9600 is nice because it will work on stock clock setup. if you enable u2x
05:21 PM polprog: oh yeah i remember
05:21 PM polprog: there were those weird clocks for super fast uarts
05:21 PM Emil: 2M does work on 16MHz
05:21 PM Emil: But you can't receive anymore iirc
05:21 PM Emil: Or wait you could dunno
05:22 PM polprog: at that point you can just take a small fpga with a 100mhz clock and throw paralell data at it so it makes some crazy usart out of it
05:22 PM Emil: why?
05:22 PM Emil: If an AVR works ;)
05:22 PM polprog: because fast
05:22 PM Emil: Also
05:22 PM polprog: lol no dma
05:22 PM Emil: So?
05:22 PM Emil: :D
05:22 PM polprog: i wonder if stm8 has dma :/
05:23 PM polprog: probably not
05:23 PM Emil: Also the maximum datarate of an avr is 160Mb/s
05:23 PM Emil: You can push 160Mbits per second out of it
05:23 PM Emil: at 20MHz
05:23 PM polprog: 20MHz paralell?
05:23 PM Emil: yeah
05:24 PM Emil: The issue is with synchronisation
05:24 PM cehteh: but how does it matter when you cant do anything else :)
05:25 PM Emil: cehteh: because you don't push 160Mbit out all the time ;)
05:25 PM polprog: 8 usarts at once via precalculted array with start and stop bits \o/
05:26 PM Emil: Using a PISO we can generate fast bitstreams
05:28 PM Emil: Using the Clock output as clock we can drive the full 160Mbit/s out of an avr
05:28 PM Emil: in a serial stream
05:30 PM polprog: ld, out, thats 3 clock for a b(it|yte); cant go faster :(
05:30 PM Emil: Because we can have a preset packet header (and trailer) in program memory and use the 32 (well 16?) registers for user data
05:30 PM polprog: well, that makes sense
05:31 PM polprog: but thats only 16 bits of actual data
05:31 PM Emil: 16 bytes
05:31 PM Emil: of actualy data
05:31 PM polprog: yeah
05:31 PM Emil: and 32 if all the registers were usable
05:31 PM Emil: I don't remember if there was a limitation on that
05:31 PM Emil: also
05:31 PM Emil: also
05:31 PM Emil: wait they were io registers nvm
05:31 PM Emil: (those general purpose registers that were not used for anything)
05:32 PM polprog: you canot ldi to lower half of the file... if you already had all of them initialized you could make a burst of 32 bytes
05:32 PM Emil: of course first initialised
05:32 PM polprog: interesting
05:33 PM Emil: polprog: burst of 32 variable data and n bytes from program memory directly
05:33 PM Emil: n fixed bytes
05:33 PM Emil: and often your data has a format
05:33 PM polprog: from program memory? that would take longer to access
05:34 PM Emil: polprog: ldi with fixed value
05:34 PM Emil: PORTX=123;
05:34 PM polprog: oh. but ldi and out thats two clocks
05:34 PM polprog: you cant ldi to an io register
05:34 PM Emil: Ah yeah
05:34 PM Emil: true
05:35 PM polprog: shame
05:36 PM Emil: well lets just overclock to 32MHz :)
05:36 PM polprog: haha
05:38 PM polprog: amazing how in the 90s PC were still in the MHz ranges and nowadays were just messing with 20MHz chips for no money
05:38 PM chat is now known as Guest70454
05:38 PM polprog: not even mentioning hundred mhz arms
05:43 PM Emil: well
05:43 PM Emil: you are somewhat wrong ;)
05:43 PM Emil: In the 90s we were well over in the hundrerds of megahertz range
05:43 PM Emil: hundreds*
05:43 PM polprog: couple hundreds
05:44 PM Emil: Oh you actually were right
05:44 PM Emil: 94 75MHz Pentium
05:45 PM Emil: but 95 and we are 180MHz already
05:46 PM Emil: 99 AMD Athlon at 750MHz
05:46 PM Emil: and 90 Mac 40MHz
05:47 PM Emil: Fast development in the 90s
05:47 PM Emil: it seems
05:47 PM polprog: indeed
05:47 PM polprog: 95 ~200mhz. mine is 167mhz
05:47 PM polprog: also from 95
06:02 PM polprog: niters Emil
06:04 PM Emil: polprog: good night
06:32 PM Rez is now known as LoRez
06:32 PM PsySc0rpi0n is now known as HelloShitty
09:05 PM chat is now known as Guest910