Back
[03:08:29] <leehambley> could anyone point me in the direction of a guide/notes on using a state machine rather than a preemptive MT solution to MT on a tiny AVR ?
[03:10:01] <cehteh> with lots of switch/case statements .. or some event driven system, i am just programming
[03:11:20] <cehteh> http://git.pipapo.org/?p=battswitch.git;a=blob;f=src/battswitch.c;
[03:11:25] <cehteh> take a look there
[03:17:14] <osteri> i've tried this approach
http://johnsantic.com/comp/state.html
[03:17:51] <osteri> but ended up using switch/case due to its simplicity
[03:18:39] <cehteh> yes, you can make it table driven, but on a tiny its prolly better just hardcode it with switch/case
[03:18:53] <osteri> most likely switch/case is also faster
[03:19:12] <cehteh> if speed is a problem
[03:19:27] <cehteh> in my code i clock the tiny at 125 or 128 khz :)
[03:19:54] <apo_> faster, but uglier =P
[03:21:01] * cehteh works on a event driven system, one priority queue for timed jobs, 2 normal queues, one for realtime one for background jobs, all very tiny
[03:21:15] <cehteh> jobs == scheduled function calls
[03:21:38] <cehteh> other interrupts may push jobs on the queues as well
[03:22:06] <osteri> switch/case is not uglier, it's far more easier to understand than function pointer doing hideous state changes
[03:22:55] <osteri> and with complex systems it becomes horrible, when the state machine has many states/events
[03:24:10] <cehteh> yeah with the function pointer approach you have to document your state transitions properly
[03:24:20] <cehteh> code can become horrible to read
[03:24:53] <cehteh> but with some programming discipline that should be manageable
[03:25:52] <cehteh> besides .. you hardly write any complex system on a attiny :D
[03:28:47] <osteri> maybe a graph tool which produces state machine -code based on UML event-state-graph
[03:31:06] <cehteh> yes should be easy to do
[03:31:13] <osteri> then the function pointer stuff could work better
[03:31:49] <cehteh> well, i still prefer the other way around, first define the states and trasnsitions, then code
[03:32:00] <cehteh> so graphing afterwards wont help
[03:32:39] <cehteh> but defining states and transitions with some preprocessor macros wich either emit C code or graphviz .. could work
[03:33:11] <osteri> i mean other way around; do a graph and then produce code
[03:33:28] <cehteh> i like to keep this in sync
[03:33:46] <cehteh> having the graph in some textual description which validates or even generates the code
[03:34:03] <cehteh> generating a visual graph only for documentation
[03:35:51] <osteri> that's how state machines are easiest to design - by graph
[03:36:50] <osteri> any other way takes more time to understand how state machine works
[03:37:06] <cehteh> yes but there are nice textual representations of a graph too
[03:39:36] <osteri> by graph i mean mathematical definition, so it can and will be textual
[03:57:33] <leehambley> hey cehteh - sorry I missed your reply, thanks a lot
[03:59:08] <leehambley> I do wonder how this works with serial communications where timing is critical - but I think I have to play with it first before I can ask any intelligent questions
[04:00:17] <cehteh> you want to do the serial interrupt driven anyway
[04:02:04] <cehteh> so your state machine only fills buffers, sets up the hardware/interrupts .. maybe stays in a 'sending' state until it receives a finished event
[04:31:43] <leehambley> cehteh : thanks - that's a good note
[04:31:49] <leehambley> I'll look into that a bit more
[04:32:04] <leehambley> I hadn't consdiered how preemtpve MT might work with interrupt driven serial comms
[06:14:39] <Lambda_Aurigae> http://xkcd.com/1604/
[06:35:55] <Jartza> hello
[06:36:25] <Jartza> Lambda_Aurigae: started drawing diagrams for blog
[06:36:49] <Lambda_Aurigae> kewl
[06:38:03] <Jartza> https://drive.google.com/folderview?id=0B2dTzW9TMeBxTzI5X2I0VGVORVE
[06:39:24] <Jartza> of course those diagrams need explanation with them
[06:49:22] <Jartza> those diagrams are the hardest part :)
[06:50:54] <Jartza> https://github.com/Jartza/octapentaveega/tree/master/doc
[06:51:11] <Jartza> source of diagrams :)
[06:52:27] <Jartza> might be bit old as I haven't ran git push today
[07:34:40] <anonnumberanon> anonnumberanon> <Lambda_Aurigae> anonnumberanon, wire library is good for massive bloat.
[07:34:40] <anonnumberanon> <anonnumberanon> I know most Arduino libraries are bloat but I watched a video of this guy who did some optimization of code and showed how not to use the Arduino library in his quadcopter, yet, he kept using wire.h, so I'm thinking the wire library is not very slow if he uses it. Now maybe you were talking about code size which is very different from code execution speed.
[07:34:50] <anonnumberanon> ???
[07:35:37] <Tom_itx> bloat would cause both
[07:39:26] <anonnumberanon> bloat is a stupid term employed by smoke screen warriors
[08:43:20] <|DM|> Doesnt bloat just mean inefficient code ?
[08:53:08] <anonnumberanon> Depends whether you describe efficiency as easier and faster to write or producing better application results.
[09:11:41] <|DM|> No it doesnt
[09:12:11] <|DM|> The definition changes what each person considers bloat, but it doesnt change what bloat means
[09:56:27] <|DM|> what's the avr-gcc no crt option ?
[10:10:07] <|DM|> its -nostartfiles if someoen wonders
[10:10:16] <|DM|> now, I wonder if there's an unconditional skip
[10:28:32] <twnqx> anonnumberanon: IMHO, developer time is meaningless when it comes to code efficiency.
[10:28:39] <twnqx> but that's a point of view.
[10:36:47] <twnqx> wow. that moment when a 1.27mm pitch jtag header is too huge
[10:37:42] <twnqx> but i really fell problems scraping out another 3mm of pcb estate
[13:21:10] <twnqx> http://i.imgur.com/G5j3B9G.png next step: connect the parts...
[17:49:05] <Lambda_Aurigae> Jartza,
http://hackaday.com/2015/11/16/pea-whistle-steganography/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+hackaday%2FLgoM+%28Hack+a+Day%29
[17:49:18] <Lambda_Aurigae> transmitting data by whistle.
[22:44:01] <Jartza> Lambda_Aurigae: well THAT is neat :)
