PIC programming - where to start and which programmer to get

[tooki]

• Haven't considered an ATtiny85 as I have never used them. Thank you for the suggestion. Sounds like it could suffice but I would need to add a UART. I expect that the TL866II or one of those FTDI boards could be used to program it?

No idea where you got the notion that an FTDI board can be used. The only Arduino/ATmega/ATtiny boards that can be programmed with an FTDI (= UART adapter) are boards already preloaded with a bootloader. But to load the bootloader, you first need a “real” programmer like a PicKit (or Arduino with the ArduinoISP sketch).

(In contrast, just as an example, the ESP32 series has a serial bootloader out of the box, so an FTDI can be used to program one; in fact, Espressif’s official programmer is just an FT2232.)

[Howardlong]

My experience of Microchip Direct here in the UK is that orders usually take about a week to 10 days elapsed, so you don't want to be in a hurry.

First, they seem to take a couple of days to even dispatch the item from Thailand or wherever stock is actually sitting, but they only ship to Microchip's UK HQ, not direct to the punter. Then the UK HQ ships the items to you via Fedex/TNT overnight.

Recent examples:

Order on 22 June was delivered on 3 July
Order on 22 May was delivered on 30 May
Order on 8 May was delivered on 13 May
Order on 2 May was delivered on 12 May

[Howardlong]

PIC18 (in 2000) added a few things that help a bit but it's still awful,

They added a load of stuff in 2016 including vectored interrupts and DMA revitalising the line-up, as I've mentioned previously on this thread.

[WaveyDipole]

As for Microchip direct: I already told you that Microchip ships those from their UK warehouse, so why would you think you’d be paying for taxes and tariffs on US goods? They’re already imported. You’d be placing a domestic order.

I don't doubt that you are no correct, but it would be nice if they would confirm that. Instead they used pressure tactics stating that unless I give them full personnal contact and other details and create an account they couln't give me any information. The point is kind of moot because I will not be buying direct from them. Eve on the UK site they quote prices without mentioning whether thats before or after VAT so one can only assume that its before and decide accordingly. I didn't mean to question what you are saying an apologise if it came across that way.

Between this and your subsequent statement about the power consumption, you seem to like to base your decisions based on defeatist assumptions, rather than going to the effort to find the actual answers…

Ouch! I like to base my decisions on facts. For purchasing decisions I usually like to have the purchasing source confirm what has been said on a forum, but that has not been the case here. Not in the least bit your fault - but theirs, so perhaps I am being rather defeatist about dismissing Microchip as a direct purchasing source.

On the other hand, I am not too hung up on the power usage if the solution will be powered from USB. However, I have found the discussion of varions optimising techniques interesting and do have a genuine desire to understand this better. I am therefore grateful for all the comments on the subject. Its not something that I have had the need to delve into before, but I understand that in some circumstances such optimisation it might be essntial.

So far in connection wit this specific project, the discussion has shown that I have at least 3 options:

- optimise the Micro (32u4)
- use a different AVR such as 328P or ATtiny
- use a PIC

If low power consumtion end up being required, then it has also shown that optimising code and hardware is the key so I am considering those options leatning more about power optimisation. In the meantime, I now have a working prototype using the board I had to hand as proof of concept. The next step might be to see how it can be best implemented. For example, could one add Bluetooth (BLE) and still keep power below around 20ma? There is also the issue of RF noise so lots to think about.

In the meantime information has been coming my way thick and fast over the last couple of hours so still catching up with the reading.....

[WaveyDipole]

• Haven't considered an ATtiny85 as I have never used them. Thank you for the suggestion. Sounds like it could suffice but I would need to add a UART. I expect that the TL866II or one of those FTDI boards could be used to program it?

No idea where you got the notion that an FTDI board can be used. The only Arduino/ATmega/ATtiny boards that can be programmed with an FTDI (= UART adapter) are boards already preloaded with a bootloader. But to load the bootloader, you first need a “real” programmer like a PicKit (or Arduino with the ArduinoISP sketch).

(In contrast, just as an example, the ESP32 series has a serial bootloader out of the box, so an FTDI can be used to program one; in fact, Espressif’s official programmer is just an FT2232.)

Good point. Indeed the bootloader is essential for USB-to-serial. Was forgetting that. Thank you.

