#garfield Logs

Mar 23 2022

#garfield Calendar

04:53 AM Tom_L: morning
09:03 AM rue_mohr: I'm not sure what happened yesterday
09:03 AM rue_mohr: I was awake from 4am to about 1am
09:03 AM rue_mohr: so, I'm not running on a lot of sleep just now
01:03 PM aandrew: yeah my last night was the opposite
01:04 PM aandrew: I was tired around 11 but pushed through, I blinked and it was 3am and had an 8am appt. not a good day
01:08 PM aandrew: on the plus side, the natural gas quick disconnect was installed, so now I can modify the generator and test that out
01:09 PM aandrew: might need to redo the pipe from the inside of the wall (where the manifold is) to the outside though, it's only 1/2" and the flex hose is only 3/8", might not provide enough fuel for the generator
01:10 PM aandrew: back of napkin calculations (1HP = 10,000 BTU) suggest it should be fine but might be marginal, especially if I decide to bbq while running the generator, although I think this will only be an issue at close to full load
01:10 PM aandrew: it'll be neat to see
01:10 PM aandrew: I also understand that engines running on natural gas/propane tend to be a LOT cleaner than gasoline
01:40 PM WormFood: do do if(isprint(PINL)) putchar(PINL); while(++PORTA != 0); while(++PORTC != 0); <-- is this code clear?
01:47 PM aandrew: wtf is PINL, it sounds like a #define for a pin but doesn't make sense with isprint() if that's what it is
01:47 PM aandrew: PINL, PORTA, PORTC all sound like memory mapped I/O so no not super clear to me anyway
01:49 PM WormFood: that is what they are
01:50 PM WormFood: the only thing in the line, that is not standard is putchar(). Nothing else is redefined
01:50 PM WormFood: no, I'm sorry, that is the standard putchar() function, but you can't see my code that ties into it, but that does not matter for that line. Everything is as it appears. Nothing weird with the variables.
01:51 PM WormFood: that code compiles and works as intended.
01:52 PM WormFood: I knowm, most people do something like for(i=0;i=x;i++) PORTA=i;....but you can directly use PORTA as a variable, so PORTA++ works. Granted, there probably not be many cases where you actually want to do that, but it does work, which surprised me a little at first.
01:54 PM aandrew: if PORTA is a macro ++PORTA is definitely not going to compile
01:55 PM aandrew: I'm still not sure what you're doing though -- you asked if the code was clear - it is not
01:56 PM aandrew: it looks like you're reading a pin state (PINL) but then isprint() will always be false since (char)0 and (char)1 are both unprintable, so putchar() would never get called
02:20 PM aandrew: woo, got my 915MHz bandpass filters
02:20 PM aandrew: grabbed this off amazon: https://www.amazon.ca/gp/product/B08VDRN3WS, was going to put the BPF on the input side btu still need to figure out a good diplexer setup
02:21 PM aandrew: need to look at the LoRa radios I have and see which have PA switch or separate tx/rx ports
02:46 PM aandrew: hm reading up on cavity filter design now, I wonder how difficult this is with a simple cnc mill and aluminum
02:47 PM aandrew: doesn't look particularly challenging as 33cm band isn't tiny tiny, and as long as the math is right making the machine do it looks straightforward
02:54 PM aandrew: I don't know that a duplexer will actually work for LoRa but maybe the tx/rx bandwidth is narrow enough that you could filter it. Have to investigate more
03:23 PM WormFood: aandrew, that code counts through all 65536 combinations on port A and C, and for each combination, it reads PINL and sends it via putchar. I have not defined any macros. Any macros that may be there are from avr-gcc and/or avr-libc, and not me.
03:25 PM WormFood: PORT A and C are connected to the address pins on an EPROM, and L is connected to the data lines. --> do do if(isprint(PINL)) putchar(PINL); while(++PORTA != 0); while(++PORTC != 0); <-- reads 64K of address space, and sends it over the usart
03:25 PM WormFood: I thought it was a clever task to accomplish without using additional variables.
04:37 PM aandrew: aha
04:38 PM aandrew: PINL is an 8-bit port, from the name it sounded like 1 bit
04:38 PM aandrew: I'd not try to be cute with the code:
04:38 PM aandrew: for (i = 0; i <= 65535; i++) {
04:38 PM aandrew: *PORTA = *i >> 8;
04:38 PM aandrew: *PORTC = *i & 0xff;
04:39 PM aandrew: /* delay if needed */
04:39 PM aandrew: val = *PINL;
04:39 PM aandrew: if (isprint(val)) {
04:39 PM aandrew: putchar(val);
04:39 PM aandrew: }
04:39 PM aandrew: }
04:39 PM aandrew: chances are the compiler will do something similar anyway and at least this is clear what you're after
04:40 PM aandrew: also by not hitting PINL twice you also don't hit hardware twice (if that's an issue)
04:40 PM aandrew: and also (not necessary for this ocde, but in general) you can also avoid side effects if there are any on accessing a port
04:41 PM aandrew: if your native data width is 8-bit I'd use two loops for high and low address byte of course, not sure what the target hw is. I assumed 16-bit hence the >= 65535 rather than > 65535 to avoid accessing 32-bit variables
04:41 PM aandrew: um
04:42 PM aandrew: not sure why I said *i, should just be i
04:42 PM aandrew: and *PORTA/*PORTC/*PINL might not need the dereference either, just assuming they're voltile ponters
04:44 PM aandrew: also you're not really dumping the ROM if you're not outputting the value if it's not printable
04:44 PM aandrew: you're more or less doing a "strings" on it
04:45 PM WormFood: *PORTC = *i & 0xff; <-- should not be necessary
04:45 PM WormFood: You're right, that is the way most people would write it.
04:45 PM aandrew: ah yes if it's all 8bit stuff then yeah it'll automatically truncate
04:45 PM WormFood: but, your version is clearer, or more concise
04:46 PM WormFood: actually, the compiler should optimize that out, if it's worth a damn
04:46 PM WormFood: it'd be easy enough to test out tho
05:20 PM WormFood: but, there is one other thing tho...The address space is actually bigger than the code suggests, and is actually 20 bits, and not 16, and those 4 other bits are tied into 2 more registers. I expect my code is faster, because each loop is doing less work, but I don't think either way it matters, because it's probably going to spend a lot of time waiting on the serial port.
05:24 PM aandrew: yes, early optimization is an easy trap to fall in to
05:24 PM WormFood: a 16 Mhz cpu, sending at 230.4Kbps....I don't think either method is going to matter....except for one more thing....I'm going to be using it with xmodem, so 128 or 1024 byte chunks, and if I understand correctly, I need a CRC *before* the block is sent
05:25 PM WormFood: so, doing a CRC caclucaltion, before sending a block of data, is going to need to be fast enough to not timeout the other end.
05:26 PM WormFood: but, I can fix that, and make it calculate the crc, as it sends the data, then travel back in time, and send the crc, before the data is sent.
05:28 PM WormFood: after the CRC on the first block is calculated, then for each byte that is transmitted, you calculate the crc on the next block, so when you're ready for the next block, it already has the crc.
05:29 PM WormFood: now, in a situation like that, the method of doing it could matter a lot...but, having xmodem's blocks at 128/1024 bytes sucks. I wished it was 256 bytes...that'd simplify things a lot.
05:30 PM aandrew: if you need to send the CRC before the block the CRC is protecting that also means you need to buffer 128 bytes somewhere
05:31 PM aandrew: (or read twice of course)
05:31 PM WormFood: aandrew, I'm gonna try your code and see how fast it is, compared to mine, and see if it actually makes any performance difference.
05:31 PM WormFood: what? I don't need 128 bytes of data anywhere.
05:31 PM WormFood: why would I need that?
05:31 PM WormFood: I need 2 bytes for the CRC
05:31 PM WormFood: feed 128 bytes into the crc, get 2 bytes out
05:32 PM WormFood: now send the crc and those 128 byte
05:32 PM WormFood: s
05:33 PM WormFood: aandrew, why would I need 128 bytes of buffer anywhere?
05:38 PM aandrew: if the CRC prefixes the data it protects, you either need to read it twice (once to calculate CRC, once to transmit) or buffer it
05:40 PM WormFood: it's in ROM/PROM/EPROM/FlashROM....I truly do not expect it to have much chance to change between calculating the CRC and sending the data it protects. And if there is a difference, the remote end will tell me, and I'll send the same CRC and data over again.
05:41 PM WormFood: it is possible, that you could get a flaky read, and it not be the same, but if you get a bad read, you're guaranteed that the bad data gets to the other end. By calculating the crc this way, you have a better chance to catching errors like that...at least, it seems that way in my mind
05:42 PM WormFood: if you see it differently, I'm all ears. (or is that "all eyes" on IRC?)
05:44 PM WormFood: I see no reason to buffer 128 or 1024 bytes for the crc. However, I will admit, it would make it easier for me to adapt existing xmodem code, if I did buffer it. It just seems unnecessary to do it that way.
06:32 PM aandrew: nope I agree
06:32 PM aandrew: in this application you can re-read as many times as you like
06:38 PM rue_mohr: its here!
06:38 PM WormFood: The symptoms?
06:38 PM Tom_L: i was gonna mention they updated the shipping date again
06:41 PM rue_mohr: the box
06:43 PM Tom_L: but i see you figured that out
07:05 PM rue_mohr: :)
07:21 PM Tom_L: now you just need a few more projects
07:26 PM rue_mohr: ugh
07:28 PM Tom_L: find the chips?
07:29 PM rue_mohr: yes!
07:30 PM rue_mohr: I'll set them up in a bit
07:30 PM rue_mohr: I'm completely out of energy right now
07:30 PM rue_mohr: I want to play with the parts
07:36 PM aandrew: I have too many things to play with now, I need to organize them so I don't lose them so I can come back to them in a bit
07:44 PM rue_mohr: I got the connectors for my battery tester today too, I need to finsih that, bill 2 people for paint sprayers, build 5 more spryaers, see if a company picked up an order and dropped off more repairs, and play with some javascript
07:45 PM Tom_L: parts look right to you?
10:35 PM rue_bed2: yes
10:35 PM rue_bed2: I woke up!
10:35 PM rue_bed2: am I awake now then?
11:25 PM * rue_mohr starts supper
11:29 PM BloodMoon: boink
11:30 PM rue_mohr: hey
11:31 PM BloodMoon: I got a fly new laptop ;)
11:31 PM rue_mohr: coo
11:31 PM BloodMoon: test driving it
11:31 PM rue_mohr: it dun be fast then?
11:32 PM BloodMoon: Flipping fast... one I erased it :D
11:32 PM BloodMoon: once*
11:32 PM rue_mohr: so your working two jobs now?
11:32 PM BloodMoon: yeah :P
11:32 PM rue_mohr: huh
11:33 PM BloodMoon: you would never of thought hay?
11:33 PM rue_mohr: your dynamic
11:34 PM BloodMoon: I'm strange and seem unemployable, but I wont stop till I get what I want.
11:34 PM BloodMoon: in the big scheme of things
11:34 PM rue_mohr: this 24 hour interval doesn't work for me
11:35 PM BloodMoon: of shifting gears?
11:35 PM rue_mohr: I'm really working hard to try to be awake at the right times
11:35 PM rue_mohr: I need to move to another planet where the days are a bit longer
11:35 PM BloodMoon: classic Rue
11:36 PM BloodMoon: maybe you need to move to alaska
11:36 PM rue_mohr: too cold
11:36 PM BloodMoon: yeah
11:37 PM rue_mohr: how about a space station?
11:37 PM rue_mohr: not the international one
11:37 PM rue_mohr: one with more diversity
11:37 PM BloodMoon: oh no?
11:37 PM BloodMoon: HA
11:38 PM rue_mohr: went to sleep after work
11:39 PM rue_mohr: woke up at 8
11:39 PM rue_mohr: pm aparently
11:39 PM rue_mohr: so, ok
11:39 PM rue_mohr: working on some javascript
11:43 PM BloodMoon: Javascript hay?
11:43 PM rue_mohr: yea, but the browser isn't showing me errors
11:43 PM BloodMoon: Why how?
11:43 PM rue_mohr: if there is an error it just wont run it
11:44 PM rue_mohr: <body onload="updateDB()">
11:44 PM BloodMoon: dev shell???
11:44 PM rue_mohr: function updateDB() {
11:44 PM rue_mohr: DB.onreadystatechange = refreshDB;
11:44 PM rue_mohr: DB.open("GET", "database.txt", true);
11:44 PM rue_mohr: DB.send();
11:44 PM rue_mohr: }
11:44 PM BloodMoon: no error
11:44 PM rue_mohr: function refreshDB() {
11:44 PM rue_mohr: if ((DB.readyState == 4) && (DB.status == 200)) {
11:44 PM rue_mohr: PDB = [];
11:44 PM rue_mohr: DB.responseText.split("\n").foreach(addCard2DB(s, i), PDB);
11:44 PM rue_mohr:
11:44 PM rue_mohr:
11:45 PM rue_mohr:
11:45 PM BloodMoon: is DB an instance of xmlHtp
11:45 PM rue_mohr: document.getElementById("debug").innerHTML = PDB;
11:45 PM rue_mohr: }
11:45 PM rue_mohr: }
11:45 PM rue_mohr: var DB = new XMLHttpRequest();
11:45 PM BloodMoon: yeah it is
11:45 PM BloodMoon: yup
11:45 PM rue_mohr: function addCard2DB(s, i) {
11:45 PM rue_mohr: if (s == "OK") return; // check this...
11:45 PM rue_mohr:
11:45 PM rue_mohr: var temp = s.split(":");
11:45 PM rue_mohr: var tempo = {address: temp[0], code: temp[1]};
11:45 PM rue_mohr: PDB = {...PDB, ...tempo };
11:45 PM rue_mohr: }
11:45 PM BloodMoon: im doimg that too in my prooject
11:45 PM rue_mohr: evil enough?
11:45 PM BloodMoon: kinda
11:46 PM BloodMoon: I think you got it slighly fcuked up
11:46 PM rue_mohr: hah
11:46 PM rue_mohr: I'm stepping thru it mentally here
11:46 PM rue_mohr: the fact PDB is an object dont help debug it
11:47 PM rue_mohr: aparently I need more tea
11:48 PM rue_mohr: not 100% sold on using key:value pairs, but I think its more right
11:48 PM BloodMoon: as I thought, your being unessasery with your 'scope'
11:49 PM rue_mohr: heh, things are a bit too global :)
11:50 PM BloodMoon: W3schools shows it flat out
11:50 PM BloodMoon: using 'this' can be a good thing
11:50 PM BloodMoon: are you trying to return JSON?
11:51 PM rue_mohr: I'm doing it at a file level, which works, hehe
11:51 PM rue_mohr: yea
11:51 PM BloodMoon: ok Let me help you for god sakes
11:51 PM BloodMoon: !
11:51 PM BloodMoon: fuck
11:51 PM rue_mohr: I'm grabbing database.txt which is a test of the serial reply that will come from the avr
11:51 PM BloodMoon: hold the phone and watch
11:52 PM rue_mohr: a debug console woul dbe nice
11:52 PM BloodMoon: MyJsonOBJ = JSON(`this: ass[0] that: ass[1]`);
11:52 PM BloodMoon: yes thos are back ticks WTF right
11:53 PM rue_mohr: er, thats using a libary tho isnt it?
11:53 PM BloodMoon: no standard javascript
11:53 PM rue_mohr: oh, they wove it in deeper?
11:53 PM BloodMoon: is integral for the language to have that functionality
11:53 PM rue_mohr: so the return format looks like
11:53 PM BloodMoon: Javascript is fucking amamx=zing
11:53 PM rue_mohr: 01F7:FFFFFFFF
11:53 PM rue_mohr: 01F8:FFFFFFFF
11:53 PM rue_mohr: 01F9:00C21616
11:53 PM rue_mohr: 01FA:FFFFFFFF
11:53 PM rue_mohr: 01FB:FFFFFFFF
11:53 PM rue_mohr: address:value
11:54 PM BloodMoon: lol maybe but its an actuall objact from that pint on
11:54 PM rue_mohr: ends with "OK" just to throw it all
11:54 PM BloodMoon: with 2 members
11:54 PM BloodMoon: try it
11:55 PM rue_mohr: why the JSON context tho, convienience?
11:55 PM BloodMoon: yeah very much so
11:55 PM rue_mohr: the goal is to have a database in memory of all the entries
11:55 PM BloodMoon: you get a string from the server call and then BAM its a fucking ligit structure!!!!!
11:55 PM rue_mohr: so I'm peeling it off one line at a time and parsing it into key:value pairs
11:56 PM rue_mohr: what are ya expecting the server to reply with tho
11:56 PM rue_mohr: xml?
11:56 PM BloodMoon: IF YOU make it a real object its going to be a breeze to traverse with for loop
11:56 PM BloodMoon: xml??
11:56 PM rue_mohr: ah, I have evil text that needs to be parsed tho
11:56 PM BloodMoon: no
11:56 PM BloodMoon: JSON
11:57 PM BloodMoon: as a big long string
11:57 PM BloodMoon: some do xml
11:57 PM BloodMoon: but use an inter face that return JSON
11:57 PM rue_mohr: ah, the idea of this is that I dump ALL the processing on the browser
11:57 PM BloodMoon: GOD i actually am writing a full stack all javascript application last week it already works
11:58 PM BloodMoon: you want to see the code
11:58 PM BloodMoon: its 3 parts
11:58 PM BloodMoon: sql server
11:58 PM rue_mohr: no thinking on the avr or the esp8266 bridging the data
11:58 PM rue_mohr: no thats ok
11:58 PM BloodMoon: node js api server
11:58 PM BloodMoon: and javascript client in brouser
11:58 PM * WormFood cringes at the thought of javascript
11:58 PM rue_mohr: but you kinda answered one of the things I was running up against,
11:59 PM BloodMoon: ok
11:59 PM rue_mohr: the term javascript has gone all blurry with terms that reffer to javascript extensions
11:59 PM rue_mohr: hmm
11:59 PM rue_mohr: ok, so
11:59 PM rue_mohr: lets just walk thru this
11:59 PM BloodMoon: ok