Back
[00:24:10] <enhering> to capture the logs, CapnJ
[00:24:16] <enhering> Probably.
[00:25:13] <CapnJ> can't there be like one "log bot" that writes everything to a blog or something?
[00:25:14] <enhering> My modules are finally talking to each other:
https://hackaday.io/project/11724-yauvc-yet-another-unmanned-vehicle-controller/log/53084-sensor-data-via-wifi-and-serial-connection
[00:25:21] <enhering> There is one.
[00:25:37] <enhering> It was mentioned a few days ago.
[00:25:43] <CapnJ> Hey I renember you enhering
[00:25:49] <CapnJ> how's your project doing?
[00:26:35] <enhering> https://hackaday.io/project/11724-yauvc-yet-another-unmanned-vehicle-controller/log/53084-sensor-data-via-wifi-and-serial-connection
[00:26:48] <enhering> Today i reached a milestone.
[00:27:02] <enhering> Next step is the servo module.
[00:27:19] <enhering> But I still have to wait for some components
[00:28:39] <enhering> Thanks for your help.
[00:28:45] <enhering> It made a difference
[00:32:24] <enhering> Have you seen carabia recently?
[00:32:47] <CapnJ> nop
[00:32:59] <enhering> vanished
[00:33:46] <enhering> Visited the link?
[00:34:36] <enhering> The english is so bad, but I believe the message can be understood
[00:36:45] <enhering> 3 am here. I'll go to bed.
[00:36:51] <enhering> See you, CapnJ
[00:39:09] <CapnJ> see you enhering
[01:00:55] <rue_house> enhering, what was the bug?
[03:05:13] <hetii> Good morning :)
[05:16:03] <Lambda_Aurigae> enhering, when you mentioned my na e I was dead asleep.
[05:41:57] <_ami_> Lambda_Aurigae:
https://hackaday.io/project/11724-yauvc-yet-another-unmanned-vehicle-controller/log/53084-sensor-data-via-wifi-and-serial-connection --> he mentioned ur name here too. - popular one! ;)
[05:42:09] <_ami_> enhering: ^
[05:46:55] <Lambda_Aurigae> yeah...I saw it..was just mentioning, I didn't comment at the time as I was asleep.
[08:25:25] <enhering> https://hackaday.io/project/11724-yauvc-yet-another-unmanned-vehicle-controller/log/53084-sensor-data-via-wifi-and-serial-connection
[08:26:22] <specing> I wonder how many kg of li-ion one needs to lift a person
[08:27:15] <enhering> It depends on efficiency. If you use a wheel and ropes, You may even need the same number of kg.
[08:27:26] <specing> lol
[08:29:01] <specing> I'm sure a single 18650 (50g) could lift me up a couple meters high by winch
[08:31:35] <specing> Btw --
http://www.banggood.com/Eachine-Customized-Version-F3-Racing-Deluxe-10D-Flight-Controller-STM32F303-For-Eachine-Racer-250-p-1060619.html
[08:31:54] <specing> 5 grams with all the bells & whistles
[09:11:42] <skz81> mmm i'm reading that : lib.chipdip.ru/286/doc000286027.pdf
[09:12:02] <skz81> (ethernet iterface chip through SPI)
[09:12:34] <skz81> i'm a bit puzzled by "datagrams" pages 27 and next.
[09:13:19] <skz81> It seems like the chip operates only in a kind of "half-duplex" mode ? I mean, I can't write a new command while reading previous results ?
[09:14:12] <skz81> If so I guess I could save one pin by driving smartly SCK (by software it sounds easy, unsure w/ HW)
[09:14:57] <skz81> driving smartly SCK : i.e. giving enough time for the pin to revert I/O direction
[09:15:27] <skz81> for the DATA* pin to revert I/O direction, even
[09:24:18] <Jartza> evening
[09:50:15] <skz81> evening Jartza
[10:20:30] <Lambda_Aurigae> skz81, look at the tuxgraphics tcp/ip stack for the avr and enc28j60
[10:25:53] <skz81> Lambda_Aurigae, a real mine of knowledge for what I want to do, but a bit overwhelming to dig out for my answer about SPI "duplexness" of this chip
[10:26:01] <skz81> thanks anyway, will be useful :)
[10:26:46] <Lambda_Aurigae> sorry I didn't have the direct answer....I have only used their stack with that chip.
[10:27:19] <Lambda_Aurigae> you could also look at procyon avrlib and see how they handle the enc28j60.
[10:28:28] <skz81> but did you (or everyone else) ever see a slave that either listen or talks, but never both ?
[10:28:43] <skz81> SPI* slave
[10:29:47] <Lambda_Aurigae> can't say as I have..
[10:34:04] <Lambda_Aurigae> but, I don't do a lot of spi myself.
[10:34:11] <Lambda_Aurigae> I prefer the more complex i2c
[10:34:17] <skz81> OK. I wonder if it is an accurate description of the behaviour or "only" a misleading description...
[10:34:29] <Lambda_Aurigae> probably somewhat misleading.
[10:34:31] <skz81> it is not an actual problem though, I'm still putting bits of knowledge together...
[10:34:40] <Lambda_Aurigae> check out microchip's eratta sheets.
[10:34:41] <skz81> yup, prolly :)
[10:35:15] <skz81> thanls I will. I can also make some try later if/when I get the piece
[10:36:26] <Lambda_Aurigae> they are a nifty little toy.
[10:36:39] <Lambda_Aurigae> not high speed but with that tuxgraphics library they are very functional.
[10:36:58] <Lambda_Aurigae> I've expanded that lib to feed up to 8K sized pages from an atmega1284p.
[10:37:38] <Lambda_Aurigae> it's written for an atmega 8 or 88
[10:37:44] <Lambda_Aurigae> with very limited ram..
[10:37:48] <Lambda_Aurigae> but still functional.
[10:40:16] <skz81> nice : ) I don't need much speed here, want try to do an ethernet power switch. Had one for some purpose at work but the resource was preempted ... Because it cost ~400€ ! My company said they would avoid to buy new ones, I my need was not a real need (I must admit it was a "in case of")
[10:41:57] <Lambda_Aurigae> they have a couple of example projects there...
[10:42:24] <Lambda_Aurigae> would be easy to do a power switch with hit.
[10:42:26] <Lambda_Aurigae> it
[10:43:21] <Lambda_Aurigae> http://www.tuxgraphics.org/electronics/200905/embedded-tcp-ip-stack.shtml#0lfindex5
[10:43:24] <Lambda_Aurigae> there ya go.
[10:43:29] <Lambda_Aurigae> ethernet remote switch app.
[11:01:42] <skz81> yup, saw that :) Also, checked the errata... Nothing about SPI description in the DS (more about bugs of the chip and workarounds)
[14:54:18] <doppler_> I'm trying to achieve over-the-air firmware update capability on a system I designed using an atmega328p
[14:54:21] <doppler_> I've started looking into boot loaders and it seems like some of them offer this functionality, and others don't
[14:54:34] <doppler_> am I heading in the right direction or is there something simpler I can do to get the same effect?
[14:54:49] <doppler_> the firmware image will be transferred over USART
[14:55:33] <doppler_> from another microcontroller which is internet-connected
[14:58:44] <doppler_> the other possibility that came to mind was somehow utilizing the watchdog subsystem to do this, but I don't have the intuition to determine whether that's worthwhile...
[15:02:55] <specing> uart? thats not over-the-air
[15:03:44] <doppler_> well, that serial link is attached to another microcontroller which is already internet-connected
[15:04:03] <doppler_> so the hope is to orchestrate a cooperative update procedure
[15:18:03] <antto> doppler_ you can use the watchdog to reset the cpu from the firmware to the bootloader via software
[15:18:42] <doppler_> I see, so I will actually need both things
[15:19:13] <doppler_> a bootloader to handle image transfer and flash programming, and then a watchdog reset hook to cycle the machine and enter the bootloader
[15:20:33] <antto> that way you could have the firmware decide when to attempt "firmware update" .. it will set some flag somewhere (in eeprom or RAM, somewhere where the flag won't be cleared) and cause a reset (via the watchdog) then when the chip resets - it should check if the reset was caused by the watchdog, and if so - check the flags/arguments set via the firmware.. do the update.. etc.
[15:21:04] <antto> some chips have an actual software reset command which makes this much easier (xmega for example)
[15:22:02] <antto> for this to work, you'd have to implement the watchdog-related stuff carefully into both the firmware and especially the bootloader
[15:23:07] <doppler_> that makes sense to me
[15:23:21] <doppler_> would it be reasonable for me to write a bootloader? how complex does it need to be?
[15:29:11] <antto> that's tricky too
[15:30:15] <antto> what you could do is borrow an already working bootloader (if the license is okay) study it a bit and carefully add the extra functionality you want on top
[15:32:31] <antto> the important thing here is: the bootloader is the thing that runs first, every time the chip resets.. so the bootloader has to quickly decide whether to remain running (and wait for programming/firmware update) or jump to the firmware
[15:33:43] <doppler_> that sounds like the easy part
[15:34:12] <doppler_> isn't that just a jmp based on a flag?
[15:34:26] <antto> to make that decision you could have a button (hold the button while power-on to enter the bootloader), a timeout (have the bootloader wait 1 second for programming activity before jumping to the firmware), or some other method, like setting a flag from the firmware itself plus software reset
[15:35:42] <doppler_> the flag method sounds like the best combination of robustness and suitibility for my needs (non-interactive flash initiated by a connected chip)
[15:36:24] <antto> note that, with the last option, while it sounds nice - it can lead to a problem, it requires the firmware to be okay.. what if something bad happens during a firmware update, and the new firmware is partially programmed, thus corrupted - you'll be unable to retry because you can't cause this magical software reset condition
[15:36:54] <doppler_> hmmm yeah
[15:36:59] <antto> while a button would've worked even after such disaster
[15:37:34] <doppler_> well not really :) because this thing is being handled by customers who don't know anything about the internals of this machine
[15:37:49] <doppler_> but I see how that might be an issue
[15:38:39] <antto> i think an extra thing could be added to let the bootloader detect if the firmware is not working properly, and remain running if so
[15:38:47] <antto> but that would require some thinking
[15:40:04] <doppler_> in the next PCB revision I will have outside access to the AVR's reset line
[15:40:30] <doppler_> but that would only help if I have that delay feature or something similar
[15:40:43] <antto> hardware reset?
[15:40:48] <doppler_> yes
[15:41:03] <doppler_> the same one that is routed to the ICSP
[15:41:49] <antto> are you planning to have the user trigger it or trigger it from software via some output pin plus additional circuitry?
[15:43:47] <doppler_> the initial update trigger will be over the internet
[15:43:47] <doppler_> then I'm thinking the two chips can negotiate over USART
[15:43:52] <doppler_> since that's already an established connection between the two and is used for the primary functions of the firmware
[15:44:08] <antto> the really important thing here is: the bootloader and the whole firmware update process should be as simple as possible, and solid
[15:44:35] <antto> because users tend to screw things up especially the first time they try it
[15:45:16] <antto> and it doesn't help if the update procedure instructions is a very long list ;P~
[15:45:44] <doppler_> hey, I'm all for simple
[15:45:50] <doppler_> this is sort of my first time doing a lot of this stuff
[15:46:07] <doppler_> that's why I was asking about the feasibility of writing a bootloader :)
[15:46:20] <antto> the simplest way is with a button aka "hold that button during power-on"
[15:46:55] <antto> the fancy way is with software-triggered magical reset
[15:48:02] <antto> in any case, if you can borrow an already working bootloader - use that, test it, see how the code works, and then carefully add your functionality onto it
[15:48:09] <antto> ..without breaking anything ;P~
[15:49:32] <antto> if you have spare time - try to make your own bootloader, but be prepared to read a few datasheets and docs
[15:49:46] <antto> and make sure you test it well
[15:51:31] <doppler_> what responsibilities does a bootloader have at the bare minimum? right now my firmware is running without one at all
[15:51:34] <antto> i'm using an stk500v2-based bootloader with a variation of the "hold this button" scheme, further modified with LED visualisation, and also updatable via MIDI sysex instead of stk500v2
[15:51:45] <antto> sadly, i cannot "add" the fancy scheme to it
[15:51:55] <doppler_> oh wait :)
[15:52:08] <doppler_> "hold this button" could just be a signal set high/low by the other mcu
[15:52:09] <antto> because that requires modification of the bootloader, but it's too late for that now
[15:52:13] <doppler_> that could work
[15:52:35] <antto> yes, "hold this button" means an input pin
[15:52:58] <doppler_> sweet, I like that
[15:53:23] <antto> the bootloader starts, initializes its things, then checks this pin.. if the value is "normal" - jumps to the firmware, otherwise remains running
[15:53:42] <doppler_> shit I mean that sounds like less than 30 lines of C
[15:55:11] <doppler_> there's a BTLDR section in the datasheet, hopefully that will contain the details needed for jumping to the correct area, etc
[15:55:21] <doppler_> s/area/address/
[15:56:25] <antto> "what responsibilities does it have" <- the bootloader's job is to let you change the firmware easily without needing a programmer, this makes it possible for mortal users
[15:57:00] <antto> it should try not to cause a situation where the chip gets bricked
[15:57:29] <antto> and it should especially try to not corrupt itself.. because a corrupted bootloader is fixable only with a programmer
[15:57:45] <Lambda_Aurigae> done right, a bootloader can't overwrite itself.
[15:58:01] <Lambda_Aurigae> but,,,bootloaders are written by people...soooo
[15:58:14] <antto> yes.. tell that to.. nevermind ;P~
[15:58:33] <Lambda_Aurigae> bootloaders can range from super simple to mega complex.
[15:58:43] <Lambda_Aurigae> I've seen v-usb based bootloaders that are a pain in the ass
[15:58:58] <Lambda_Aurigae> and have written an ethernet bootloader that used the enc28j60 chip.
[15:59:16] <antto> i had to deal with a 512byte bootloader written in ASM with 1-byte commands
[15:59:34] <Lambda_Aurigae> and have also written a bootloader that would take some very simple hex commands and write to flash.
[15:59:37] <antto> that's the one which was able to easily corrupt itself (since it also happened that the chips were not locked)
[16:00:16] <antto> and then the stk500v2-based bootloader, with packetized protocol, much better, and written in C
[16:00:34] <antto> ..onto 4kB flash
[16:00:41] <antto> luxury ;]
[16:00:47] <doppler_> hahah
[16:01:32] <doppler_> I guess I'll give it a shot
[16:01:32] <doppler_> as long as I can jmp properly and nothing is corrupted, I won't be any worse off than I am now
[16:01:40] <Lambda_Aurigae> I've also done an IR protocol bootloader.
[16:02:01] <antto> doppler_ basically, the bootloader sits in a section at the end of the flash memory, the fuse settings have to be set accordingly, then the chip will run from that section instead of running from the beginning.. then your bootloader will be the first thing that gets started
[16:02:25] <Lambda_Aurigae> using the old lego IR comms protocol...where everything is transmitted byte by byte first forwards then backwards...each byte pair is checked and if they don't match it asks for retrans.
[16:02:31] <antto> that last section of flash can be additionally write-protected (via the lock bits)
[16:02:47] <Lambda_Aurigae> most AVRs have a separate bootloader section.
[16:02:56] <doppler_> yes, this one does
[16:02:59] <Lambda_Aurigae> the commands to write to flash can only be run from that section.
[16:03:09] <Lambda_Aurigae> those commands won't work if run from the lower memory area.
[16:03:40] <Lambda_Aurigae> you set the fuses up to have the chip start in bootloader mode...bootloader mode can have its own interrupt table as well.
[16:03:44] <doppler_> Lambda_Aurigae: wow that's pretty crazy re; the IR bootloader
[16:04:08] <doppler_> ok, this is all making sense so far
[16:04:20] <Lambda_Aurigae> the bootloader checks for bootload condition...if passes, it goes into bootload mode...if fails then it switches the interrupt table to the main table(if applicable) then jumps to start of main application.
[16:05:02] <Lambda_Aurigae> the IR bootloader was for bots to get reprogrammed on the combat floor...they could go up to a data station and request a software update.
[16:05:06] <doppler_> be back in a few
[16:05:51] <Lambda_Aurigae> autonomous bot society basically.
[16:06:14] <Lambda_Aurigae> if the bot had the requisite points, it could get its program upgraded.
[16:06:21] <antto> i know who i'll blame when the machines take over
[16:06:23] <Lambda_Aurigae> evolution in action...kindasorta.
[16:06:31] * antto looks at Lambda_Aurigae
[16:06:39] <Lambda_Aurigae> muahahhahaahaaaa..
[16:06:58] <Lambda_Aurigae> these bots were made from legos.
[16:07:19] <antto> i have a whole bucket of legos
[16:07:20] <Lambda_Aurigae> most they could do to you is get underfoot and trip you and make your foot hurt for an hour....
[16:07:36] <Lambda_Aurigae> I had, at the time, about 4000 dollars worth of legos.
[16:07:38] <antto> it's hidden away cuz.. it's like pandora's box
[16:07:53] <Lambda_Aurigae> mindstorms, technic, plain legos, various custom sets.
[16:08:11] <Lambda_Aurigae> sold some and gave some away and moved up to vexlabs robotics stuff.
[16:08:21] <antto> i have mostly old sets from 1990 to 1997 maybe
[16:08:26] <Lambda_Aurigae> these days it's mostly custom built from old printer and copier junk.
[16:08:50] <Lambda_Aurigae> best motors and drivers out there are dug out of old copiers.
[16:08:59] <Lambda_Aurigae> biggest problem is they are all 24V.
[16:09:10] <Lambda_Aurigae> but most will run at 12V with just a loss of strength and/or speed.
[16:09:38] <Lambda_Aurigae> it's nice working in the copier industry
[16:09:47] <antto> i always drooled at the lego technics sets
[16:10:02] <Lambda_Aurigae> specially as my boss knows he can't afford to lose me so I get some fun perks like being able to strip old copiers for my toys.
[16:10:07] <Lambda_Aurigae> technic is great
[16:10:14] <Lambda_Aurigae> mindstorms is technic on steroids.
[16:10:26] <Lambda_Aurigae> I still have a bunch of lego pneumatics stuff.
[16:10:52] <Lambda_Aurigae> need to dig that back out and play with it with my new junk bots.
[16:11:23] <antto> i think the only thing i had from lego technics was a simple bike.. with springs on the rear wheel
[16:11:39] <antto> :~(
[16:11:43] <Lambda_Aurigae> hehe.
[16:12:02] <Lambda_Aurigae> they have chains and tracks and worm gear sets and differential gear sets and all kinds of stuff.
[16:12:10] <antto> but i have the 1994 space robots ;P~
[16:43:56] <doppler> ugh, got pulled to a surprise meeting
[16:43:57] <doppler> antto, Lambda_Aurigae: thanks for the discussion guys :)
[16:46:17] <doppler> I'm gonna give it a shot.