[WaveyDipole]

   * there is a speed tax. Already scarce resource (CPU muscle) gets dilluted further by C, both for covering its own inefficiencies and for plastering over the HW cracks and holes.

This applies to every C compiler on every architecture.

No, that's not correct.

Part of the design of the RISC architectures appearing from about 1985 on is that they provide everything needed to make compiling high level languages such as C or Pascal as efficient as possible, and they don't provide anything extra to that, that won't be used by C compilers. Most of the time there is really nothing to be gained by going to asm unless you are doing something very specialised that is outside the C execution model. An example of that is multiple entry points to the same function with some of them adjusting the arguments or doing a little work and then falling through past another entry point. Though even that example if less strong with ISAs that pass arguments both arguments and return address in registers and have compilers that know how to do tail calls ... and a peephole optimiser that removes a JMP to the next instruction.

Must admit I hear that C compilers are pretty much well optimised these days, although I gather the offering with the free MPLAB X IDE is rather inefficient. Could one simply use an alternative compiler e.g. gcc?

My comments above about modern instruction sets (post 1985) DO NOT APPLY to PIC, which is from 1976 and was designed as a simple Peripheral Interface Controller and not as a general-purpose CPU.

Noted.

No you can not use gcc for PIC. GCC in general only supports 32+ bit CPUs and a few selected 16 bit ones.

The original PIC instruction set (PIC16 and below) is extremely unfriendly to compilers and can not support the normal full C language.

Also noted.

Just one question; I presume that for PICs, when various comments are referring to C, that does literally mean C and not C++? So its no Arduino-like language but and one loses the object oriented stuff that is available on Arduino AVRs? Does one still have std:: libraries at least?

No, C and C++ are the same language in this conversation.

C++ makes more use of pointers to structs and pointers to functions (virtual functions in C++) but all the same fundamental features exist in C and require the exact same kinds of instructions from the CPU, even if idiomatic C++ code uses them a bit more often than idiomatic C code (let alone contorted restricted C code designed to compile efficiently on PIC).

Ok, so its C, but a "contorted restricted C code designed to compile efficiently on PIC". Interesting to note.

[brucehoult]

   * there is a speed tax. Already scarce resource (CPU muscle) gets dilluted further by C, both for covering its own inefficiencies and for plastering over the HW cracks and holes.

This applies to every C compiler on every architecture.

No, that's not correct.

Part of the design of the RISC architectures appearing from about 1985 on is that they provide everything needed to make compiling high level languages such as C or Pascal as efficient as possible,

Respectfully, I don't agree.

It could be argued that x86, PIC24 and dsPIC, for example, are better suited to C than load-and-store RISC architectures like MIPS, ARM or RISC-V because of their base/frame pointer and the pointer addressing modes available to most instructions, not just load and store.

No, and I addressed that in the parts of my message you didn't quote.

Those CISCy addressing modes on all of the arithmetic instructions make life a little easier for asm programmers (but not much, honestly), and maybe for compilers -- though even that is arguable for an optimising compiler because it hugely complicates decisions around CSE -- but it doesn't result in technically better code, just more convenient in some way.

The same for frame pointers. They only exist to simplify life for the human programmer, so that the same stack frame item is at the same offset all the time, regardless of stack pointer pushes and pops. But that's merely a mental crutch, a compiler can easily keep track of changing offsets (and a human can with some effort), and it costs instructions and memory traffic and code size and performance to maintain the frame pointer.

[tooki]

On the other hand, I am not too hung up on the power usage if the solution will be powered from USB. However, I have found the discussion of varions optimising techniques interesting and do have a genuine desire to understand this better. I am therefore grateful for all the comments on the subject. Its not something that I have had the need to delve into before, but I understand that in some circumstances such optimisation it might be essntial.

So far in connection wit this specific project, the discussion has shown that I have at least 3 options:

- optimise the Micro (32u4)
- use a different AVR such as 328P or ATtiny
- use a PIC

If low power consumtion end up being required, then it has also shown that optimising code and hardware is the key so I am considering those options leatning more about power optimisation. In the meantime, I now have a working prototype using the board I had to hand as proof of concept. The next step might be to see how it can be best implemented. For example, could one add Bluetooth (BLE) and still keep power below around 20ma? There is also the issue of RF noise so lots to think about.

