Back
[03:10:35] <Mali> Emil: simavr :
https://github.com/buserror/simavr
[03:14:51] <skz81> Simavr is quicker, but don't try to use timers with it. (simulavr has it's own problem too).
[03:17:21] <skz81> Funny enough, if Levitator was still here, my advice would be to run its code in a simulator (even Atmel Studio's simulator would do the job, but CLI simulator are maybe more reliable for logging data, like instruction list executed between boot and main() )
[06:16:33] <pepijndevos> What's the relation between the system clock and the io clock.
[06:52:12] <Lambda_Aurigae> system clock?
[06:52:22] <Haohmaru> i've only seen this in the xmega
[06:52:26] <Lambda_Aurigae> oh
[06:52:29] <Lambda_Aurigae> yeah...
[06:52:49] <Lambda_Aurigae> clki/o is just the main input clock divided by any prescaler.
[06:55:50] <Lambda_Aurigae> guessing someone hasn't done a search in a datasheet before asking this question?
[06:58:02] <Haohmaru> so i looked around into possible options for a script-like language to run on the avr as a way to let other coders actually control this whole board.. i looked into ada, forth, pawn, lua, micropython, angelscript, squirrel
[06:59:06] <Haohmaru> i really hoped for angelscript or squirrel to work, but it seems they both use some of the fancy things in C++11 (and STL) and i couldn't even build them on avr
[07:00:13] <Haohmaru> as for ada, i read some very good things, but it seems this is a whole language that just builds to machine code for the actual avr, thus no C or C++ together with it as i initially thought
[07:00:48] <Haohmaru> but if ada would work - it seems as if it could be even better than C/C++ for writing your whole firmware
[07:01:57] <Haohmaru> so now i am more and more considering rolling a custom bytecode VM.. i'm fine with that, but then the big issue with that is the actual language on the other end
[07:02:24] <Haohmaru> cuz those coders won't write in an assembler-like language for sure
[07:02:42] <specing> GNAT-GCC can compile ada to .net and some other stuff
[07:02:44] <Haohmaru> so i'd have to invent a language, and then a compiler too
[07:03:28] <specing> seems it can target the JVM as well
[07:04:26] <cehteh> Haohmaru ada is a compile language
[07:04:58] <Haohmaru> yeah, it's "serious"
[07:05:07] <cehteh> imo the best you can get are some forth implementatons, not as simple (featureless) than basic
[07:05:12] <specing> Ada is a systems programming language designed for embedded applications
[07:05:47] <cehteh> there are some stripped down lua variants, but still too big for an 8bit AVR,
[07:06:29] <cehteh> ans who posted lisp yesterday? should work a bit too, i always call lisp is forth in reverse :D
[07:07:19] <Haohmaru> tbh i don't like those with ":=" too much
[07:07:53] <specing> Haohmaru: you don't like those with assignment being assignment?
[07:07:55] <cehteh> syntax should be your least concern :D
[07:08:56] <specing> semantics are much better than in C
[07:10:01] <cehteh> i really think when one wants a serious (full) scripting language on avr's forth is the only way to go
[07:10:12] <Haohmaru> i was thinking about also making a tightly specific script-like language, which compiles into the specific C++ code to glue with my firmware, but this might be a dumb idea
[07:10:20] <cehteh> others work somewhat, but are limited, take too much resources etc
[07:10:48] <Haohmaru> in any case, i'd still have to write a compiler, but at least it might be easier, and then that would have to be compiler again with avgcc
[07:11:06] <cehteh> alternatively you can make a very simple stack machine, tying c functions to bytecode
[07:11:07] <Haohmaru> but no idea how that binary blob will get added to the firmware easily
[07:12:40] <cehteh> bootloader? or selfprogramming
[07:12:56] <Haohmaru> i basically want to expose a bunch of functions and events to a <reprogramable chunk of program> .. which would play the role of the decision-making entity ;P~
[07:14:04] <Haohmaru> otherwise i have to implement that myself, which means we'd have to coordinate more with those other coders during the developement
[07:14:10] <cehteh> but hey .. when you are in real need for some scripting language, just abadon avr and go for stm32
[07:14:29] <Haohmaru> right.. but that's more serious
[07:15:14] <Haohmaru> i know you can just stick almost any scripting language on that, even with built-in compiler
[07:15:33] <Haohmaru> i've seen lua/python and what not running on those 32bit cpus
[07:16:00] <Haohmaru> plenty of flash/ram
[07:16:06] <Haohmaru> plenty of MHz
[07:16:23] <cehteh> yes
[07:17:00] <Haohmaru> the whole setup is frightening me a bit
[07:17:05] <Haohmaru> compilers, programmers
[07:17:19] <specing> you think 8-bit 16 MHz avr is too small for scripts?
[07:17:32] <Haohmaru> no
[07:17:36] <specing> people used to compute stuff on 30 ton 10 Mhz cpus
[07:17:46] <specing> or even less Mhz.
[07:17:59] <Haohmaru> i just can't find a decent language for my specific purpose
[07:18:42] <Haohmaru> i can write my own bytecode, i think.. but i would still need an actual high-level language with it
[08:07:32] <inflex> ASM :)
[08:57:25] <bss36504> Haohmaru: The same crazy bastard that wrote the ARM emulator for AVR also wrote a pretty good JVM for AVR, if that interests you. Then any JVM-targeted language should work.
[08:58:02] <bss36504> Haohmaru:
http://dmitry.gr/index.php?r=05.Projects&proj=12.%20uJ%20-%20a%20micro%20JVM
[09:12:06] <Haohmaru> okay, this looks promising, given that it's written in C, i guess it should be easier to make it run on my xmega together with the C++ firmware
[09:15:13] <Haohmaru> but i read he has used a lot of asm to make this run fast, which might mean problems for xmega
[09:18:32] <bss36504> Where did you see that?
[09:19:04] <bss36504> I just skimmed through it again (i first read about it about a year ago) but I didnt see any notes indicating ASM was used
[09:19:36] <bss36504> In fact, he says he
[09:19:51] <bss36504> he's tested it on AVR and PIC controllers
[09:21:25] <Haohmaru> "which is why uJ has replacement 64-bit code for AVR hand-coded in assembly"
[09:21:49] <bss36504> do you need float support?
[09:21:52] <Haohmaru> if he used asm for one thing at least, he has probably used asm for other things
[09:21:54] <Haohmaru> no
[09:22:00] <bss36504> sorry, long long
[09:22:05] <Haohmaru> i just have a bad feeling
[09:22:13] <bss36504> Well download it and look!
[09:22:18] <Haohmaru> i think at most i'll ever use 32bit ints
[09:27:05] <Haohmaru> okay, this guy definately codes asm and likes it
[09:28:31] <bss36504> Haohmaru: I just did a search on the files; there are no asm sources which means that any asm is embedded in C files. I searched for 'asm' in all the files and found some only in the board setup files, which seem to have the code that copies the classes into flash. Youd have to roll your own function for that anyway, so wouldnt worry.
[09:59:35] <skz81> <specing> you think 8-bit 16 MHz avr is too small for scripts? >> IMHO, I don't think so, but memory (RAM & flash) are very tight to fit an interpreter into.
[10:00:28] <skz81> depends on the actual chip, indeed, but it tends to be tight
[10:00:46] <specing> compared to 30 ton machines from 50 years ago...its abundant :D
[10:03:56] <skz81> Maybe, but still not enough for this purpose:)
[10:40:25] <skz81> ho ! xmegas ! Did read that at the first place
[10:40:44] <skz81> n't*
[11:24:23] <_ami_> how is the performance of new and delete in avr? i am not calling it frequently though
[11:27:30] <LeoNerd> new/delete depend on malloc. You probably don't want malloc on an AVR
[11:54:35] <hetii> Hey :)
[12:01:35] <cehteh> its not only about performance, its about determinism and fragmentation .. it may fail and it may take unpredictable time
[12:01:48] <LeoNerd> Indeedy
[12:20:04] <_ami_> cehteh, LeoNerd: ok, good to know.
[12:20:24] <_ami_> what if i just do one time new? like its gonna live forever.
[12:59:08] <hetii> Could someone check my circuit and validate is everything is ok? :)
[12:59:11] <hetii> http://svgur.com/i/FW.svg
[13:00:00] <cehteh> lol
[13:00:12] <hetii> ?
[13:00:34] <cehteh> bit big to do that
[13:01:12] <cehteh> heatsink on the vreg? why that?
[13:02:50] <cehteh> lots of caps :)
[13:03:09] <hetii> thats why I ask for other eyes :) The heatsink will be just one for all MBR10100 diodes,LDOs and output transistors.
[13:04:06] <hetii> yep, I know its a lot of caps and also wonder if I should use such amount, but want to avoid any oscillation that can happen in it.
[13:04:26] <cehteh> why the 100nF caps around the rectifiers?
[13:05:35] <cehteh> i am not that much skilled that i can comment on all that
[13:05:54] <cehteh> like 10nF parallel to 100nF .. does that make sense?
[13:06:06] <cehteh> i mean wetcap and ceramic yes
[13:06:27] <cehteh> whats the whole thing about anyway?
[13:07:15] <hetii> cehteh: well general its a PSU where you can set output voltage and current.
[13:07:51] <cehteh> with 7805?
[13:08:38] <hetii> 7805 is used there just as a reference voltage for OPs
[13:09:08] <hetii> of course one is there as a power supply for ttyny45 and amp/volt meters
[13:09:27] <hetii> caps on rectifiers are a common way to eliminate noises
[13:09:59] <cehteh> i see
[13:10:00] <hetii> and 10nF can help to avoid oscillation on TL431
[13:10:51] <hetii> But general using 7805 as a voltage reference is optional, I don`t know use in final, LDOs or TL431
[13:11:41] <bss36504> hetii: I'll ask too, why put caps in parallel with the rectifier diodes? Wont they be low impedance to the AC and actually cause it to shoot through to the "DC" rails and not be rectified?
[13:12:36] <cehteh> i'd go for some more precise reference
[13:12:50] <bss36504> yeah, like an actual reference :P
[13:13:02] <bss36504> They make chips for that, you know
[13:13:08] <cehteh> and maybe only one, for both?
[13:13:28] <cehteh> 7805 have some tolerances
[13:14:11] <bss36504> right, if you use 7805, you have It's internal bandgap error plus the regulation error. If you use a real reference chip, it's output will be very tight and well characterized
[13:14:55] <bss36504> this is why "professional" PSUs cost $$$, the reference and all the things that it touches must have very low error and/or be easily compensated, eg. temperature compensated.
[13:16:36] <cehteh> i never designed such elaborate PS
[13:17:12] <cehteh> no idea if that'll work
[13:17:19] <bss36504> I've dabbled in the design, did lots of sims, lots of reading and learning, and decided the cost of parts and debug was better spent just buying one.
[13:17:46] <hetii> bss36504: as far as I know the caps in rectifier makes better parameters of each diode and also block hight frequency, there is no risk to use them.
[13:18:39] <bss36504> Then you have them configured wrong. Decoupling caps friom V+ to GND makes sense, but across the rectifiers????
[13:18:46] * bss36504 scratches head
[13:19:07] <cehteh> maybe ok, dunno
[13:19:12] <bss36504> As frequency increases, the impedance of the caps decreases.
[13:19:19] <bss36504> at DC they will look like an open.
[13:19:30] <bss36504> at 50/60 hz, they will look like a resistor (kind of)
[13:19:39] <cehteh> 100nF?
[13:19:44] <bss36504> so that means you basically have a resistor of some Xc in parallel with the diodes...
[13:20:01] <cehteh> 50hz does nothing to them
[13:20:08] <bss36504> what?
[13:20:23] <bss36504> its not about what the frequency does to them, its what they do to the operatioon of the circuit
[13:21:27] <bss36504> Xc @50hz and 100n = 1/2PiFC = 31uOhm. That's practically a short circuit at that frequency
[13:22:09] <bss36504> I mean, at like 1GHz+ it will start to look more like an open, but thats because of lead/trace inductance...
[13:22:31] <bss36504> hetii: Did you consider simulating parts of this in eg. LTSpice?
[13:23:09] <hetii> to be honest I saw such caps in many/many circuits: for eg:
https://pauls-amps.com/2015/06/10/homemade-hot-rod-plexi-50w-part-2-snubber-caps/
[13:23:18] <hetii> and also saw them in real devices
[13:23:56] <bss36504> lemme think on this for a few
[13:25:10] <bss36504> huh, learn something new everyday:
http://electronics.stackexchange.com/questions/14250/what-are-the-advantages-of-full-wave-bridge-rectifier-with-capacitors-parallel-t
[13:25:54] <cehteh> nice drawiing :D
[13:26:02] <bss36504> lol
[13:26:08] <bss36504> the comment below it made me laugh
[13:28:09] <cehteh> for a typical snubber it lacks the resistor, but it DC on that already so prolly ok
[13:28:40] <cehteh> DC with some ripple
[13:31:25] <hetii> So general I think it should work, and there was a question why there is two 7805 (or 4xtl431) a a reference voltage. The reason is that one is use GND and second GNDD, so one is for the voltage and second for current
[13:31:32] <bss36504> idk man, if it works then great. I cant wrap my head around why it wouldnt just be conducting. I mean, i realize that it's actually part of an RLC circuit so yeah sure something different must be happening in there, but I'm more of a visual learner, and i dont have time to do a simulation right now. I just get lost looking at all that math haha
[13:32:07] <hetii> what is not see in first shot in this circuit is that AMP meter make a resistance between GND and GNDD
[13:32:19] <cehteh> are GND and GNDD somehow coupled?
[13:33:40] <hetii> cehteh: yes, by amp meter or you can use resistor 0.1ohm/5W and use voltmeter instead.
[13:35:16] <cehteh> btw i dont know how the 78xx like ceramic caps on input and output, some older design vregs need some ESR or they start swinging
[13:36:01] <cehteh> dunno if thats the case for 78xx but i read that on some other datasheets
[13:36:45] <hetii> from datasheet I read that input capacitor is around 0.33uF and output 0.1uF and those was used for all charts
[13:37:13] <hetii> but of-course all depend on the current that is plan to get from them
[13:37:49] <hetii> I also read somewhere that is better to put smaller the higher capacitors for such LDOs
[14:31:43] <Emil> Anyone know of a good usbasp firmware that also allows spi data to flow through?
[14:44:39] <bss36504> flow through to where? like from the MCU to the MCU's slave? or from the MCU to the PC?
[14:49:49] <Emil> latter
[14:49:57] <Emil> And from the PC to the MCU
[14:50:08] <bss36504> naturally :)
[14:50:17] <bss36504> I dont know of one...could you roll it yourself?
[14:50:59] <Emil> Probably not, USB is my achilles heel
[14:51:02] <Emil> https://github.com/cnlohr/tinyispterm
[14:51:06] <Emil> there's this though
[14:52:06] <bss36504> What kind of device does the ASP enumerate as? Just a CDC device? If so, you wouldnt have to mess with the USB, you could just open a terminal to whatever serial port it's on
[14:53:53] <Emil> bss36504: it's custom
[14:54:17] <bss36504> ooooooof course it it
[14:54:21] <bss36504> it is*
[16:12:26] <mitsakos> hello everybody, i just upgraded my mac to El Capitan and i realized that avrdude is not finding my usbtinyisp any more. have you seen this before? "avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)
[16:23:09] <mitsakos> did i get any respone? sorry but i got a disconnect
[16:42:56] <crazy_imp> heyho
[16:43:44] <crazy_imp> are there any known bugs with gcc 6.2? (looked at the bugtracker and found nothing critical)