If you’re planning to add Bluetooth or WiFi, then just go with an ESP32 series, with the understanding that they aren’t the most power-efficient MCUs out there. (But if you can power it from USB or a wall wart or from power somehow extracted from the device it’s controlling, this might not matter.)

I used a tiny ESP32-C3 board (the DFRobot Beetle ESP32-C3) as a remote control transmitter last year, albeit using the ESP-NOW protocol, not Bluetooth LE. I forget how much current draw I measured when idle. It rises a lot while actively communicating.

[David Hess]

If you’re planning to add Bluetooth or WiFi, then just go with an ESP32 series, with the understanding that they aren’t the most power-efficient MCUs out there. (But if you can power it from USB or a wall wart or from power somehow extracted from the device it’s controlling, this might not matter.)

I used a tiny ESP32-C3 board (the DFRobot Beetle ESP32-C3) as a remote control transmitter last year, albeit using the ESP-NOW protocol, not Bluetooth LE. I forget how much current draw I measured when idle. It rises a lot while actively communicating.

Is there an ARM equivalent to the ESP32?  The last thing I want to do is learn another microcontroller architecture or become more dependent on China.

Hmm, looks like the STM32 is exactly that with a SoC version that includes Bluetooth and Wi-Fi.  I wonder how they compare.

I forgot that Infineon bought Cypress.

[brucehoult]

PIC18 (in 2000) added a few things that help a bit but it's still awful,

They added a load of stuff in 2016 including vectored interrupts and DMA revitalising the line-up, as I've mentioned previously on this thread.

Which is not relevant to C vs asm code quality.

[David Hess]

PIC18 (in 2000) added a few things that help a bit but it's still awful,

They added a load of stuff in 2016 including vectored interrupts and DMA revitalising the line-up, as I've mentioned previously on this thread.

Which is not relevant to C vs asm code quality.

I thought the PIC18 was their answer for better C support.

[brucehoult]

If you’re planning to add Bluetooth or WiFi, then just go with an ESP32 series, with the understanding that they aren’t the most power-efficient MCUs out there. (But if you can power it from USB or a wall wart or from power somehow extracted from the device it’s controlling, this might not matter.)

I used a tiny ESP32-C3 board (the DFRobot Beetle ESP32-C3) as a remote control transmitter last year, albeit using the ESP-NOW protocol, not Bluetooth LE. I forget how much current draw I measured when idle. It rises a lot while actively communicating.

Is there an ARM equivalent to the ESP32?  The last thing I want to do is learn another microcontroller architecture or become more dependent on China.

Original ESP32s (and ESP8266) were the obscure Xtensa ISA which is normally used deeply buried inside a chip and no one except the chip manufacturer knows its there or programs it. Espressif were, as far as I know, the first to expose an Xtensa to end-user programming and Cadence were not all that happy with them.

Recent ESP32s are RISC-V and the company has said all future ones are expected to be.

This is no doubt a controversial opinion, but 32 bit Arm is becoming a legacy technology like PIC, continuing to be used in old designs (and minor updates to them) for a long time, but with fewer and fewer new products built around them.

[tooki]

If you’re planning to add Bluetooth or WiFi, then just go with an ESP32 series, with the understanding that they aren’t the most power-efficient MCUs out there. (But if you can power it from USB or a wall wart or from power somehow extracted from the device it’s controlling, this might not matter.)

I used a tiny ESP32-C3 board (the DFRobot Beetle ESP32-C3) as a remote control transmitter last year, albeit using the ESP-NOW protocol, not Bluetooth LE. I forget how much current draw I measured when idle. It rises a lot while actively communicating.

Is there an ARM equivalent to the ESP32?  The last thing I want to do is learn another microcontroller architecture or become more dependent on China.

Hmm, looks like the STM32 is exactly that with a SoC version that includes Bluetooth and Wi-Fi.  I wonder how they compare.

I forgot that Infineon bought Cypress.

I recommended ESP32 because the OP is already familiar with the Arduino framework, which has robust ESP32 support. (Espressif also managed to maintain high product availability during the pandemic, unlike ST. It seems to be a well managed company. And while Espressif itself is Chinese, the chips are manufactured by TSMC in Taiwan.)

FYI, Espressif is little by little migrating to the open-source RISC-V architecture.


Which STM32 has WiFi? I checked their website and the only WiFi product I see is a separate WiFi module intended as a “companion” to an STM32 MCU. They have many MCUs with Bluetooth, zigbee, etc. but none with WiFi.

[Tation]

In no way will a ESP32 device provide BLE connectivity powered by, say, a CR2032 cell. But there are other chips capable of that, e. g. from Nordic (Arm) or from Telink (RISCV), with offerings below 10 mA.

With the added benefit (over PIC) of support in Zephyr, free dev tools... Can't see the benefit of trying BLE from architectures different of Arm/RISCV.

[SiliconWizard]

Yeah, for low-power RF stuff such as BLE, Zigbee, ... and if you have no use for WiFi, I would clearly also recommend against ESP32 solutions. They are not low-power by any means and there are much better alternatives out there.
Nordic is one serious contender, and On Semi RSL series are also impressively good. All ARM based.

But for WiFi, there's very little competition, at least in this price range.

[Picuino]

https://learn.sparkfun.com/tutorials/reducing-arduino-power-consumption/all

[shabaz]

Is there an ARM equivalent to the ESP32?

I've used the ESP32 for a few projects, I like it.
Not quite the same thing (for hobby projects at least, it might not matter if it's all on one SoC or not) there's the Pico W, or Pico 2 W (latter supports switchable ARM and RISC-V) which both have a basic 2.4 GHz WLAN and BLE. Quite decent SDK too, and works with GNU tool chain. I've not used the W variants much, but find myself using the basic Pico (RP2040) a fair bit. For low cost, low power BLE I think there are a ton of options, at the low end there's some Dialog castellated board modules easy to prototype with, I've found a few uses for them (picked up about 50 of them when they were extremely low priced like sub-$2 but now they've gone up a bit).

[tooki]

In no way will a ESP32 device provide BLE connectivity powered by, say, a CR2032 cell. But there are other chips capable of that, e. g. from Nordic (Arm) or from Telink (RISCV), with offerings below 10 mA.

With the added benefit (over PIC) of support in Zephyr, free dev tools... Can't see the benefit of trying BLE from architectures different of Arm/RISCV.

Well, as I said, I recommended ESP32 to the OP because of his familiarity with the Arduino ecosystem: ESP32 is robustly supported there. But it’s definitely not low-power. (Though it remains unclear whether low power is actually a core requirement or not; OP has sorta flip-flopped on that…)

[WaveyDipole]

https://learn.sparkfun.com/tutorials/reducing-arduino-power-consumption/all

Thank you. Interesting article. 

[WaveyDipole]

In no way will a ESP32 device provide BLE connectivity powered by, say, a CR2032 cell. But there are other chips capable of that, e. g. from Nordic (Arm) or from Telink (RISCV), with offerings below 10 mA.

With the added benefit (over PIC) of support in Zephyr, free dev tools... Can't see the benefit of trying BLE from architectures different of Arm/RISCV.

Well, as I said, I recommended ESP32 to the OP because of his familiarity with the Arduino ecosystem: ESP32 is robustly supported there. But it’s definitely not low-power. (Though it remains unclear whether low power is actually a core requirement or not; OP has sorta flip-flopped on that…)

My current prototype is connected via USB so can draw power from the PC USB port so power draw is not that important in this scenario. Ideally, I would like to arrive at a wireless solution that requires perhaps no more than 20-25ma of current. I don't think that WiFi will be viable - it just draws too much - but am investigating whether Bluetooth is plausible. I came across a BM70 module for example, but it still needs a controller to drive it and might draw more than I would like. I am therefore interested in those Nordic and Telic options so Googling. A range of 5 metres would probably suffice, but 10 would be great.

I suppose one could also use nRF24 modules, with the receiver + ATtiny on the radio end and an Arduino plus transmitter on the PC end. I have some of thhose lying around as well. The nRF module supposedly draws 13.5mA when receiving, so if I can keep the ATtiny to below 12mA then my goal would be achieved. The PC end is powered from USB so no problem. However, I do have a couple of Bluetooth dongles lying around which would be more convenient to use on a PC than making a 3D printed case for an Adruino plus nRF24 transmitter. Still, it *might* be a possible solution.

I would have to test to see how much an ESP32-C3 draws when driving just that single GPIO and running BlueTooth. That *might* also be a solution if it can be optimised down enough, but I'm told that these draw like 110mA, but no doubt that's before any optimization is applied and probably running WiFi. I just plugged it in with the OLED display I had connected and running a display demo and the current draw is around the 25-30mA mark. Disconnecting the OLED does not make much difference but it does drop to below 20mA.

[coromonadalix]

you have the "snap" board who almost do the same job as a pickit4  for less,  paid 10,99 ea directly at microchip  ?


https://packs.download.microchip.com/DeviceDoc/Device_Support.pdf


Please note, Microchip’s SNAP Debugger does not work with UPDI/PDI and TPI based formerly Atmel AVR devices unless the R48 pull-down resistor is removed and a 1k to 10k pull-up resistor is installed between TVDD (J4-2) to TPGD/DAT(J4-4).

[David Hess]

Which STM32 has WiFi? I checked their website and the only WiFi product I see is a separate WiFi module intended as a “companion” to an STM32 MCU. They have many MCUs with Bluetooth, zigbee, etc. but none with WiFi.

Looks like they only have Bluetooth.  I thought they also had Wi-Fi because they are listed with "2.4 GHz".

I will keep looking.

Recent ESP32s are RISC-V and the company has said all future ones are expected to be.

Having participated in a couple of RISC-V discussions, I have even less interest in adopting it.  It reminds me of the all theory and no practice systems designed by university computer professors.

[brucehoult]

Having participated in a couple of RISC-V discussions, I have even less interest in adopting it.  It reminds me of the all theory and no practice systems designed by university computer professors.

A very strange take given all the design decisions that were made emphasising practicality and efficiency -- especially for tiny cores -- over being pretty.

[WaveyDipole]

Hmm, I tried a number of NimBLE-Arduino library examples (couldn't get any of the Espressif included ones to compile) on the ESP32-C3 and for client applications the current draw was around 90mA. For the server application it was 50mA. That's similar apparently to WeAct Blackpill.

Of course, I am just running off-the-shelf examples here without any optimization. I am using the FNIRSI FNB48S USB tester to measure current draw. If it can be optimzed down then it might be viable but would require significant current saving. There's not much in the way of components on this ESP32-C3 Mini board although there is a power LED that could be removed. The rest must be being drawn by the BlueTooth radio and I am researching possible ways of reducing that. Suggestions include reducing clock speed (where have I head that before) and scan frequency. Lowest operating voltage is 3.3V so not much can be done about that.

[westfw]

The only Arduino/ATmega/ATtiny boards that can be programmed with an FTDI (= UART adapter) are boards already preloaded with a bootloader.

Not quite true.  If you have a real FTDI breakout with all the pins, AVRDude added the ability to bitbang AVR ISP protocols, quite a while ago:

Code: [Select]

# FTDI USB to serial cable TTL-232R-5V with a custom adapter for ICSP                           
# http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm                                     
# http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_TTL-232R_CABLES.pdf           
# For ICSP pinout see for example http://www.atmel.com/images/doc2562.pdf                       
# (Figure 1. ISP6PIN header pinout and Table 1. Connections required for ISP ...)               
# TTL-232R GND 1 Black  -> ICPS GND   (pin 6)                                                   
# TTL-232R CTS 2 Brown  -> ICPS MOSI  (pin 4)                                                   
# TTL-232R VCC 3 Red    -> ICPS VCC   (pin 2)                                                   
# TTL-232R TXD 4 Orange -> ICPS RESET (pin 5)                                                   
# TTL-232R RXD 5 Yellow -> ICPS SCK   (pin 3)                                                   
# TTL-232R RTS 6 Green  -> ICPS MISO  (pin 1)                                                   
# Except for VCC and GND, you can connect arbitual pairs as long as                             
# the following table is adjusted.                                                             
programmer                                                                                     
  id    = "ttl232r";                                                                           
  desc  = "FTDI TTL232R-5V with ICSP adapter";                                                 
  type  = "ftdi_syncbb";                                                                       
  connection_type = usb;                                                                       
  miso  = 2; # rts                                                                             
  sck   = 1; # rxd                                                                             
  mosi  = 3; # cts                                                                             
  reset = 0; # txd